The current standard for eLearning-to-Learning Management System (LMS) communication is SCORM, the Shareable Content Object Reference Model. Originally released in 2001, SCORM is rapidly becoming obsolete. With the successful roll out of the Experience API (xAPI), the foundation for a new SCORM standard has been laid. My purpose in this article is to outline the path to that new standard.
The history of LMS-to-content communication goes back over 20 years, to 1993. That was the year that the Aviation Industry Computer-Based Training Committee (AICC) released “CMI Guidelines for Interoperability,” originally a file-based specification for the desktop, later revisions were designed for a web browser.
SCORM itself was first released by Advanced Distributed Learning (ADL), a division of the Department of Defense, in 2001, with a major revision in 2004. Easily the most widely adopted specification for LMS-to-content communication, SCORM was originally based on AICC.
xAPI was released in 2013. It is the first component of ADL’s Training & Learning Architecture, however, it is not a specification for LMS-to-content communication. By itself, xAPI is not and was never intended as a replacement for SCORM.
xAPI defines communication between a learning experience and the Learning Record Store, or LRS. While most of us agree that the majority of learning occurs outside the LMS, there is still some formal eLearning that will be maintained in the LMS, so a more modern SCORM is certainly needed. Now that ADL has taken over the cmi5 specification, it is clear that cmi5 is the next generation of SCORM.
SCORM: The good and the bad
SCORM provides:
- LMS-to-content
communication
SCORM defines a way for the LMS and training content to communicate with each other. It defines both the communication layer and the data that will be stored. That data is fixed: you cannot store parameters not defined by SCORM. - Designed for the
desktop and browser
SCORM was designed for browser-based communication. Mobile devices are not considered in SCORM because it was released in 2004, three years before smartphones were in widespread use and before tablets. - Interoperability
This is a key advantage of SCORM. SCORM uses a common packaging, communication, and launching mechanism. A course designer can build an eLearning module, package it as SCORM, and any LMS that supports SCORM should be able import, launch, and track the module.
ADL, recognizing that SCORM needed updating, commissioned a study called Project Tin Can. The study findings are on ADL’s website, but here are some highlights:
- With SCORM, content
must reside in the same domain as the LMS
This is very inefficient, especially in our new “cloud-based” world. To be sure, there are workarounds for this problem, but they are not part of the specification and they are not interoperable across systems. - SCORM is complicated
The SCORM specification is long and complicated. It takes dedicated resources to develop and maintain compliance. - Designed for the web
browser
A modern specification should work on mobile devices and should support mobile apps. Simulations and gaming are now in widespread use for eLearning but SCORM does not support them. - SCORM is easily
hacked
SCORM uses old technology that is quite easily hacked.
Doesn’t xAPI fix all that?
The xAPI is just the first component of the Training & Learning Architecture and does not replace everything SCORM does. At its core, xAPI is a data transport and storage mechanism.
Figure 1 shows some of the things your LMS + SCORM system provides.
Figure 1: LMS + SCORM provides these functions. xAPI can only handle one of them
xAPI could replace the record storage, but what about all the other functions? xAPI is not designed for scheduling, for example. There’s no sequencing, no user management features, and so on.
I can hear you saying, “But 70 percent of all learning is social and xAPI is perfect for that.” Yes, xAPI is great for tracking social learning, but most organizations simply cannot eliminate formal learning.
Let me give you an example: As I write this, I’m getting ready to get on an airplane. I want to get on one where the team that attached the engines were formally trained on how to attach engines to aircraft. I want them to attach the engines based on a specification designed by a formally trained engineer and trained with materials developed by an instructional designer. Social learning is great, but it is not the solution for every situation.
xAPI is flexible. Is it too flexible?
One of the great things about xAPI is that you can define your own verbs and extensions. This allows you to track everything needed to analyze your learner’s experience, but it is another reason that xAPI is not the “new SCORM.” For example, what verbs or extensions indicate “completion” of a course? There’s no definition. Sure, you can make your own choice, but interoperability is lost. There’s also no common way to define sequencing and bookmarking criteria, two basic tenets of SCORM. If we want to use xAPI as the basis of a new SCORM, we need to add a few rules to insure consistency across systems.
Introducing cmi5: xAPI with rules
Recognizing the problems with both the SCORM and AICC specifications, and to tap the new benefits of xAPI, in 2012 the AICC and ADL began working on a new specification for LMS-to-Assignable Unit (AU) communication. This new spec, dubbed cmi5, would use the xAPI as the communication and data layer, combine the features of both the AICC and SCORM specifications, and tap the new benefits of xAPI.
You can think of cmi5 as the LMS use case for xAPI. The cmi5 specification defines how the LMS and the content will communicate using the LRS.
cmi5 goals
ADL developed cmi5 with the following goals:
- Interoperability
A cmi5 assignable unit should work the same across all LMS systems that support the specification. Think of the SCORM package, where an LMS imports a SCORM course. cmi5 has a similar import specification, but with cmi5 only the course structure is imported, not the actual content. This means the content can reside anywhere—behind a firewall, as an app on a mobile device, etc. - Extensibility
Unlike SCORM, the data cmi5 tracks is not limited. Since cmi5 is based on xAPI it supports extensions. You can also track binary data like videos, pictures, and audio clips. You can even share data across multiple assignable units. - Mobile Support
Here again, cmi5 benefits from xAPI: since the base communication mechanism handles mobile devices, so does cmi5.
Sample cmi5 rule
So if cmi5 is “xAPI with rules,” what does a rule look like? These are the cmi5 verbs:
- Launched
A “Launched” statement indicates that the LMS has launched the AU. It should be used in combination with the “Initialized” statement sent by the AU in a reasonable period of time to determine whether the AU was successfully launched. - Initialized
The AU uses an “Initialized” statement to indicate that it has been fully started and is ready for student interaction. It must follow the “Launched” statement created by the LMS within a reasonable period of time. - Completed
The AU records the “Completed” statement when the learner has experienced all relevant material in the AU. - Passed
The AU issues the “Passed” statement when the learner has attempted and successfully passed the judged activity in the AU. - Failed
The AU records a “Failed” statement when the learner has attempted and failed the judged activity in the AU. - Abandoned
The LMS uses the “Terminated” statement to determine that the AU session has ended. In the absence of a “Terminated” statement the LMS will make the determination if an AU abnormally terminated a session by monitoring new statements or State API calls made for the same learner/course registration for a different AU. When abnormal termination is detected, the LMS writes an “Abandoned” statement. - Waived
A “Waived” statement is used by the LMS to indicate that the AU may be skipped by the Learner. The LMS makes this determination based on the course structure in cmi5. - Terminated
The AU must record a statement containing the “Terminated” verb as the last statement recorded by the AU in a session. - Satisfied
The LMS writes a “Satisfied” statement when the learner has met the “move on” criteria for all AUs in a block or all AUs in a course.
So cmi5 defines some verbs that must be used according to rules in the specification, but cmi5 developers are not limited to these verbs. You can record any statements you wish in the LRS, without impacting cmi5 compliance.
Other cmi5 features
Here are some other cool cmi5 features:
- Launch Mechanisms
The course structure defines whether the AU can be launched in the existing window (where the LMS is running), or in its own window. - Content Entitlement
There are two types of content entitlement supported by cmi5. The first is an entitlement key in the course structure. Recognizing that some developers may use a pay-per-use model, cmi5 also allows for a separate entitlement key to be determined at runtime, using a mechanism agreed upon by the LMS and the AU. - Completion Criteria
Here cmi5 addresses the age-old debate “Does completed mean passed?” In cmi5, the course developer or the LMS Administrator can define a “move on” criteria. This can be “Passed,” “Completed,” or “Completed AND Passed.” - AU-specific launch
parameters
In the course structure, the AU can define any specific custom parameters that it requires.
Benefits of cmi5
Why use cmi5 over SCORM? Let’s take a look at some of the benefits:
- Content-defined data can be stored in the LRS using cmi5
- Data sharing across content
- Content-defined launch mechanism
- Distributed content
For each of these benefits, here is a sample use-case.
Use case 1: Content-defined data
You build a content module that wants to record the exact steps a user took to perform a procedure, with video.
Without cmi5
You can either customize your LMS to store the video received from the AU and customize the AU to send data to your specific LMS, or the AU can store the video in some external location.
With cmi5
All the data, including the video file, can be stored in the LRS.
Use case 2: Data sharing
You have a multi-AU course. You need data entered by the student in AU #1 displayed or used in AU #3
Without cmi5
There is no mechanism in SCORM to allow this. So you are again faced with customizing the LMS and the AUs, or the AUs can find a custom way to share data.
With cmi5
Your content can record any data it wants in the LRS. So AU #1 records the data in the LRS, and AU #3 fetches that data from the LRS.
Use case 3: Distributed content
You have a giant eLearning module with video, voice, animations, etc. that you need to deliver to students all over the world.
Without cmi5
With SCORM, your content is loaded to your LMS server in Houston and your students have a slow, agonizing user experience.
With cmi5
Your content is distributed globally through a content distribution network and your students are happy.
Mobile support
In addition to the benefits above, you also gain mobile support with cmi5. Since it is based on xAPI, cmi5 uses modern technology like REST and JSON.
cmi5 status
So can you use cmi5 today instead of SCORM? Not quite yet. The cmi5 specification has just been released as a version called “Sandstone.” This is basically a stable beta, meaning you can develop against the specification and ADL promises not to make major changes. The goal is to release a final version of the specification in September 2015.
The ADL cmi5 committee expects that the Sandstone release will encourage content development tools and LMS vendors to move forward with spec adoption.