Update: The Output of Project Tin Can is Experience API.

next generation scorm evolution project tin can
 

Ready to really dive in?
View the full
Tin Can API spec.

View the Tin Can API
“quick start” guide.


It Needs To Be Simple

A major aspect that most of you are looking for in a next-generation specification is simplicity. Traditional e-learning standards are complex, so it takes significant time and cost to become conformant.

You’ve also asked for more power.

Unfortunately, simplicity and power generally don’t go hand-in-hand in a software environment, but we think we’ve found a solution.

The Tin Can API at its simplest is much easier than SCORM:

  • You no longer have to deal with Javascript.
  • The complexity of activities and LRS communication is greatly reduced (fewer API calls.)
  • There are no more required manifest files or complex file structures.
  • There are no complex requirements for the content (activity) to meet. It only needs to be able to send the statement “I did this.”
  • Since the activity runs on its own (outside of the LRS,) there are no user interface requirements to be met by the activity or the LRS — the activity exists on its own and reports statements to the LRS.

“I did this” is simple, and it can stay that simple if that suits your needs. Statements can get as complex as you’d like them to be, and that’s one way where the answer to a “more powerful” e-learning specification comes into play. (There are many other ways that the Tin Can API is more powerful than traditional specs. Keep reading the “capabilities” section to learn more.)

An example of a more complex statement would be:

[Somebody] says that [I] [did] [this] in the context of
[ _____ ] with result [ _____ ] on [date].

Join in in the conversation below. Add your voice and see what others say about this solution to a simpler but more powerful e-learning specification.

SCORM 2.0 next generation project tin can

Did we achieve what you wanted with this feature?


  • Jimmy Arbuckle

    I can tell you that the U.S. military is relying heavy on SCORM. It is the development standard; but as you said, there are not allot of developers using the full power of SCORM. The courses I’ve seem with exceptional use of SCORM came from contrator’s developing for the military. The LMS engineers are stunned in most cases because when issue arrise, they don’t know how to address them; the otherside of SCORM most miss. What good is the courseware if the LMS cannot run it and there is no support to fix the issues?

  • Jimmy Arbuckle

    SCORM 2004 3rd Edition is the current standard for the U.S. military. However, you will find numerous courses running SCORM 1.2 and 2003. Thank goodness for backward compatibility. I guess this raised a question about the Tin Can API; will courses currrently developed for the standard API still work? If not, what would the cost to convert current courseware? Just a thought..

  • For some more updated statistics on SCORM usage, check out https://scorm.com/scorm-stats/ which shows the actual usage of SCORM within SCORM Cloud.

  • Anonymous

    SCORM 2004 actually isn’t backwards compatible with SCORM 1.2, so this is a good example — just like with SCORM 1.2, we anticipate LMSs that implement the TinCan API to keep their SCORM implementations for some time.

    Also, it should be possible to create a wrapper that presents a SCORM player and API to content, and then makes TinCan API calls based on the content’s SCORM calls.

  • Also, for what it’s worth, we had one of our developers convert a sample SCORM course to report via Tin Can. He has a prototype working agains a prototype LRS we’re building. It took him about two days to do the conversion…but that time also included getting up to speed with Tin Can and writing some reusable code for future conversions. He’s also the first developer to ever do that and is working against an LRS still in development.

  • Miriam

    As a manager in educational web content organizations, we want to pack our contents in SCORM and delivered it to our customers (which are LMS or other web sites). some organizations didn’t want to work so hard to open the SCORMs.. so – I really think that simplicity is essential condition!!!

  • Playing devils advocate here.

    “You no longer have to deal with Javascript.” This statement confuses me after looking at all your examples that are written in JSON in the spec. I know that you may not be forced to use JavaScript but to say you no longer have to deal with it is a bit of a marketing ploy for those that don’t like JavaScript 😉

    “There are no more manifest files or complex file structures.” This all depends on whether you feel that JSON and XML are complex file structures.

    “There are no complex requirements for the content (activity) to meet. It only needs to be able to send the statement “I did this.”” And currently in SCORM a SCO only has to send Initilize and terminate. 3 lines of code, you can initilaize, send a score and terminate the SCO.

    I do like the fact that this is web service based and not so client side as the current standard so I am not saying that TinCan is a bad thing, but I think as it stands now, after looking at the spec there are still going to be just as many people confused about TinCan API implementation as are current confused or clueless about SCORM.

  • bsc_scorm

    We think it’s fair to say “You no longer have to deal with JavaScript” since JSON is only the serialization format. The fact that it’s a human-readable format makes it convenient to express certain structures using it in the spec, but anyone who doesn’t want to deal with the JSON could instead use one of the JSON libraries available for various languages. Also many folks who don’t like JavaScript really don’t like dealing with various browser implementations of JavaScript, and they certainly don’t have to do so with TCAPI.

    We probably should have said there are no more _required_ manifests or complex file structures — TCAPI does not require ‘Import’, or a manifest. We certainly don’t feel that JSON and XML are inherently complex, rather the imsmanifest.xml is a little bit complex even in simple cases, and quickly gets more complex from there.

    Regarding your 3 lines of code example, would you have set a scaled_passing_score in your manifest, or are you just tracking the score? In TinCan, one result object can be populated with score and success status, or the verb “Passed” could be used. Do those 3 lines of code reference a SCORM library that performs a correct search for the API, or does it only find it in the most common locations? And of course there has to be a manifest with at least one organization, item, and resource.

    I think the sheer size difference in the spec between Tin Can and SCORM will help folks understand Tin Can better. (True, some areas do need to be fleshed out, but we’re not headed for 3 books with hundreds of pages each). The concept of an LRS, combined with the web service API clearly delineate responsibilities, so there should be less confusion about who is responsible for what. Since all LRS responsibilities are in terms of an API, with no UI, launch, or import requirements, the LRS can be verified through automated tests, so any confusion can be quickly cleared up.

  • anon

    Question, – does LRS = Learner Response System – and is Project Tin Can specifically focused on training and training systems?

  • Andy

    LRS stands for Learning Record Store. You can learn more about what an LRS is here: http://tincanapi.com/learning-record-store/

    The Tin Can API was originally created with e-learning and training systems in mind, but it can have much broader applications. I’d recommend taking a look at http://www.tincanapi.com and send us questions as you have them.

  • julian

    julian