Project Tin Can Requirements

Project Tin Can identified a number of requirements which we set out to solve; these are listed below. You’ll recognize some of these from the overview of xAPI today (Project Tin Can evolved into the Experience API or xAPI) and perhaps also notice some additional benefits of xAPI that weren’t envisioned at the time!

It needs to be simpler

Traditional learning standards are complex, so it takes significant time and cost to become conformant. Tin Can was designed to be as simple as possible, while remaining flexible enough to handle more complex scenarios.

Removal of the need for an internet browser

Not all learning happens in a web browser.Tin Can was designed to work with native mobile (and desktop) apps, simulators, serious games and physical hardware.

Distribution of content/cross domain

With SCORM, content has to be uploaded to the LMS, which is a real pain if you want to put the same content on several LMSs and keep it regularly updated.Tin Can was designed so that learning experiences could sit outside the LMS and report data back.

Access to more data

Most learning specs don’t require that runtime data be stored after a piece of content is completed, but that detailed data can be very useful for analytics and feedback.Tin Can records learning events as an activity stream and the data is available no matter how many times the learner repeats the experience.

Need to be able to use “user defined variables” in content

When you’re designing a learning experience, it’s not uncommon to need to store some piece of data that specification authors hadn’t considered. Tin Can includes a lot of flexibility allowing you to store additional information beyond the core data points defined in the specification.

Learning that’s not initiated in an LMS

The nature of the Tin Can API means that learning doesn’t have to start in an LMS. In fact, the LRS doesn’t even need to have prior knowledge that the activity or actor (learner) are involved.

Simulations and serious games

Simulations and serious games have been used in learning for some time, and the tracking and reporting has largely been limited to the proprietary systems in which they live. Now these activities can be tracked with the Tin Can API, allowing data from these experiences to be analyzed alongside other learning experience data.

Track real-world activities, not just digital ones

Traditional learning specs track digital actions like when a course has been completed. What happens when you want to verify that not only has someone learned a skill, but that they can perform it in the real world? What happens if you want to record a real-world (not necessarily e-learning) event such as classroom participation? The Tin Can API offers up methods to integrate and correlate real-world activities with digital learning.

Need to track offline or long running content

Most previous 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. A piece of content/activity that uses the Tin Can API and has its own storage can store data locally and transmit back to the LRS when a connection is present.

Platform transition

The Tin Can API allows for a learner to start an activity in a web browser on a computer and continue that activity later one a native mobile phone app. This is a simple but powerful new capability, and wasn’t possible with any of the older learning standards.

Better interoperability

Interoperability specifications are designed to make two technologies by different vendors work together and one of the frustrating things about SCORM was that it often didn’t work. Content required tweaks to work with different LMSs and LMSs had to be adjusted to play certain content. Often this was due to incorrect implementations of SCORM, so Tin Can was designed reduce the likelihood of non-conformant implementers.

Tin Can gives more power to content creators and is simpler to implement, reducing the scope for error. LRSs are required to validate data and return errors, helping content creators to get things right. In addition, we’re doing a lot of work to support Tin Can API adopters, including providing open source code libraries, prototypes and piles of documentation on this website! Some implementers will still get things wrong of course; we can only do so much!

Instructors/others need to observe/interact during training

E-learning has been a very solitary experience. You take your course or test, then you get evaluated. The Tin Can API opens up new possibilities by getting out of the way and letting activity developers create new ways of interaction between learners and instructors.

Collaboration and team-based learning

Collaborative learning with the Tin Can API means that there can be multiple learners experiencing the same activity. They don’t have to be physically together, and they don’t have to experience the activity at the same time (but they can.)

Team-based learning allows for tracking results of experiences that are had by more than one person, as well as each individual. Statements such as “Team 3 completed special ops training” can be used. This is useful when it’s important to track and report on the team’s performance as well as the individuals inside the team.

“I want to do my own sequencing”

People have many problems getting SCORM 2004 sequencing to work the way it was meant to because of interoperability issues between content and LMSs. There has always been too much room for an LMS to misinterpret the sequencing put forth by content creators.

The problem is pervasive enough that many content creators pack what should have been multiple SCOs into one SCO in order to have a fluid user experience, even though they forgo the extra reporting they get from using multiple SCOs.

Tin Can is designed to allow content creators to manage sequencing themselves, supporting implementers to do what they’re already trying to do, rather than trying to enforce a model that doesn’t fit.

We need security/authentication

It’s pretty well-known that older learning specs lack robust security. Depending on how it’s implemented, it’s entirely possible to be just as insecure with Tin Can. With server side tracking robust security is possible though, allowing Tin Can to be used for higher stakes training and assessments.

Need to be able to “tag” content with skills

One of the requirements identified was the need to tag content. As Tin Can did away with packaging content (content can be hosted anywhere on the internet) tagging content is left as the responsibility of the LMS or content repository. Tin Can does enable tagging of experiences, for example marking a particular job task as relevant to a competency or a quiz as belonging to a particular module.

Read more

Want to find out more about the Experience API? Use the links below to dig deeper…

Or are you ready to move on and find out why you should adopt?

Contact Us