The gomo learning suite and Experience API (xAPI or Tin Can API)
What is xAPI?
xAPI (also known as Tin-Can or Experience API) is a brand new specification for learning technology that makes it possible to collect data about the wide range of experiences a person has (online and offline). This API captures data in a consistent format about a person or group’s activities from many technologies. Very different systems are able to securely communicate by capturing and sharing this stream of activities using xAPI’s simple vocabulary.
The gomo learning suite and xAPI
gomo supports xAPI v1.0 and the gomo learning suite communicates with the Learning Locker LRS to store and retrieve data.
In gomo 3.0, we are tracking preset statements. These statements indicate the following:
Course passed/failed with result block containing score (raw, min and max) and completion
Page visits - experienced
Question answered with score (raw, min and max), success and completion status
Assessment completed with score (raw, min and max), success and completion status
Course exited with duration/session time information
Course state data for internal use; tracks last location and general course state
The gomo player sends xAPI v1.0.0 compatible statements to record all of the above events at relevant points throughout a user’s journey. Statements are triggered automatically once xAPI is enabled (via the gomo authoring portal). As per our SCORM support, each assessment can optionally be tracked and/or chosen to control the overall passed/failed status of a course. All statements are sent and a received to Learning Locker using standard delivery methods (AJAX requests).
gomo 3.0 and xAPI for standalone courses and alternative LRS’s
gomo supports xAPI v1.0 and supports the publishing of standalone courses to any xAPI v1.0 compatible LRS.
It will therefore be possible to use gomo with a third party LRS right out of the box. If this is loaded in to an LMS, then they typically specify the LRS details via some standard URL parameters like so:
So the URL parameters are typically how you would expect it to function when running inside a third party system.
In the case where a gomo course has LRS details embedded in the player and also loaded in to an LMS that specifies them via the URL, both systems will receive the xAPI tracking statements.
The current course user/actor should always be specified via the URL as this is a standard requirement of xAPI courses.
xAPI APs do not need to be launched from an LMS, however it is still an option. When an LMS launches a xAPI AP, it will provide the necessary information for that AP to track back to the LRS (endpoint, learner information, credentials, and optionally registration, activity ID, platform, language, and grouping). The format of the launch URL will be as follows:
Note that that some of the parameter values include reserved characters, and even other URLS, and therefore must be URL encoded. Example launch link (shown without URL encoding and with line breaks for readability):
Each statement comprises of a verb, activity and actor, the verbs we use are shown in blue above. The activity is always the current page or asset being acted upon and the actor indicated the current user, currently specified via the URL. This results in a statement similar to this:
The LRS will present this to the user in plain English like so:
"Mike Alcock launched 'Health and Safety'"