How Can You Use The Tin Can API In Your Informal Learning Networks?
In part 1 of this series (ref The Tin Can API – Why Should eLearning Professionals Care?) I shared with you an audio recording of the interview I conducted with one of the contributors to the Tin Can API consortium. In that interview, Ali Shahrazad from Saltbox Services helped us gel with the basic relationship of the Tin Can API (a.k.a. “Experience API”) to a central data repository called a Learning Record Store (LRS).
We learned that Tin Can is a new API (application program interface) standard that lets you, me and other vendors (of, say, LMSs, eLearning authoring tools, CRMs, websites, custom applications, etc.) send information about activities by our users within those various platforms to a Learning Record Storage (LRS) database. Once in such an LRS (which itself can be a hosted service or an otherwise proprietary toolset including the LRS with reporting, visualization or other analytics tools built on top of it), we can then analyze that information to get more robust insights of activity-type information about how users use (Tin Can developers like to say “experience,”) those various platforms.
In this second part of the 4-part series, I’m including the audio interview I conducted with representatives from Callidus Cloud — the company that creates, among other things, the hosted LMS platform I’m currently using with one of the companies I work with.
The audio’s a little hard to decipher in a number of spots. So I included a transcript of the interview immediately below the audio file.
This interview reinforces the concept of Tin Can being primarily a conduit (think: plumbing) via which to send/receive user activity information from various Tin Can-enabled software. (Those software become enabled by developers integrating Tin Can API code with the basic workings of the software.)
Interesting, too, is the observation by the folks I spoke with at Callidous Cloud that Tin Can is just another form of SCORM. I thought that statement would probably make the Tin Can consortium folks bristle. But, I also didn’t think it was a description that was too far off base. Yes, yes, Tin Can is different code than SCORM. And yes, it’s designed to work with a wider set of platforms than LMSs. But, I see their point: like SCORM, Tin Can is essentially a standard code set that all developers of eLearning-type software (and I’m using that term loosely as such software can include social networks, CRMs, and such) can use to send and receive information about user activity to another thing. Also, just as SCORM information is essentially useless without an LMS, so too is Tin Can information essentially useless without an LRS.
But, take a listen. And then share your own thoughts: What do you think? Is Tin Can, indeed, just SCORM on steroids, as some might say?