Popularity and adoption of Tin Can API

A new learning technology specification, Tin Can API is gaining lot of momentum. It is a new standard that allows for tracking, storage and sharing of learning experiences practically anywhere and from any device. It captures common people’s learning habits and interactions. We all learn with our communications and interactions with other people, content, systems etc. Our learning is not tied or limited to when and where. Similarly the Tin Can API has the ability to record everything by sending the signals about objects (noun) and their actions (verb) to a Learning Record Store (LRS) and storing the interactions in them.

The fundamental differences between SCORM and TinCan API are:

• TinCan frees the content to live anywhere, and communicate with any LRS, whereas in SCORM the Package Manifest is managed by the LMS
• TinCan uses REST based web service and JSON data to communicate with LRS, whereas in SCORM all communication with LMS is done using Javascript APIs
• Tin Can focuses on Runtime data collection (tracking) and ignores content packaging, sequencing/navigation which were key parts in the SCORM specification

The Tin Can API can easily recognize, track and communicate a wide range of learning activities including Traditional Learning, Mobile Learning, Simulations, Virtual sessions, Gaming, Real-world performances, Social-learning interactions, Offline learning, Collaborative learning, etc. Tin Can API is next generation and evolution of SCORM which is considered to be simple and flexible and uses secure vocabulary. It captures all the activities that happen as part of learning experiences. It addresses almost all the limitations of the previous specifications and is considered to be very robust. It is very flexible and hence can support any type of statements, devices and workflows. Ability of LRSs to be able to store interactions locally and also share with other LRSs across devices, systems and organizations enable people to track and maintain their learning history forever. The Tin Can API opens up a world which can be shared across other tools. This enables our systems intelligence to know and understand likes and habits of each learner based on their past activities and provide relevant suggestions and provide complete solid learning experience to our audience. And their further interaction and capturing of those interactions and processing it improving on it make the experience better and better.

Tin Can API specification is not just at a concept, draft version 0.95 is already out and is getting developed at a fast track with a lot of interest in the elearning community. Some of the key areas where specification is not very clear are reporting and security/verification. Its not very clear as to how would an LRS validate the sanity of the tracking messages (or avoid man in the middle attack), spec doesn’t discusses it, which is a big concern. Similarly in the absence of standardized verbs and results (which was ther in 0.9 but removed in 0.95), the reporting in the COTS implementations of LMS would be quite basic, and majority of scenarios would need customized reporting.

While the hype and adoption for Tin Can API continues to grow, many e-learning technologists and analysts are watching this trend closely and somewhat cautiously. The concept looks very promising and is a great step for the learning industry in future direction, but at the same time some are bit cautious about the unforeseen challenges. The reason for it is that it has been almost 9-10 years when the SCORM 2004 specification was released, but still many organizations and LMS providers are using SCORM 1.2 (and some no standard at all). The adoption of new specifications by businesses and organizations is usually a slow process and when it comes from moving from one specification to another organizations usually like to upgrade/adopt to next version of current specification in use due to familiarity and comfort. Moving to something different (even though it may be nextgen specification) as Tin Can is usually challenging. It would take a while and some mix of successes and failures, before it is widely adopted. Which may be good thing as there would be lessons learned which would ultimately help in robustness of the Tin Can API specification.