Update: The Output of Project Tin Can is Experience API.
Tracking Offline/Long-Running Content
Most previous e-learning specs require a constant connection to track content. Content can be suspended and resumed later, but the content can’t be experienced offline while it’s suspended. An LMS can provide an offline version of its API so a user can experience content offline, but it requires extra work for the LMS and not every LMS offers this feature.
LETSI RTWS gets around this limitation by making it possible to create a proxy for the content to communicate with, and the proxy can communicate with the LMS. It’s an elegant solution, but it does have one slight limitation — content has to be launched in a connected environment before it can be taken offline.
The work that we did with the Tin Can API in this area was based directly off of previous RTWS progress. The Tin Can API offers the same capabilities as RTWS, but takes it a couple of steps further. A piece of content/activity that uses the Tin Can API can be smart enough to detect whether or not it has a network connection. If there is no connection and the content/activity has its own storage, it can store data locally and transmit back to the LRS when a connection is present. Plus, activities can start offline, unlike RTWS.
The nature of the Tin Can API also makes it great for tracking long-running content, where it’s impractical to keep a SCORM session open for weeks at a time. Think of a simulation or serious game that a user might interact with over a period of days or weeks — it shouldn’t be re-launched from the LMS for each interaction. The Tin Can API provides for a good solution to this problem.
What are your thoughts on the Tin Can API solutions to tracking content offline, tracking intermittently connected content, and tracking long-running content? See the comments below to see how we got to where we are today, and add your thoughts/concerns to the list.
| <- Previous | Next -> |
| Track real-world activities | Platform transition |