I’ve had my eye on Tin Can xAPI for a few years now, and they’ve finally earned their spot in the eLearning trend talks. However, there is a lot of discussion on what you can do with xAPI, but little discussion on how to actually implement it in your learning solutions. So, my goal is to give you a high-level, plain English explanation of what you’ll need and share some resources to help you get started. Let me start with a brief bit of history of xAPI.
Tin Can was the original name of xAPI. It was developed by Rustici Software in 2011 when they were commissioned by Advanced Distributed Learning (ADL), after they responded to a Broad Agency Announcement (BAA) for ideas for the next generation eLearning specification. ADL is the keeper of SCORM and understood that the existing protocol has its limitations and flaws, so they set out to find a new way of reporting learning interactions. The first version of Tin Can was finalized in 2012 just in time for DevLearn. You can read more on the background of Tin Can here.
WHAT IS xAPI?
- Mary attended the webinar.
- Bob started watching the video, but only watched the first 2 seconds.
- Mike downloaded the resources using AR app.
- Jane clicked the Help button in the course three times.
- Alice read an industry article.
xAPI uses statements to track behaviors. A statement is composed of three elements:
ACTOR / VERB / OBJECT
“I” “DID” “THIS”
Unlike SCORM, which is difficult to understand and requires an established connection (can only track course clicks within the LMS), xAPI gives us a common language that is easy to use and doesn’t require an established connection. This means that you can track learning interactions that happen outside the LMS, for example, interactions in ILT sessions, on-the-job learning, self-directed learning, etc.
The ADL created a standard xAPI language that is used to create xAPI statements. This ensures that statements used by different technologies report back the same experience using the same language. Let me share a quick example:
A learner attends a webinar hosted through WebEx and then attends another webinar hosted through GoToMeeting. Each of these webinars is set up to track and report the learner’s behavior. However, they may report the experience differently:
|Learner registered for webinar||Learner signed up for webinar|
|Learner logged on to webinar||Learner signed in to webinar|
|Learner answered a poll||Learner responded to a poll|
In both cases the learner completed the same tasks, but they were reported differently. Imagine having to sift through data that tracks what learners are doing using different languages. The xAPI standard vocabulary ensures that the behavior is reported using the same language.
xAPI arms Instructional Designers, such as you and I, with a new tool to really measure a learner’s performance. However, the question, “How do I get started with this awesome Tin Can API/xAPI stuff?” has left many scratching their heads. The good thing is that you don’t need to be a software programmer to start using xAPI; there’s software to help.
WHAT DO I NEED?
xAPI does not communicate with an LMS; it needs something else to accept and capture the statements it sends. That something else is called a Learning Record Store (LRS)—think BIG, SCALABLE DATABASE. Some newer LMSs have a built-in LRS, but others haven’t caught up yet and require a separate LRS solution. Many free, open source, and low-cost LRS options are out there.
Your LRS will accept and capture the xAPI statements sent by your learning solution. It also gives you the ability to view, print, and manipulate that data. I’ve been using Saltbox for about a month; they offer a free LRS that can be used for personal and small-scale testing. An external LRS can be secured using https protocol.
If you want to share data between your LRS and your LMS, you’ll need a connector that will facilitate communication between the two. Most LRSs will offer an LMS connector. My recommendation: Do your research to make the best recommendation for your client.
You will need a way to write and send the xAPI statements. The good news is most rapid development software can write xAPI statements for you as part of the course publishing process. This gives you a way to experiment and develop an understanding of how it all works. Rapid development tools provide a standard, limited set of statements. For example, Storyline will provide only the following standard verbs as part of the built-in statements:
You can read more here. Adobe Captivate 8.0 and 9.0 also have the same capabilities; you can read about it here. You can also publish Lectora for xAPI; read about it here. Again, these tools will provide you with a basic set of xAPI statements that will be sent to your LRS.
I’ve published a Storyline course using Tin Can API as my output option. Open and study the Tincan.xml file to whet your palate.
Latest posts by Myra Roldan (see all)
- Webinar Q&A | CARDBOARD: Inside a Rapid VR Project - April 12, 2017
- Five Schoolhouse Rock! Learning Strategies You Should Be Using - March 2, 2017
- Webinar Q&A | Creating Sticky Learning With Low-Cost AR Solutions - January 23, 2017