Last week [October 25th] I had the distinct privilege of sitting in on the Tin Can API break-out session that was presented by Aaron Silvers of ADL. I’m not sure of his exact title, but his role was in a leadership capacity on the Tin Can API project. His business card says “the Beard”…and while that was accurate, I still don’t know his real title. Given ADL was also the birth mother of SCORM, I walked in and sat down with a preconception or two that this was SCORM in a new dress. Wow, was I wrong!
I confess to ripping off one of Aaron’s quotes that Tin Can API was…”the ability to track things that are more granular and useful.” When I wrote it down I was still in the mindset of SCORM and SCOs and tracking training transactions, and such. I was still feeling constrained by being in the shadow of SCORM. Again, I was wrong. I’m reminded of a record album from years gone by, “Twins Sons of Different Mothers”…Tim Weisberg/Dan Fogelberg…yeah I know, just dated myself, but it describes the relationship between SCORM and Tin Can API. While the two are “twins” in the sense of being related to learning, they truly are borne out of a different lineage.
Sure, that’s a silly example, but I think it is essential that we put our thinking about Tin Can API into a different perspective. We have to view Tin Can API through a different lens. If we do not, our current Training paradigm lens will limit our future applications of the API, and it may very well restrict our “vision” of where it could go by being stuck behind the walls of the SCORM box we’ve been in for so long.
Tin Can API is NOT the next version of SCORM. Speaking of being stuck “in the SCORM box”, a discussion thread surfaced this morning in one of my networking groups. A colleague was looking at Tin Can API as an enhancement to SCORM, and the fact that Tin Can would enable tracking social learning activities would ultimately limit the effectiveness of social learning by the fact that we were tracking it. He was clearly looking through the SCORM lens and was not impressed.
On one hand, I could agree completely about how “in a box” we are with the thinking SCORM supports; up until last week, that is. I held those same beliefs that Tin Can was merely lipstick-on-the-SCORM-pig. It appeared that it was an attempt to track “other things” including social learning activities. As I sat in the Tin Can API break-out session last Thursday, my concept was changed by Aaron Silvers, the ADL Project Lead for Tin Can. The first thing that was changed was the name of the API… from Tin Can API to what it will be known formally as… “EXPERIENCE API” or simply xAPI. I could not help but take a sip of the Kool-Aid at that point.
Now I confess to NOT being an expert on SCORM or Experience API, but I’ve been a training expert living and operating under the constraints of SCORM for many years and have seen where traditional transactional learning approaches just cannot go. The ability to “track things” seems to be an obsession. In compliance cases, I realize we have no choice, but the tons of butts-in-seats and course completion data we can get from the LMS justifies [outside of compliance reporting] only that we’ve been busy…not a whit of proof that any knowledge transferred is being applied in an impactful way…least-wise sustaining human performance at the point of work.
Experience API is not about “content” like the LMS. When Aaron said this, he had my attention. I took another sip of Kool-Aid. The LMS is all about content. Take content out of the LMS equation and you are left with a SCORM-compatible, digital boat anchor. Aaron’s quote I ripped off [second paragraph] was what gave me a new lens to look through and it totally tracked with the new name for the API. This was not so much about “tracking learning content transactions” as it was shining the light on “what people experience” during the learning process on their journey toward competency…hence the new name Experience API. We are finally unshackled from the limits of SCORM and the LMS…to expose user-level data on learning experiences that have nothing to do with LMS or SCORM-based content consumption. I took a much bigger sip of the Kool-Aid.
Then Aaron described how Experience API could be integrated with Activity Streams as a new component of significance. While it’s true that activity streams can bring a lot of nonsensical nuggets of crap-that-wastes-your-time to you in a Facebook or Twitter world, and, in some cases, in a LinkedIn world, but…with a little innovation and the Experience API, what if those “social platforms” were in-house and focused and filtered on only the social learning aspects of workplace and performance workflows?
What if the “social” relationships were peers within a specific clinical discipline…or a research & development discipline…and yet still scattered all over the globe?” Or what if the peer groups were first-line managers working through a leadership development effort in a post-training, collaborative, and geographically-dispersed environment? What if we [as the Training and support team] had a need to harvest user-generated best practices or home-grown job aids that invariably sprout from within the point of work?
No LMS could ever hope to go there. This is so far outside of the vision of SCORM we cannot even fathom tracking it…or for that matter having the inclination to consider tracking these kinds of activities…these kinds if performer/learner-centric experiences. Is this…then…not a new paradigm? Take a sip with me.
Aaron had me at “This is not the next generation of SCORM; it’s what comes next in the evolution of learning.” That may not have been his exact words, but it’s what I heard, and being a passionate advocate of performer support I feel he should have added “and performance” to his description. SCORM cannot go there. The LMS cannot go there. Step away from the technology. Embrace the learner/performer and their work context. This is not a technology play. The technology cannot go there…BUT…our learners CAN…our performers DO…and Experience API is the tool that puts a new face on an evolved data set. I suppose you could argue it is still in-a-box, BUT…it does not force the learner…nor the performer…nor the learning environment into a box along with the data. Instead, Experience API exposes user data that has never been available to us before…ever.
Great…more data to track. Maybe, maybe not. Does everyone need to track this kind of thing? Absolutely not, but as a professional in the Training business would you not want to “see” the experiences of your learner/performer population as they progress toward competency at the point of work? I’d love to know that a threaded discussion wrestled over something I could address with a enhancing tweak to some existing training…or push a PS job aid object to a select peer group to resolve their issue. SCORM could never give us that, but Experience API makes it possible.
That’s when I finally “got it”. I became a convert, was no longer a doubter, and had no choice but to drink all sixteen ounces of the Tin Can Kool-Aid. I have another recent post on this topic that addresses what I see as a really big deal going forward regarding performer support – “Tin Can & Performer Support – Just Enough – Just in Time – Just for Me”.
Again, I am not the Tin Can API expert, so if you want to dig deeper you should hit the Tin Can API website by the good folks at Rustici Software. They won the ADL contract to productize Tin Can API and are an excellent source of information. In terms of timing, Aaron said the formal release of Experience API will be early next year; March/April 2013. Many authoring platforms and LMS vendors are already offering Tin Can API compatibility options, but I caution not to get wrapped around the LMS axle when you start envisioning where this API will enable you to go. This is all about the individual learner/performer’s experience as they learn…not the content…and not the boat anchor…err…the LMS.
This is exciting! C’mon…take a sip!