Update: The Output of Project Tin Can is Experience API.
Platform Transition
The Tin Can API allows for a learner to start an activity on one platform (such as a computer at home) and continue that activity later on a different device (like a native app on a mobile phone.) This is a simple but powerful new capability, and wasn’t possible with any of the older e-learning standards.
Enough data can be stored in the LRS so that reports can then be pulled based on where the activity took place — 20% of this activity was experienced on the native Android app, 70% of this activity was experienced on Internet Explorer for Windows 7, etc. Reporting doesn’t have to get that granular, but it’s nice to know that it can.
One thing that makes platform transition possible is that content isn’t stored in an LMS. An activity developer can create different versions of an activity for each platform that he/she might want to use, and then remain in control of the delivery. Content and activity creators aren’t dependent on LMSs to deliver the right versions.
How does it work? Thought you’d never ask.
There is a “state” API that allows for storage of as many key/document pairs as the activity wants to use. A “state” can be created that is shared across the same activities on different devices.
In the instance of platform transition, the Tin Can API allows an LRS to see learning activities on different devices as logically being the same activity. This allows for a learner to transition from one device to another with the same activity, and for reporting to work on the whole activity or to be broken out to see where and how people experienced the activity.
What are your thoughts on how the Tin Can API handles platform transitions? Leave your thoughts and comments below.
| <- Previous | Next -> |
| Track offline/long-running content | Better interoperability |