To SCORM or not to SCORM

To SCORM or not to SCORM

Some months ago, my colleague Kim wrote about SCORM (Sharable Content Object Reference Model) and gave us some useful tips on deploying SCORM packages for eLearning platforms. The reality, however, is that producing such learning packages remains heavily dependent on authoring applications that, although available off the shelf, still take some time for many organizations to master before they could produce respectable interactive packages. With high expectactions for many sectors to have the "nice and shiny" and the insistence of some folks on what their "brands" entail in the "look and feel" department of eLearning, lousy SCORM packages just won't cut it at all.

The SCORM standard itself (perhaps more accurately, a collection of standards) is rather old. With its roots back in the 1990s in the U.S. Department of Defense's offline computer-based training, SCORM has evolved over years to be an online course deployment standard as well.* More recently, "rival" standards have emerged. "Experience API" ("xAPI", aka "Tin Can API"), for instance, came about to provide tracking for learning across content providers. Know more about xAPI here. xAPI's proponents waste no time reminding us of its many benefits.

Expectedly the politics around standards couldn't be less energetic. See, for instance, this post. For this blog, we'll try to stay out of it. It doesn't help that SCORM packages done using different authoring software are replete with quirks. In the able hands of some developers and project managers, however, these quirks do not have to be too annoying.

Still, for no small reasons, people are taking a long time to adopt to more advanced versions of the standard. Version 1 of xAPI came in 2013. Look where we are at with that right now!

One can make the argument that xAPI is still SCORM. But in the minds of old folks, SCORM is just their old stand-alone package (online or offline), oblivious to the need for its real-time trackability by learning managers and content providers. Truth be told, the people we talked to across industries, those who actually pay for the development of interactive materials, still do not find xAPI's functionalities compeling enough for them to shift away from the "classic" SCORM. While compatibility across learning management platforms is given lip service, most people in our melieu are content with their good-ol'-fashioned SCORM packages (on version 1.2, circa 2001) playing on their trusty learning management system (LMS).

So where does that leave us? One alternative to consider is to deliver lectures via videos. No interaction within the video itself? This much you see in the MOOCs^ scene these days, with providers as diverse as EdX, Coursera, and the like. Keep the videos short and have them interspersed with interactive activities. Otherwise, flat visuals are all you have. And for many courses this approach works. Unless you still feel the need for these short videos to be jazzed up with illustrations and graphics.

The problem with videos is that not that many people organic to the institution can do them well. What you often see are awkward people "acting" before the cam. Mostly we see talking heads. Obviously the alternative to the alternative is to have the video production outsourced to some media company, which in itself is no guarantee for good learning outcome.

The challenge doesn't end here. Added to SCORM, xAPI, and videos is the possible use of the Common Cartridge (CC) Standard. With CC, contents are supposed to be compatible with each other, regardless of which LMS you are using. Know more about CC here. There are other standards out there (see, for example, this roadmap), and using one does not necessarily mean the exclusion of the others. For instance, CC can use SCORM as part of its packaging. The differences between standards largely have to do with which aspects of the learning experience is emphasized.

So "to SCORM or not to SCORM"? To use an old (but tried and well-adopted) standard or to try a new promising one? Certainly not a simple either/or question. Which standard gets widely adopted and dominates eLearning, is partly a function of which tools get deployed widely. It's not necessarily about which standard is superior but which standard (or combination of standards) people find appropriate in their own contexts, given whichever tools are working "naturally" in the organization's workflow.

At the end of the day, learning managers do not always have the luxury of waiting for the better standards to emerge clearly as "winner" before they run eLearning. Deployment started yesterday and, today, there's more demand for interactive materials online.

Should you persist with the production SCORM packages for your organization, make sure you publish them in HTML5 format, as opposed to Flash. The fate of the later is dim. Google Chrome, for one, will end its support for Flash by December 2020. But HTML5 is well supported on various platforms; it's going to be around in the foreseeable future.


Experimentation on the adoption of standards is not always a luxury for many but, to the extent feasible in our own contexts, it should be a duty for all of us. Standards are a means to an end. Insofar as we try out new things to be more efficient and effective, we experiment with new standards. It's a balance between "the usual" and taking eLearning to new heights.

We at moodLearning help our partners make informed decisions as to what standards to adopt. We also provide the requisite tech support services for you to accomplish your mission in eLearning.