The Tincan API resulted from several deliberations on SCORM 2.0 over the last five years. The standard is developed by the company RUSTICI but ADL is still the steward of the specification, just like SCORM. The Tin Can API is community-driven, and free to implement.
At its core, TinCan is a messaging system. You collect messages in the form of JSON statements about what your learners are achieving while learning or playing or interacting with other people. Those statements are stored on what TinCan calls LRS (Learning Record Store). The LRS can be either standalone or part of an LMS. The standard doesn’t touch on how you go about translating those messages into something useful. In its simplest form you simply present the statements in the form of “Noun, verb, object” or “I did this”. It is totally up to the LRS developers to make use of this data in any other way they see fit.
Compared to TinCan, SCORM was a very complex standard. It took our team around 8 months to build a SCORM 1.2 engine and more than 16 months for the SCORM 2004 / 4 edition. On the contrary, we spent only 1 month to complete a basic TinCan implementation for use with eFront and TalentLMS. Perceived simplicity is a core ingredient of the new offering and a major adoption point for LMS and authoring tools developers.
A nice side-effect of the messaging system is that any enabled device or program can send Tin Can API statements (mobile phones, simulations, games, real world activities etc.). On the contrary, SCORM was browser and LMS based only. As TinCan project put it “People learn from interactions with other people, content, and beyond. These actions can happen anywhere and signal an event where learning could occur. All of these can be recorded with the Tin Can API.” This openness is very important and in our point of view, the biggest benefit that TinCan brings to the world.
TinCan also claims improvements on another commonly required but rarely delivered functionality – the ability to complete learning objects offline and synchronize when you get online. Even when not working completely offline people ask for better support for browser timeout and connection drops. SCORM depends on the browser session and such issues are common and catastrophic.
In reality, the new API offers little real help on this front. However, since the communication happens through simple messaging, client programs can easily store the messages when offline and communicate them to the LRS whenever the user returns to online status. No matter how basic this seems to be an efficient solution. Never underestimate the power of simplicity!
TinCan is very cryptic on a few prominent elements on SCORM like Packaging. The reason is that you might not need Packaging at all. Your learning object might be a mobile application or a game that does not run inside an LMS; Packaging has no value on such a loose-end environment. If you choose to import a TinCan package to your LMS though then yes, you will need to deal with content packaging, launch and import issues.[i]
TinCan has also little to do with the complexities of things like Sequencing. Do you remember what SCORM’s 2004 sequencing was? Let me refresh your memory…
“In SCORM 2004, the sequencing is completely dynamic; the sequencing implementation identifies the next activity based on both Tracking Model and Sequencing Definition Model of activities. In fact, the values of Tracking Model are dynamic but the values of Sequencing Definition Model are static. Actually, in SCORM 2004, the sequencing implementation collects the result of learner interactions with SCO (through CMI data model) and maps them to the Tracking Model and then evaluates the sequencing rules (defined for activities) based on the Tracking Model.”[ii]
This sort of complexity led to very low SCORM 2004 adoption. From our experience over 90% of SCORM is still 1.2. Perceived simplicity is the reason. People just want to grab the raw score. The other things that SCORM 2004 offers are often in surplus to requirements. People often require SCORM 2004 support but rarely use it.
Our biggest complaint with SCORM was that it is a reference model and not truly a standard; you don’t plug this into a wall and everyone works the same way. There is still too much variation in how compliant SCORM LMSs implement UI associated with the SCORM RTE. Will content be loaded in a new window? A frameset? How large a window? How will the table of contents be presented? What navigation request does closing the browser imply? Content authors should be able to rely on a consistent set of UI expectations.
Unfortunately, TinCan does not help towards this standardization. On the contrary, it leaves even more freedom to content creators by letting them, for example, define their own verbs used on statements. Interoperability of content between LMSs can be somewhat improved due to the simpler messaging system and absence of Javascript; however, standardization of presentation or reporting will not be benefited from TinCan directly.
To summarize, TinCan brings many good things like simplicity and freedom from the browser and the LMS. On the other hand, it falls short on standardization of UI and reporting. In essence, TinCan tries to bridge elements of formal learning (mainly Reporting) with informal activities (e.g, browsing or game playing). We can foresee additional tools or sub-standards on top of TinCan to address real world issues especially with reporting and standardization of the verbs on statements.
