Month: May 2012

Something I’ve been hearing about lately is something called, “Project Tin Can,” and it’s been a topic that seems to come back again and again in reference to m-learning. “Oh, I think great strides are being made with ‘Tin Can’,” or “I think ‘Tin Can’ might help to solve that problem in how it relates to m-learning,” I’d hear. I knew it has to do with how scoring and assessments are done, but what is it beyond that? Why should I even begin to pay attention to this?

Of course, I had to start doing some research, because if this is a hot topic that affects m-learning, I need to be on top of it, right?

First, if one doesn’t have an understanding of SCORM, one has to understand that first.  SCORM, for all you technical communicators that don’t know, is best explained by Rustici Software, which works very closely with the ADL who set these standards:

SCORM is a set of technical standards for e-learning software products. SCORM tells programmers how to write their code so that it can “play well” with other e-learning software. It is the de facto industry standard for e-learning interoperability. Specifically, SCORM governs how online learning content and Learning Management Systems (LMSs) communicate with each other. SCORM does not speak to instructional design or any other pedagogical concern, it is purely a technical standard…. The SCORM standard makes sure that all e-learning content and LMSs can work with each other, just like the DVD standard makes sure that all DVDs will play in all DVD players. If an LMS is SCORM conformant, it can play any content that is SCORM conformant, and any SCORM conformant content can play in any SCORM conformant LMS.  (See http://scorm.com/scorm-explained/ for more details)

Okay, so we have a set of standard for e-learning so that all content can work together congruently.

Great! So, why mess with what works?

Well, SCORM was developed about a decade or so ago, and while it’s worked great, a lot has changed in how educational content is delivered. A decade ago, we didn’t have smartphones in the same way that we do now, and tablets were still thought of as either pads of paper or slabs of slate that you wrote on with chalk. Mobile devices took off in the last few years much faster than anyone anticipated.  Obviously, if there are new means of technology, there are also new means of learning and delivering learning content to learners.  ADL, the SCORM proctors, realized that they need to stay ahead of the curve and start looking new solutions as mobile technology started to integrate into daily life.

While I had heard of Tin Can, it most recently was brought to my attention by Chad Udell of Float Learning. Float Learning is hot on the trail of TinCan, as evidenced by their May 2012 newsletter. Chad posted this link on Twitter to the following article by Reuben Tozman of the edCetra Training Blog: Instructional Design Tips for Tin Can, which talks about how Reuben and his company started to use Tin Can to start using methods that had their foundations in SCORM for a project, but ultimately needed the flexibility of Tin Can to evolve and progress with the project. I also looked at this article by Ben Clark of Rustici Software, as posted by Aaron Silvers of ADL on “What is Project Tin Can?“, which basically outlined what Tin Can was in broad terms, but it wasn’t completely clear to the “lay person” like me.

The most helpful thing in helping me understand what Tin Can is was to listen to episode #7 of “This Week in M-Learning” with RJ Jacquez and Rob Gadd, which can be found either on this website or on iTunes. They had Aaron Silvers and Jason Haag of ADL as guests on the show, and being that both Aaron and Jason are very much part of and deeply into the Tin Can project, they were excellent sources to consult.

The following are the notes that I took from the conversation (and hopefully I’m summarizing and paraphrasing most of the conversation correctly–let me know if I have any inaccuracies):

First and foremost, both SCORM and TinCan API (as it’s now known) are not standards, but rather they are specifications. SCORM is a widely adopted and used specification, but it’s still just a specification, not a standard. That’s an important distinction to make up front.

From there, it was explained in the podcast that Project Tin Can started around 2008, when ADL started looking at whitepapers and various resources to determine how they were going to develop new standards within SCORM to develop a platform that could move forward rather than a specification. With social media starting to have a stronger presence in the world, especially on mobile, something was needed that wasn’t being pre-defined or pre-described yet was something that SCORM tried to addressed. For example, how could people have ubiquitous access to online data? How could a self-sustaining, open source system be created in the process to build this new specification/platform/standard using as many ideas as possible to push the evolution of the system continually into the future?

Tin Can API–the end result thusfar of that research–is a major component of tracking of learning activity in next generation of SCORM.

RJ asked a major question in the podcast, which was, “What is the big deal of Tin Can?” It’s a valid question, after all. Aaron, Jason, and Rob (who is using Tin Can at his mobile technology firm) explained that Tin Can allows for mobile SCORM tracking to work optimally, both offline as well as online. The spec is meant to help level the playing field so that the content can plug into new platforms without losing content in transfer, giving it far more flexibility and ease to help mobile technology use SCORM specs.

It was noted that the need to be simpler was key for implementation; it needed to be more flexible than SCORM, so the concept behind Tin Can is not only to use it for e-learning and m-learning, but to provide deliverables of different code libraries that go beyond online learning. It was noted that Articulate Storyline is using a simpler version of Tin Can rather than SCORM, but it’s more capable in its deliverable, and Blackboard is using a form of it as well.

Another big point was that Tin Can API can be initiated with informal training and not start with an LMS (Learning Management System). The idea is that learning not initiated with an LMS would take credentials from social media sites like Twitter, Facebook, or Google (I believe Pinterest and Klout have these kinds of sign-ins). The idea is that by obtaining credentials from such sources, the content from a Tin Can-compliant app would already knows who you are. In other words, if you are already authenticated through a single sign-in ID, the app will be able to collect activity and log it. It was noted that not a lot of overhead to search for content, and Tin Can would allows smaller companies to do it for their projects.

So, the burden is lighter than SCORM. An LMS isn’t needed but it can integrate with an LMS; it is not specified to be a stand-alone but rather could expand the capability of any enterprise system by taking data about what you are doing in one place and allow other systems can see how you are performing, making it interoperatable and ubiquitous. Tin Can is meant to find a common ground to help look at data in context, helping disparate systems talk to each other.

As Tin Can API is a spec in early stages, it’s evolving very quickly thanks to
the project being highly community-based, in which things change quickly in weeks and months instead of over years like SCORM. Between the huge community support–slightly like crowdsourcing through specific online social media and other outlets– and getting some smaller m-learning “boutique” firms jumping in now, Tin Can is gaining great momentum. Rustici Software has been doing the research for ADL; ADL proposed what they wanted from their requirements, and Rustici were fortunate to get the job of bringing it to fruition. Aaron and Jason explained that Rustici released workable prototype that was incomplete–but workable–implementing the concept of using an activity stream in the Tin Can spec. (An example of an activity stream that they gave was Facebook’s layout.) Even after the initial project was completed, Rustici continued to build it out and offered what they did as open source, and their continued work was adopted readily by the Tin Can community.

So–the podcast was pretty informative and yield some of the best information to understand.

It seems to me that Tin Can API is still something to continue to watch, whether one is an m-learning developer, or even as an instructional designer or m-learning specialist. My impression was that Tin Can is meant to eventually go beyond m-learning and e-learning, and extend into other mobile applications as mobile technology specifications and standards evolve. Single-sourcing is a huge issue in mobile technology, and it seems to be that this is a project that is very much centered on making that happen.

For more information on Tin Can API, I recommend visiting the links above, and give a visit to http://scorm.com/tincan/.