Edited, April 21, 2013: As I have observed the evolution of the Experience API (AKA the TinCan API), I have come to believe that it is the first steps toward the future of learning, and even other forms of online interaction and collaboration. See my comment below. Dave Smith
I have been thinking about this post for a few weeks now. I hear so much about how great the new Experience API (also know as the Tin Can API) is or will be. To this I say, I agree. The concept of providing a means of integrating disconnected learning with traditional online learning is powerful. Where I draw the line is when I also continually hear Tin Can being described as the next generation of SCORM or the future of online learning.
In this article, I am going to give opinion, my opinion. You can read here what I think the Experience API is and what it is not. As you read on, you will also hear why I think it is a parallel effort that needs to be developed to its full potential along side of the existing SCORM standard. I am amazed at what Experience is not.
Please read along with me and add comments about your understand of Tin Can.
First, let’s talk about what the Experience API is. It is a standard methodology for registering, collecting, and (eventually) reporting on events. That’s it! That’s all it is!
Does this mean that it is not useful or important? Certainly not! In my work as a developer of an online Learning Management System (LMS) and course-ware authoring tool, one of the frequent, recurring requests that I get is, “How do we integrate our classroom training and other offline learning events into the reporting piece of the LMS?” Training professionals want to be able to go to one place and see a complete picture of their learning program. It is my belief that Experience includes the promise of reaching this goal. To this end, we at Brindle Waye are actively engaged in learning how we will best hook our tools up to the Experience API.
I must admit that I get a little turned off when I see a facetious example of a Tin Can statements such as “Dave ate an ice cream cone.” While this is valid in the current definition of Experience, it belittles the value of the tool. The heart of Experience is the Learning Records Store (LRS). Don’t be confused; an LRS is nothing like an LMS, although they might work together. Using Experience statements, your tool, whether it is a full LMS or a mobile app running on your iPad, can input data into this “database.” That much of the standard is pretty much tied down and defined. The part that is yet to be seen, in my eyes, is what we do with this data once we collect it. The challenge that lies ahead is how we use this storehouse of data to build a better reporting tool that incorporates learning in all of its forms.
Now let’s talk about what the Experience API is not. Primarily, it is not a learning delivery standard. SCORM defined ways that we can deliver training content in formats that are understood by software that was not written by the same company that created this content. As the first word of the acronym says, it is a way to share content among tools and vendors. We can argue about how effective it has been in reaching this goal, and I agree that there are strong arguments that it is not that much of a success. Apart from whether or not SCORM is being adopted widely or used correctly, it is a good standard for creating share-able content. Experience says nothing about content or how it is formatted. As I said in the beginning, it is nothing more than a place to record that something happened – thus the name “Experience API.”
I hope that my ramblings here have brought home that Experience is not a replacement for or a next generation of SCORM. It is a new standard that promises both powerful benefits and significant challenges.
Those are my thoughts. Please share yours with me.