Tin Can. Experience. TIN CAN! Experience! We’re all hearing about it… but what is it?
For starters, the official, government-sanctioned name is “Experience API.” It’s the next generation of SCORM… an API for distributed learning. You’ll probably still hear it called “Tin Can” sometimes, but that was a working title. We’ll use its proper name from here on out. ADL, or Advanced Distributive Learning, is the government agency behind the spec.
API’s (that stands for Application Programming Interface) are not nearly as scary and complicated as they sound. An API is a language two software programs or databases use to talk to each-other. Ever created an account on a third-party website using your Facebook account? That was thanks to the Facebook API. Ever had an app that uses Google Maps to log what route you ran? That communication comes courtesy of Google’s API.
SCORM, You’re Looking Weary
eLearning has been signed, sealed and delivered via SCORM for years. The SCORM API is tested and reliable for tracking of basic information such as course completion, time spent taking a course, completion date, and post-test score. This works great, because the only learning interactions anyone has ever thought of hinge directly on how learners do on a post-test, right? Wrong!
Learning designers have been forced to design their eLearning to work within the tight constraints of SCORM for too long. As stable as the API is, it has a number of limitations:
- Activities must be launched from the LMS. Courses, courses, and more courses, please.
- Activities must have a constant internet connection to be recorded. Sorry, mobile workforce.
- A limited number and type of activities can be tracked. Exciting metrics like completion, time spent, pass/fail and a final score are as good as it gets.
How is Experience API better?
Experience API brings us a number of improvements to take advantage of in L&D:
- It can track learner progress without a constant internet connection.
- It does not need learning experiences to be launched from the LMS in order to track them.
- It can record information on social interactions.
- It can track learner activity from a variety of informal activities. One example given by ADL is a “bookmarklet” that can be installed on a web browser and be used to track informal activities such as web pages visited.
Since Experience API does not need the LMS to report activity, content from Wikipedia, Youtube, TED Talks, Coursera, Kahn Academy and more can all be integrated into formal courses without a hitch. Progress from these sources can be reported in the LMS right alongside formal courses.
These new data points are all collected by a new database called a “Learner Record Store.” These are currently stand-alone products, but ADL predicts they will eventually be integrated right into LMS’s. A Learner Record Store, or LRS, is where Experience API sends all the data from mobile apps, informal learning, social conversations, and more.
That’s great, but when will my LMS Support Experience API?
Experience API reached version 1.0 in May 2013. Now we can all complete our required training while skiing in the Andes with no internet, right? Not so fast. LMS’s will all have to adopt the spec before it can be used in eLearning… at least, by companies that require all training be housed in an LMS. And while enabling Experience API is one thing, taking full advantage of the spec will take more time.
Authoring tools such as Lectora and Articulate Storyline have already announced support for Experience API, and this is certainly a necessary step in the adoption process. However, these tools have really just added Experience API as an option for delivering the same data that was already being tracked via SCORM. Sure, you can start using it now, but you’ll probably still just be tracking course completion, Pass/Fail and the like.
It’s sort of like hopping in your new Ferrari to drive 20 mph through your neighborhood. It sounds great, but you aren’t using the vehicle any differently than you used your old Camry.
Even if a major LMS vendor adopted Experience API tomorrow, it would not have much to offer you if you still plan to deliver the same “click next” eLearning courses. Sure, one potential advantage would be allowing you to record the completion of a mobile app or game created by a custom provider like us. But this hypothetical Experience API LMS still would not be doing anything to interpret all of the new data points it can now collect.
New Analytics and Reporting capabilities Needed
In order to take advantage of Experience API’s ability to collect data from informal learning activities, detailed results from games and mobile app usage data, LMS vendors will need to build robust new analytics, reporting, and data visualization capabilities. The data we collect is only as good as the means we have for processing and interpreting that data.
Experience API gives L&D the ability to design and develop more engaging learning solutions… but we still have a long way to go before we are really harnessing all this new potential. The technology we use to deliver and manage these solutions has a great deal of catching up to do… and that catching up requires significant time and financial investment. So while Experience API-compliant LMSs will undoubtedly start popping up next trade show season, an LMS that is really using Experience API for all it’s worth is farther away than we think.
And while just adding “Experience API support” is not the final answer for LMSs OR authoring tools… it’s a positive first step that prepares our industry for the dramatic leap that will happen when we really start measuring learner experiences instead of course completion.
How can I get my LMS to be Experience API compliant sooner?
Ask for it! Talk to your LMS provider. Let them know it’s a priority for your organization. The sooner a critical mass of customers are asking for Experience API support, the sooner LMS’s will get on board.
The first question an organization should ask itself is whether they still require an LMS in the traditional sense in the first place. Is there a better way to tie a Learning Records Store (LRS) into their existing HR and personnel systems without the more rigid confines of an LMS? Having an LMS support XAPI will certainly speed adoption of the new standard, but if it makes sense for the organization, particularly if they have a significant mobile workforce or a BYOD culture within their organization, they should be moving away from the traditional LMS, and quickly. But, very salient and valid points throughout, but we need to get L&D professionals to better understand the workings of XAPI in terms of the verbiage used, and the more simplified nature of the communications, including being able to utilize/communicate with XAPI through web services. Let’s continue and raise the discussion above these simplified explanations and show ISDs how they can use this in a real world situation via social media interaction, serious games or simulations, etc., even YouTube viewing. if we’re still framing our reference around “courses” in terms of this new API, we’re going the wrong direction.
Thank you Steve!
And yes, TALK TO YOUR LMS PROVIDER! The sooner they will get on-board, the better.
In http://www.sweetrush.com we often consult clients on choosing a proper LMS, and I think this is right about time when Tin Can support should become one of the top requirements.
I also agree with KurtMel in the previous comment. Learning Records Store (LRS) is clearly a better solution than traditional LMS, at least in theory. From what I can see, the practical implementations of LRS are still hard to find, but times are changing my friends, times are changing.
This is about the best explanation of Experience API that I’ve read yet. Thank you Steve!
Thank you! I tried to be as clear as possible and leave out the jargon and “buzz.”
My favorite line with the Tin Can hype is ‘It can track learner progress without a constant internet connection’. And how is this to happen exactly? It appears that the attitude is ‘Tin Can content can store statements locally whilst offline because they are incredibly clever’. This is fine if in a full browser. For the vast majority of mobile applications Tin Can will be opened in a Web Browser Control that is part of the native SDK. So where does this magic happen here?