Forum .LRN Q&A: Re: SCORM 2 "Tin Can API"

Collapse
2: Re: SCORM 2 "Tin Can API" (response to 1)
Posted by Don Baccus on
The more recent scorm player (packages/scorm*) MIchael Steigman and I wrote for MGH isn't integrated with dotlrn, but does a better job. Unfortunately, we only support SCORM 2004, not SCORM 2.

Tin Can comes from scorm.com, a company built around scorm products and support. Apparently it's going to be adopted (is being? has been?) as a standard by the SCORM community but I know nothing about it.

Collapse
3: Re: SCORM 2 "Tin Can API" (response to 2)
Posted by Richard Hamilton on
Thanks Don. It is still being billed as "the next generation" so I guess that means not yet formally adopted by SCORM. However, it looks as if it has a fairly significant promotional push behind it, and all the big names are advertising support for it.

It also seems that the content production software tools are now delivering content which requires "Tin Can" support, but I'm not clear exactly what this adds just yet.

Do you know of any plans to enhance the SCORM player to support this for .LRN? From the noises I'm hearing, and the popular demand for access to content on iPad "apps", I get the sense that the absence of support could be a big disadvantage for .LRN.

Conversely, being first to support this amongst the open-source options could be a big decider in favour of .LRN.

If I wanted to contribute to a project like this under guidance, who would lead it?

Regards
Richard

Collapse
5: Re: SCORM 2 "Tin Can API" (response to 2)
Posted by Richard Hamilton on
I think the benefits boil down to progress tracking and reporting. Excerpts from "Articulate" authoring program support:

....

"Articulate Mobile Player content will be tracked and reported in your LMS if you published for Tin Can API and your LMS provider has implemented Tin Can API support. In fact, if you published for Tin Can API, users will be able to switch between all output formats (Flash, HTML5, and Articulate Mobile Player) without losing their progress or results."

....

....

"If you published for SCORM or AICC, your LMS will not be able to track or report Articulate Mobile Player content. If you need to track the results of your LMS courses, it's recommended that you do not include the Articulate Mobile Player option when publishing. Or, encourage your LMS provider to support Tin Can API. (Our white paper on Tin Can API implementation provides helpful information for your LMS provider.)"

....

....

"If you publish for SCORM or AICC and you don't need to track users' progress or results, you may still be able to view content in the Articulate Mobile Player. Some learning management systems will allow it, while others will not. You'll need to test your content in your LMS environment to determine if your LMS will allow viewing SCORM or AICC content in the iPad app."

....

Regards
Richard

Collapse
4: Re: SCORM 2 "Tin Can API" (response to 2)
Posted by Ernie Ghiglione on
For the bit I've been reading, Tin Can is not really the next SCORM but instead is taking the bits that most people are using about it (reporting mainly) and getting rid of all the painful content development that goes with it.

Tin Can is very light in comparison and is mean to be a lot more flexible than the rigidities of SCORM.

I guess you can think of Tin Can, on the server side, as a service that listens to clients that post events to it (ie: "Don completed the lesson"). These events are collected in the Learning Recording Store (LRS) and then can be used by other application to determine scores, grades, competencies, etc.

Tin Can completely (and purposely) ignores where these events happen, which pushes the LRS to work more like a online service than a "LMS piece" and that's why all thes mobile app people are so happy about this.

Additionally, Tin Can doesn't enforce a particular ontology like SCORM does. Nor it forces content developers to follow a strict API or content packaging.

So I guess summarizing, Tin Can just gets the bits that most people were using about SCORM (record scores and reporting) and gets rid of all the other difficult bits giving full flexibility to the content designer to do them as he/she finds fit.

I get the sense that the absence of support could be a big disadvantage for .LRN.

Well, this would depend on the content you will be deploying.

You could deploy content into .LRN and -for my understanding, the LRS could be in some other server (cloud?). Therefore there wouldn't be a real need to add an LRS into .LRN though.

Ernie

Collapse
6: Re: SCORM 2 "Tin Can API" (response to 4)
Posted by Richard Hamilton on
Ah, that's super helpful, thank you Ernie.

I assumed that .LRN had its own LRS built in, and that using it would make sense/ be a virtue.

Perhaps that is a false assumption.

Regards
Richard