The first thing to get out of the way when we discuss Tin Can or Experience API (xAPI) is that they are the same thing.

“Project Tin Can” was just the name of the original research project that resulted in xAPI. So that’s one less term you need to look up.

xAPI is a standard format for communicating and storing learning data. It tells everyone what data to store and how to write it down whenever a learner completes a learning experience. Storing individual experiences, not just quiz scores, is the driving factor of xAPI and Tin Can. But where does xAPI fit with the rest of the educational technologies out there including SCORM? Is it a replacement for SCORM? We’ll find out more as we dig into this topic!

Background

xAPI was created by the Advanced Digital Learning Initiative (https://www.adlnet.gov/), a program of the US government to promote best practices in digital learning. They knew that a common language that allowed many different learning software to communicate with each other were crucial for the industry.

At the time Tin Can was first imagined, around 2010, the internet was evolving and new web development principles were emerging. 2 examples that we see applied in the xAPI architecture are client-server separation (a web app should separate storage and interface so that they are independent on each other—thus xAPI focused only on storage) and statelessness (the data in each request should contain all the information required to understand the request without additional info from the server—thus xAPI includes many more variables in the stored data). Part of the need for xAPI was to keep up with modern best practices.

Like SCORM, xAPI provides a standard for the communication of learning data between systems. It further recognized that learning can happen formally or informally in many different contexts and formats; simply recording that something is “complete” or “incomplete” is not enough anymore. Educators want to know if it was a live seminar, an online quiz, an observational assessment, or more. All these experiences are significant to a learner’s journey so why not record them all?

xAPI stores each learning experience (whether it’s answering a question, completing a quiz, attending a seminar, or completing a course) as a “statement” encoded in a format called Javascript Object Notation (JSON). A statement can include some or all of the following information:

• Actor: who is doing the learning? This includes a name and an email to identify the learner.
• Verb: what did they accomplish? xAPI includes many possible verbs to describe what the learner did (for example: passed, failed, completed, attempted, attended, commented, and more).
• Object: a reference to the learning content including a URI to the resource.
• Context: is the activity a part of something bigger?
• Result: Did they pass or fail? What was their score?
• Timestamp: when did the learner complete the experience?
• Authority: who is providing the training activity?
• Extensions: if there is any relevant data that doesn’t fit in the areas above, put them here.

A learner’s records could include hundreds or thousands of statements and these need to be stored in a Learning Record Store (LRS) to be used later. The end result of xAPI is meaningful data about a user’s learning experiences. Having all of the information above on a learner would give you a very thorough picture of what they have learned so far!

It’s important to note that xAPI is only concerned about the format of the data, not the technology used to listen in so it seeks to cover a broad set of learning situations, not just LMSs and Elearning.

xAPI (Tin Can) vs SCORM

To talk about how xAPI is different from SCORM, we need to revisit certain factors about SCORM. In our previous post, we described how SCORM defined standards for interactions between an LMS and the learning content. SCORM focused on questions, passing grades, and scores specifically in eLearning modules. It listened for when the learner started a module, entered a question response, and ended a module.

Compare that with what xAPI stores above—xAPI is designed to handle many more situations than SCORM. Data collected with xAPI is also much more descriptive; that’s useful if the data needs to be shared across companies, organizations, or schools. A key point to understand is that xAPI is a format for storing data, not an end-to-end tool that does it for you.

So does xAPI replace SCORM altogether? Not exactly. As we mentioned, xAPI is a format for recording data that goes way beyond SCORM, it does not tell you how to listen for that data or interact with learning content at run-time. SCORM requires javascript to interact with content while xAPI leaves it up to the developers and authors to handle those interactions. Technically, you could use SCORM to listen for user data and store that data in an xAPI format, you would just be limited to the variables available in SCORM. It is most likely that the creators intended for developers to come up with their own solutions for handling interactivity beyond SCORM but to store it in a standard format.

Pros and Cons of xAPI

xAPI made changes to the SCORM concept in order to expand on the kinds of learning data that can be captured in standard set of records. It provides:

• More robust details on learning activity
• Records that can be shared between different contexts
• Flexibility to fit more learning situations

However, with more power and flexibility comes more work. xAPI provides many more ways to store learning data but it is up to instructional designers and programmers to make use of them. It is great to be able to store the results of observational assessments, but it means that developers must create tools that would enable that since many existing elearning authoring tools are not yet equipped for it.

Ultimately, that is the challenge of xAPI. SCORM provided 8 standard functions that LMSs and learning content authoring tools had to account for. Once those were programmed into these products, instructional designers could create whatever content they liked knowing those functions would be handled without any additional codes. However, with the unlimited possibilities of xAPI and less restricting requirements, it is much more likely that it involves some coding.

How to start using xAPI

OK, you are sold on xAPI but how can you actually start using it in a real world setting? Just like with SCORM, xAPI requires the LMS and learning content to be compliant.

First, you’ll need to set up a Learning Record Store (LRS). This is where the data is sent, stored, and then retrieved for reports. This will need to be part of your LMS or at least integrated with it. Look out for LMSs that support xAPI or build an LRS yourself.

Next, you’ll need to ensure the content you published sends xAPI data to your LRS. This can be configured through a content authoring tool (that supports xAPI) or custom developed with your learning content (e.g. a web page that submits data to the LRS on completion).

Lastly, you need a way to get your xAPI data back out from your LRS as useful reports. This should be part of the LMS but, as always, you can build it yourself.

xAPI is most powerful in the hands of developers, so if you really want to make the most of the learning data you collect, you might want to look into a developer or development team for your project.

Are you looking to implement xAPI or SCORM in your organization or want to just learn more about it? Get in touch with us!