Update: The Output of Project Tin Can is Experience API.
SCORM User Interface Requirements Don’t Achieve Interoperability
The heart of e-learning specifications is interoperability, but there are still some issues with the existing specs. The Tin Can API looks to solve many of the remaining interoperability issues that linger with the current specs.
Displaying the Table of Contents
With older e-learning specs, it’s not always clear how the table of contents (TOC) should be displayed. Does the LMS display the TOC, or does the content? The problem is further complicated when multiple SCOs are displayed in the TOC.
The answer? With the Tin Can API, if there is a TOC to be displayed, then the content/activity displays it. The content/activity lives on its own and reports statements to the LRS when needed. Problem solved.
Another area of confusion is the actual launching of content. What size window should it open in? Is it meant for a full-screen launch?
Again, since the content/activity lives outside of the LRS, the content/activity can make itself launch however it wants.
This is an indirect fix for a common problem that currently exists — content inside LMSs is styled in its own way, and the LMSs themselves are styled in their own ways. Sometimes these styles clash. At worst, these clashes can be distracting to a learner.
By taking the content/activity out of the LRS, theming/styling is entirely up to the content/activity provider. There’s no need to wonder what content will look like inside various LMSs.
|<- Previous||Next ->|
|Better interoperability||Instructors/others need to
observe/interact during training<