cmi5: The next generation SCORM

With the successful roll out of the Experience API (xAPI), the foundation has been laid for replacing SCORM. By itself, xAPI is not a replacement for SCORM. Instead, 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 e-Learning that will be maintained in the LMS, so a more modern SCORM is certainly needed.  Now that ADL has taken over the cmi5 specification from the AICC, it is clear that cmi5 is the “next generation” of SCORM.  This article provides an introduction to this powerful new specification.

Background

Let’s first take a look at the history of LMS to content communication.

AICC

The first specification for LMS to content communication was AICC’s “CMI Guidelines for Interoperability”, released in 1993.

Originally a file-based specification designed for the desktop, AICC later released revisions that worked in a web browser.

SCORM

The Sharable Content Object Reference Model (SCORM) was first released by Advanced Distributed Learning (ADL)  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

In 2013 ADL released the Experience API (xAPI).  The xAPI is the first component of ADL’s Training & Learning Architecture.  xAPI is not, however, a specification for LMS to content communication.  It was never intended as a replacement for SCORM.  We’ll discuss why later in this article.  (If you’d like to know more about xAPI, read my previous two part article Introduction to the xAPI).

SCORM: The good and the bad

What SCORM provides

Now let’s take a brief look at what SCORM provides:

• LMS to content communication
  At its base level, 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 / browser
  SCORM was designed for browser-based communication.  SCORM did not consider Mobile devices.  Smart phones did not come into widespread use until around 2007…and the tablet did not exist.
• Interoperability
  One of the key advantages of SCORM was interoperability.  SCORM uses a common packaging, communication and launching mechanism.  So a course designer can build an e-learning module, package it as SCORM, and any LMS that supports SCORM should be able import, launch and track the module.

What’s wrong with SCORM?

ADL, recognizing that SCORM needed “updating”, commissioned a study called “Project TinCan”.  You can read more about their findings using this link, but I will highlight some of the issues below.

• Content must reside in same domain as the LMS
  This is very inefficient, especially in our new “cloud-based” world.  To be sure, some content vendors have developed work-arounds for this problem, but they are not part of the specification and they are not interoperable.
• 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 e-learning.
• SCORM is easily hacked
  SCORM uses old technology that is quite easily hacked.

And there is much, much more…these are just some of my “favorites”.

Doesn’t xAPI fix all that?

xAPI is not SCORM

The xAPI was never intended to replace SCORM.  It 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.  Let’s take a look at some of the things your LMS + SCORM system provides:

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.

xAPI Fixes Everything… doesn’t it?

I can now hear you saying “But 70-80% of all learning is social and xAPI is perfect for that.”  Yes, xAPI is great for tracking social learning, but in most organizations formal learning simply cannot be eliminated.  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 spec 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…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, basic tenets of SCORM.

Introducing cmi5: xAPI with Rules

Recognizing the problems with both the SCORM and the AICC specifications, the AICC and ADL began working on a new specification for LMS to Assignable Unit (“AU”) communication back in 2012.  This new spec, dubbed “cmi5”, would utilize 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.  cmi5 defines how the LMS and the content will communicate using the xAPI Learning Record Store (LRS).

cmi5 Goals

ADL & AICC developed cmi5 with the following goals:

• Interoperability
  A cmi5 “AU” 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 tracked in cmi5 is not limited.  Since cmi5 is based on xAPI, extensions are supported.  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?  Let’s take a look at the cmi5 “verbs”.

• Launched (LMS)
  A “Launched” statement is used to indicate 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 (AU)
  A “Initialized” statement is used by the AU 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 (AU)
  The AU records the “Completed” statement when the learner has experienced all relevant material in an the AU.
• Passed (AU)
  The AU issues the “Passed” statement when the learner has attempted and successfully passed the judged activity in the AU.
• Failed (AU)
  The AU records a “Failed” statement when the learner has attempted and failed the judged activity in the AU.
• Abandoned (LMS)
  The LMS uses the the “Terminated” statement to determine that the AU session has ended. In the absence of an “Terminated” statement the LMS will make the determination if an AU abnormally terminated a session by monitoring new statement 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 records a “Satisfied” statement when when the learner has met the “move on” criteria of all AU’s in a block, or has met the “move on” criteria for all AU’s in the 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.  Such statements are called “cmi5 allowed” statements.

Other cmi5 Features

Here are some other cool features cmi5 includes:

1. Launch Mechanisms
   The course structure defines whether the AU is launched in the “Existing” window (where the LMS is running), or in a “New” window.
2. Content Entitlement
   cmi5 supports two types of content entitlement.  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.
3. 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”.
4. AU-specific launch parameters
   In the course structure, the AU can define any specific, custom parameters that it requires.

Benefits of cmi5

So why should you 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, we’ll take a look at a sample “use case”.

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
You can store all the data, including the video file, in the LRS.

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#2 fetches that data from the LRS.

Without cmi5
Personally, I’ve never seen SCORM open in a single window environment.  So, without customization, you are out of luck.

With cmi5
You use the “AnyWindow” option of cmi5.

Without cmi5
With SCORM, you load your content on a LMS server in Houston and your students have a slow, agonizing user experience.

With cmi5
Your can distribute your content globally through a content-distribution network and your students are happy.

…And 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

ADL released cmi5 in June, 2016!  You can read the spec on GitHub (note: this link may change as ADL takes over the spec, but I’ll try and keep the link current for you).  Also, you can contribute to the spec by joining our weekly conference calls.  To get more info, send an email to cmi5wg@adlnet.gov. For more information on cmi5, be sure and check out our blog’s xAPI and cmi5 category.

For the next article in this series, see cmi5: An overview of the Process Flow.

Acknowledgements

Part of this article is based on a presentation by Bill McDonald and Kris Rockwell.

Art Werkenthin

Art Werkenthin is president of RISC, Inc. and has over 30 years' experience working with LMS systems in the Oil & Gas, Retail, Finance and other industries. Mr. Werkenthin holds a B.S. in Electrical Engineering and an M.B.A. in Information Systems Management from the University of Texas. Mr. Werkenthin is a member of the ADL cmi5 committee and frequently presents on cmi5 and xAPI. Follow him on Twitter @AWerkenthin for xAPI and cmi5 updates, as well as blog post announcements.