Just like humans need a common language to communicate with each other, eLearning courses and learning management systems (LMS) need a common language so that courses can send information back to the LMS from students taking those courses. To accomplish this, the industry has come up with several eLearning standards that allow courses created by any vendor to “talk” with an LMS created by any other vendor. In this article we’re going to look at the history of those standards, and where we are today.
It all started with the Aviation Industry Computer-Based Training Committee (AICC), which was formed in 1988. The aircraft industry has always had a high need for training and certification, and prior to 1988, this led to a variety of incompatible and closed system training programs that had unique hardware and software requirements. The major aircraft manufacturers of the time, Boeing, Airbus, and McDonnell Douglas, got together and formed the AICC to come up with a standard way for courses to communicate results to an LMS. The first standard for training media was published in 1989, and was based on a PC platform.
In 1993, the AICC created the CMI specification—still in use today—which specified the communications between a course and an LMS. The specification was originally intended for CD-ROM or local file based content, and was updated in 1998 and 1999 to use a protocol known as HACP (HTTP-based AICC/CMI Protocol) to allow it to operate in a Web-based environment.
The AICC was dissolved in 2014, and all of its efforts have been transferred to the Department of Defense’s (DOD) Advanced Distributed Learning (ADL) group.
SCORM has since evolved to a newer version, known as SCORM 2004, and its most recent release is known as SCORM 2004 4th Edition, which was released in 2009. SCORM 2004 added the concept of sequencing course objects, as well as the ability for the LMS to manage navigation of the content.
Although SCORM was more modern than AICC, it was designed to work in a desktop/laptop environment, requiring a user to be online and logged in to an LMS in order to record information. In today’s mobile first, BYOD world, that is not always the case. SCORM is also very restricted in the information it can record from a course—its language only supports scores, completion/pass/fail, and answers to questions.
In 2010, the ADL began research into a new eLearning standard that would allow much more flexibility, and it was given the codename Tin Can API.
In April 2013 the specification for Tin Can API 1.0 was officially released, and the project name was changed to “Experience API” or xAPI. The name Tin Can API, or just Tin Can, is still a popularly used name for xAPI.
xAPI is a simple, flexible standard that allows data to be collected on a wide range of information, rather than just strictly course information. It also allows for data to be sent in a completely platform agnostic way, so that xAPI statements can be sent from anything—from actions in a course running in a web browser to a physical button being pressed on a device. xAPI statements are phrased as an actor-verb object sentence, much like “I did this,” and allow for great flexibility when composing a statement, so that just about any information can be transmitted.
For all of the good things about xAPI, it really just defines a language for transmitting data, and how that data should be stored. An eLearning standard to replace SCORM will need to not only define this, but also specify what data needs to be transmitted in order for a course to be taken, scored, and completed. Along comes the next generation of eLearning standards, cmi5.
Before the AICC was dissolved, work had begun on creating a new eLearning standard meant to replace SCORM. The standard is known as cmi5, and is actually a “profile” of xAPI, meaning that it is a standard set of xAPI statements that a course must use to communicate to a cmi5 conformant LMS. The work on this standard has been passed to the ADL, and is actively being developed today.
In addition to the standard set of statements that a course must send, cmi5 also allows for the LMS to capture all xAPI-based statements sent from the course to be stored and reported on, giving both the standard structure that SCORM has always provided, and the flexibility that xAPI provides.
These are exciting times for eLearning standards today, as advances in xAPI and cmi5 will enable training managers to understand more and more about learner progress and continue to improve their training programs.