Tin Can has been getting lots of people in a twist lately. Early adopters are tweeting and blogging about it and anyone who’s anyone seems to be dropping it into conversations to prove they’re at the cutting edge of learning technologies. It is certainly doing the rounds as the Next Big Thing. But ask anyone, “What is Tin Can? Explain it to me” and more often than not you’ll just get a shrug of the shoulders and a quizzical look.
This is because Tin Can API is pretty confusing to the newcomer. I can vouch for that because I am a newcomer to it myself. This blog post is my collected notes and thoughts from one day spent learning about Tin Can API. It’s become pretty clear over recent weeks to me that most people understand that Tin Can API is the next version of the SCORM standard, but few people realise that it is still only at the DRAFT stage. There is a high level of vendor ‘early adopter’ activity with technology companies implementing the draft standard but there is also a high level of vendor hype with people like Articulate touting Articulate Online as a “Tin Can API-supported learning management system”. The level of hype makes it sound more real than it is, and the race to innovate seems to have taken the standards definition squad by surprise. While these people are still working on the final revisions to the draft specification, the hype in the vendor market is leading e-learning practitioners to eagerly search out press releases and marketing material that just aren’t ready yet.
So what exactly IS Tin Can API?
We have to start with SCORM. The SCORM standard is all about tracking the status of big and chunky e-learning modules, with the e-learning module and the learner record usually residing in a single LMS or Learning Management System. Tin Can API however, rightly recognises that most learning happens away from the LMS. So the focus has moved away from e-learning modules towards learning activities, be these offline or online, tutor-led or collaborative, real-world or virtual. It doesn’t matter where the activity takes place; what matters is that some remote system with knowledge of that activity can send a simple statement to a central learner record store (LRS) containing some very basic details of what the learner did. That’s why it’s called Tin Can API – the API stands for Application Programming Interface. API’s are used everywhere in IT – they handily provide a common language to allow unrelated systems to talk to each other. For example, a library system could use Tin Can API to send a statement to an LRS to say that a learner borrowed a book or a journal. The statement itself is a very simple one in the form of ‘noun – verb – object‘, for example ‘Mark borrowed Book X’ – it’s as simple as that.
So what can Tin Can API be used for?
Think about the possibilities. You could create Tin Can API services for an almost endless list of tools such as Twitter, Facebook, Google+, event management systems, learning management systems, Slideshare, YouTube, Yammer, library management systems, blogs, social bookmarking tools, all sorts of learning and productivity tools. These would all send small activity records to the LRS such as:
- I watched/uploaded/commented Video A on YouTube
- I borrowed Book B from the library
- I attended Conference C
- I posted Status D to Facebook
- I tweeted Tweet E to Twitter
- I scored 50% in an online quiz
- I completed e-learning F in Moodle
- I bookmarked Website G on Diigo
- I joined Group H on Yammer
- And so on…
There will be plug-ins and apps galore to help learners record their learning – Rustici have already released an ‘I learned this’ browser bookmarklet and a book barcode scanner that both send Tin Can API statements to an LRS. Well, THEIR commercial LRS. But where they have started, many others will follow, hopefully allowing learners and IT administrators to point the statements towards an LRS of their choosing.
It sounds great, so who is behind Tin Can API?
In simple terms, the US Department of Defense is behind Tin Can API. They run the Advanced Distributed Learning (ADL) initiative, which aims to “standardize and modernize training and education management and delivery”. As guardians of the SCORM standard, ADL have had a huge impact on the e-learning industry, far beyond the confines of the DoD. ADL’s current focus is on personalised, just-in-time learning and part of their vision includes “greater communication between systems and content types and tracking learner activity including non-linear learning experiences and social media interactions.” To this end, the current SCORM standard simply doesn’t cut the mustard any more.
Enter ADL’s new initiative: ‘Training and Learning Architecture‘. This consists of a number of projects including the Experience API (Tin Can API), Project Tin Can and the Learner Record Store (LRS). Forget about Project Tin Can, it is superceded by the Experience API (Tin Can API) project. Those other two projects we already know about. Bizarrely, the API project is very confusingly referred to by two names – Experience API and Tin Can API – heaven knows why but let’s just say no technology standards body has ever got an award for its marketing prowess.
So ADL are behind the draft standard, but they didn’t write it. They actually went to the market and offered funding to define the new standard. To do this they issued a BAA, which is basically an invite to tender for the work. That funding was won by a company called Rustici, who spent a year writing the draft specification. This was then delivered to ADL who put it out to the open community for review and revision. And that’s where it is now, at version 0.95.
Rustici remain closely involved in the process and are providing support to early adopters, particularly authoring tool and LMS vendors who are implementing the draft specification. I spoke to them last week myself and they were exceedingly helpful. They are also providing their own commercial LRS product and TinCan API plug-ins and are therefore investing in marketing effort around these, which has certainly contributed to the buzz and the perception among my colleagues that TinCan API was market ready. Rustici’s overview of Tin Can API – they purchased http://tincanapi.com/ to spread the word – is miles better than the ADL site, so I would recommend that as the best place to get in-depth about Tin Can API in layman’s terms. Rustici’s main commercial website is actually http://scorm.com/ – these folks really love their SCORM! But it’s important to make the distinction that Rustici are a commercial venture involved in SCORM technologies and received funding to draft the Tin Can API standard – which is all completely fine and above board. But it is ADL who are managing the definition or the Standards. This had a few people confused that I spoke to, so it’s important to clarify.
What is the current state of Tin Can API?
So as at Oct 2012 we are currently in the specification review and revision stage.
- Tin Can API is a Draft Specification currently at v0.95.
- ADL should be publishing v0.98 by end of 2012
- ADL should be publishing the final v1 specification by end of Q1, 2013.
A key reason we are hearing so much about the API already is that some vendors are already implementing the Draft Specification. Foolhardy? I don’t think so. These people are betting that Tin Can API is going to be a game changer in learning technologies, and I think they are right. These vendors are very firmly in the ‘early adopter’ category and are undertaking this work on the basis that there will be some movement in the Specification between v0.95 and v1. However, as significant efforts were already made to pull any major changes into v0.95, the hope is that any remaining movement will only be minor refinements.
Tin Can API: “tracking the bejeesus out of everything!”
So that’s the lowdown on Tin Can API as far as I understand it. I invite comment and corrections and will amend my lowdown accordingly so please enlighten me if I missed anything. But before blindly accepting all this as the future of learning technologies, let’s spare a thought for @craigtaylor74 who tweets that he is “Hearing more & more about tracking the bejesus out of everything, wrapped up in the ‘Tin Can’ guise!” The man has a point. You have to ask why we need to track all this data and what use does it serve. ADL are backing it because they think it will lead to a future of personalised, adaptive, just-in-time learning. Others will see a definite big brother angle to all this tracking.
There’s a possibility we are obsessing over the ability to track everything we learn, when what is more important is determining our learning NEEDS. I recently saw a video of work.com, the social performance management tool from Salesforce.com. It was pretty awesome, and totally focused on tracking employee GOALS and rewarding them for meeting those goals. Learning activities were not the focus, there was no ‘Jonny did this’ or ‘Mary did that’. It was all about ‘Mary met her goal’. A manager needs to know that an employee has met their goals and have visibility of failures so that learning needs can be established and met, and THAT’S where the focus on learning activities comes in. It’s not much use a manager knowing about every minor learning activity their team took if they don’t know how they are performing.
There’s a danger of being led by the technology here and that by focusing relentlessly on methods to track learning activities we will go down the wrong path as workplace learning practitioners. We need to make sure we are following best practice, user-centred design principles to stay on the right track when designing these new systems and architectures. When I first saw work.com it was clear that these people totally understood their users and hence their focus on goals not activities. So that’s my next big challenge. We are starting work at Epic already on implementing Tin Can API for GoMoLearning and maybe for Moodle too. So my challenge is to ensure we do this in the right way, led by the needs of our audience rather than just being wowed by the technology.