Introduction to Tin Can API
Wait, so what is it called again?
As it happens, the standard is now known as Experience API (Tin Can was the project name). So while a lot of people use these names interchangeably, Experience API is the more correct name according to Ali Shahrazad, the co-founder and COO of Saltbox. You'll often see it referenced as xAPI in forums and the like, but people will know what you're talking about if you call it Tin Can.
I'll use all three terms (Tin Can, Experience, and xAPI) interchangeably.
The Basics: What is an API?
Let's take a quick step back: "API" stands for Application Programming Interface. This is where it gets a little squishy for me, but an API is basically a standard that allows programs and software to speak with each other. How Stuff Works describes an API as "a set of programming instructions and standards for accessing a Web-based software application or Web tool. A software company releases its API to the public so that other software developers can design products that are powered by its service."
A lot of the big companies you know release APIs -- Facebook has an API so companies like Zynga can develop games for Facebook. But everyone else has one too -- Google, Amazon, Twitter, and WordPress to name a few. A good, easy-to-use API is really key to wooing developers to create programs on your platform.
OK, so then what's Experience API?
Similar to the APIs we mentioned above, Tin Can was developed by a company. A private company called Advanced Distributed Learning (ADL) took a leadership role the development process of Tin Can, thinking that it could be a really great way to learn more about what's going on within an organization's learning environment.
In short, Tin Can was created to allow you to track more information about the learning behavior of users than was previously available. The existing standard, SCORM, can really only track what's happening inside an eLearning course--who takes the course, how well they do on the assessment, and things like that.
Experience API was built to expand on that and learn even more about a user's learning behavior. Curious to know how your employees are learning about compliance policy? Want to know how many people are using the wiki you created to access operational procedures? You may want to explore the Experience API.
Want something more specific? Here's an interesting use case: xAPI can also be configured to collect information from several LMS's. When I spoke to Shahrazad, his company was working on a project for a major retailer to gather information from multiple LMS's and deposit it into one central repository. They were able to use Tin Can to make this happen.
Well, wait. Doesn't SCORM handle all the data I need to track learners?
In a word, no. Much of SCORM was developed before the widespread adoption of informal/exploratory learning and has a lot of drawbacks in these areas. For example, did you know that SCORM only works when you view a course in a browser? Not only that, but the browser has to be launched from the same domain as the LMS. If you're in an office that's usually fine, but it's not very flexible for a mobile workforce. Additionally, mobile has a hard time accommodating for those limitations. It can do it, but it's a challenge.
The Tin Can API offers some flexibility in that it allows you to do things like track and deliver eLearning in a native application, instead of a browser. Chris Tompkins from Rustici Software explains further:
"Using the Tin Can API, you can take a more modern approach. For example, you could build an iOS app that does not care about any of the limitations of SCORM. You could build a game, tool, learning experience, whatever... and use the Tin Can API to communicate to any LRS that wants to collect the learner's interactions with that app. It's far more flexible than SCORM."
SCORM was really built to manage communication between a learning object (a course) and a Learning Management System (LMS). Tin Can, on the other hand, can track many other things. Let's say you were learning about sharks and accessed your company's wiki on hammerheads--that's something Tin Can could potentially track. All this information would be stored in an LRS - a Learning Record Store that is unique to each user.
OK, so how does Experience keep track of all this? And what is an LRS?
Well, the LRS is really the key to Tin Can. It's an individualized record of 'events' for each user. When you roll all these Learning Records together, you can learn some interesting things about the way learning is being done in your organization.
The LRS allows your computer to create and transmit a series of statements in the background. One of the main features of Tin Can is that the way these statements are created, sent, and interpreted is standardized. This saves a great deal of time for developers, who might have previously needed to create manual solutions to facilitate data migration, according to Shahrazad. This can be a costly and time-consuming process; it's envisioned that Experience will greatly streamline the process of sending and receiving of this sort of data.
What you do with all that data is up to you--finding the best ways to extract meaningful information will be an entire challenge in and of itself.
Will Tin Can API replace SCORM?
Maybe. At current, Tin Can wouldn't replace SCORM (some dispute this), which still has value in tracking activity within a learning object. However, Tin Can would add additional functionality and reporting capabilities that SCORM cannot handle.
At present, Experience can be a great complement to SCORM and traditional LMS setups. In the future, though, it could potentially replace the SCORM compliance standards. Shahrazad explains it like this: SCORM was great when most eLearning took place in an office environment with each user at a desktop computer. Now that the avenues for learning have changed, a more robust standard is needed to keep track of it all.
Shahrazad also spoke briefly about an interesting use case: using Tin Can to consolidate information from multiple LMS's. (He'll be speaking about it at DevLearn, too!)
Should we use the Experience API at our organization?
Maybe! It all depends on what kind of information you're trying to get at. For some smaller companies that don’t do too much mobile learning or have a need to track this behavior, you're probably fine as you are. (If you dispute this, please leave a comment! )
If you're interested in collecting a rich variety of data about your user base (and are in a position to take action based on the results), then maybe you should consider leveraging Experience. I'm sure our friends at Saltbox, Float, Rustici, or any of the eLearning companies that support Tin Can implementations would encourage you to explore the possibilities, as well!
Rustici Software has a nice overview of Tin Can here.
Did I miss anything? Grossly misrepresent something? Send me an e-mail at <my full name> at g mail dot com and I'll try to sort it out.