The floodgates are open. It’s time to celebrate. The Tin Can API, version 1.0, is here today.

It was almost three years ago when ADL asked the e-learning community to help them with research to create a new, simpler, more powerful e-learning standard. E-learning standards are what we do, so of course we jumped at the opportunity.

The result was Project Tin Can, which resulted in the Tin Can API. We wrote the first version of the API, version 0.8, then handed it over to ADL and a vibrant open community.
MORE…

I did a webinar for HR.com on April 15th. As usual, the attendees had more questions than could be answered in the allotted time, so I’ve taken posted the questions and answers here.

Q: I love the concept, and would like to break out of the LMS confines and track other external content, but not sure how/where to start

We hear this question a lot. There is so much that Tin Can offers, implementing all of the possibilities is a daunting task. Fortunately it’s easy to start small. In every organization we’ve worked with, it has been easy to identify 3-6 pilot projects that are small in scope, but provide a big impact and lots of visibility. Take on a mobile learning project, or incorporate a game into your training program. Find an area where you can easily measure business performance and correlate training data with improved performance. Consolidate data from several LMS’s into a LRS, or use a TDS to deliver training from anywhere. Feel free to give us a call, we’re happy to help brainstorm the possibilities.
MORE…

Attendees of the 4/4/13 “Tin Can in the Real World” webinar had a few questions that we couldn’t get to “on air”, so I’ve answered them here. There’s some good info in here, even if you couldn’t attend the webinar.

Q. Are there best practices for making information user-specific? When Mike was talking about QR codes, how does the individual’s user-specific data get added from a scanner application?

A. At this early point in Tin Can’s life, I’m reticent to call anything a “best” practice yet. There are plenty of “plausible”, “demonstrated”, “functional” and “promising” practices, but it’s too early to know what is “best” yet.

In this particular use case, I would imagine that there is likely an app on the user’s phone that is preconfigured with the user’s identification. The app would likely have been authenticated against the LRS when it was installed, probably using OAuth.

Alternatively, a standard QR code reader could be used that brings up a web browser. When the user is first redirected to the web page providing the training or assessment, the user could be prompted to login with his/her network access credentials.
MORE…

Attendees of my Training Industry webinar on February 26th had quite a few questions about Tin Can, but I couldn’t get to all of them during the webinar. So, I’ve compiled your questions and I’ve answered them.

Even if you didn’t attend the webinar, you’ll still find lots of good info here.
MORE…

“Tin Can API” vs “Experience API”
You may have heard that ADL issued an official name for the Tin Can API. They call it “The Experience API”.

This move is generating a lot of confusion. Is it the “Tin Can API”? Or, is it the “Experience API”?

Rustici Software is going to call it the “Tin Can API”.

Unfortunately, as a government organization ADL has to play by a stricter set of rules than the rest of us. Bureaucracy has them stuck with an official name of “Experience API” that they commonly refer to as “Experience API (Tin Can)”.

We gave it a lot of thought. Here’s why we are sticking with “Tin Can”:

• There is too much momentum behind the name “Tin Can” for it to change now. “Tin Can” is what people know. It is what the community wants to call it.

• ADL will be transferring ownership of the spec to a public standards body after v1.0 is complete this Spring. After that transfer, we don’t expect the official government name “Experience API” to last much longer.

• From a branding perspective, “Tin Can” is a better, more identifiable name.

• It would require a large effort for the community to effectively rebrand itself. Those efforts would be better used to improve the spec and encourage real adoption.

Why Rename the Spec?
In 2010, ADL issued Rustici Software a research grant to propose an experience API. This experience API was the first requirement for creating ADL’s “Training and Learning Architecture (TLA)”.

Rustici Software conducted that research project under the codename “Project Tin Can” and submitted the “Tin Can API” as the result.

ADL looked at the “Tin Can API” alongside several other options and decided that the “Tin Can API” best fulfilled the requirements for its experience API component of the TLA.

Thus in the bureaucracy’s eyes, there is a master plan for a Training and Learning Architecture that contains an experience API. In today’s incarnation, the “Experience API” is currently implemented by the “Tin Can API”. It is conceivable that at a later date, the requirements of the experience API could be fulfilled by a different protocol.

In their eyes, it’s not a new name, it’s just the original official name.

Meanwhile, the industry recognizes that the “Tin Can API” provides a solution to many of its problems and continues its rush to adopt it.

Is Rustici Software’s Decision Final?
No decision is ever final, but “Tin Can” is what we are going with for the foreseeable future. If reason #1 above changes and the community decides to call it “Experience API” we will likely go along.

A Word About Trademarks
As part of Project Tin Can, Rustici Software applied for trademarks to protect the name “Tin Can API”. The USPTO is currently processing these applications and we expect formal trademarks to be awarded soon. In May 2012, Questionmark raised some very valid concerns about our ownership of these trademarks.

We publicly stated then, and will reiterate here, that we consider these trademarks to be property of ADL. We have already asked ADL to begin the process of transferring them to government control.

Rustici Software has no interest in maintaining proprietary control over these trademarks nor do we have any intention of using them for competitive advantage. We simply registered them because we felt it a prudent part of our research project to protect the resultant intellectual property. We were following the precedent set by CTC when they developed SCORM many years ago.

As we stated in May, if you would like for us to provide more explicit and legally binding assurances regarding use of the Tin Can trademarks, please just let us know.