As we approach the end of our SCORM series, in many ways it’s just the beginning for eLearning content standards. While SCORM has dominated the field since it was developed, there are now new kids on the block. This final post provides a perfect opportunity to look to the future of eLearning content development and consider the road ahead.
eLearning past: AICC
On day one of our series, we learned that AICC (Aviation Industry Computer-Based-Training Committee) can be considered the first eLearning standard, used to track how learners progress through course content. While many eLearning vendors still support AICC, the standard is usually a legacy of older platforms and businesses. Organizations that implement AICC have typically been around for a while and began using it when it was still common. That’s also evident from the fact that the AICC specification hasn’t been updated in over ten years.
I was recently asked about what advantages AICC offers over a standard like SCORM. In my opinion, the main benefit is that AICC uses HTTP post requests, *Known as AICC-HACP*, to track data. As a result, AICC avoids the difficulties caused by the kinds of cross-domain communications issues I described on day four. Funnily enough, Tin Can (xAPI), which we’ll examine next, adopts a similar approach to AICC regarding the HACP and, as a result, can track data across domains, or indeed, almost anywhere.
eLearning now: Tin Can (xAPI)
SCORM has been through many iterations. While it has evolved, its primary issue is that 1.2 (only the second version in its history) is still the specification commonly implemented with authoring tools and learning management systems. That indicates that, while SCORM is embedded in the industry and will be around for some time, development has stalled and other standards need to step in. In fact, other standards have already done so. I’ll begin with the Tin Can API, also known as xAPI, officially released as version 1.0 in April 2015.
One weakness of xAPI that SCORM has in its favor relates to the CAM specification, or packaging aspect, of SCORM. Tin Can’s creators published a white paper on how xAPI courses can be packaged. But in reality the document was little more than a suggestion, intended to help authoring tools get to grips with xAPI quickly. It also enabled learning management systems to import and launch xAPI packages in a manner similar to SCORM. But why does xAPI’s lack of packaging matter?
From the perspective of an LMS vendor, the original white paper was received as the definitive word from the xAPI crew and quickly became set in stone. eLearning developers believed the paper described exactly how learning platforms and authoring tools should create, package and import xAPI courses. And while the method does work, it’s ambiguous. Different tools create packages in different ways, which creates confusion and misconceptions about how a package should be defined or interpreted. A classic example is that the xAPI package itself can define questions included in a quiz that the course can also define in real-time during its tracking. Yes, you read that correctly! That’s very inefficient and unreliable, from an LMS implementation perspective. It means that two different ways to source question data from an xAPI package must be implemented, one of which (the packaging) is not well defined. But xAPI was developed to track learning everywhere and “everywhere” can’t be neatly packaged, right?
The people behind AICC haven’t been left behind just yet. I’m very excited that cmi5 has started to gather momentum. Pitched as the “true next generation of SCORM”, ADL have taken over the cmi5 specification (which suggests it will evolve!). With cmi5, ADL are writing the packaging and structuring specification that xAPI failed to deliver. That means if you already support xAPI, implementing cmi5 should be pretty easy. ADL are taking the best parts of AICC, SCORM and xAPI, and combining them with a new specification to improve tracking for online course delivery and reporting systems. In short, the people behind cmi5 are using xAPI as a communications protocol and are defining how courses should be packaged and structured too.
LTI & Common Cartridge
New eLearning standards, Common Cartridge (CC) and Learning Tool Interoperability (LTI), are also gathering ground in the academic arena. The IMS Global Learning Consortium have focused on these standards in particular. While they’ve yet to make a dent in the mainstream, I believe that LTI in particular will soon be better known. LTI allows any tool to connect to an LMS, assuming both understand the LTI API. That should make it possible to integrate a diverse range of tools with an LMS for tracking relevant data. For example, if grading tools or online books were plugged into an LMS, LTI could be used to track progress and results.
So what’s Common Cartridge all about? In some ways, the standard redefines the concept of a course and brings LMS functionality into play within the course itself. Content packages defined for CC are very similar to the packaging of SCORM courses. That’s one exciting aspect of CC for LMS vendors. It provides an easily accessible definition for how online content can be imported and shared between platforms. CC excels in giving course developers more options by supplying specifications for including handout-based files, access to chat and discussion forums, all within the course itself.
So there we have it, a five day whirlwind journey through SCORM and the future of eLearning content development. It’s an exciting time for the industry, especially with ADL now managing cmi5. The above list is not exhaustive. For example, Caliper Analytics by IMS Global Learning Consortium is another standard that could be one to watch as it gathers momentum in the field of data science.
I hope that you’ve enjoyed the series. While it doesn’t include all of SCORM’s many moving parts, it has hopefully given you a good understanding of the cogs that must spin every day for SCORM to send information between course content and an LMS.
Missed the first post? Learn what is SCORM.