Download PDFStaying on top of all the latest trends in eLearning is no simple task. As with many rapidly evolving technical fields it can be difficult to differentiate between a passing fad and the beginning of a paradigmatic shift. It’s here, nestled between the optimistic hype of new technology and a more grounded reality, that we find Experience API (commonly known as xAPI). We’re not trying to say that xAPI doesn’t have value (it does), its merits are just broadly misunderstood and typically mis-advertised.
Our goal is to cut through the pomp and ambiguity to establish a candid dialogue around the pros, cons, and applications of both SCORM and xAPI. We’ve set out to demystify xAPI; to take an in depth look at how it differs from SCORM; to understand not only when xAPI is best applied, but the organizational requirements to do so successfully.
Setting the Scene
Wrapping one’s head around the nuances of eLearning specification standards (as exciting as it is to us), can be a little dense. While our research echoes contributions from some of the industries leading software engineers and content developers, we feel it’s equally important that this information is as accessible as it is accurate. This all begins with setting the scene which, by and large, is an eLearning landscape dominated by the SCORM specification.
SCORM is the de facto norm. Chances are, if you’ve ever taken an eLearning course, it was developed using the SCORM spec. This is with good reason, SCORM is tried and true. It’s a proven, capable tool; not likely to disappear anytime soon. SCORM effectively accomplishes three primary functions; first, it defines how content should be packaged so that the Learning Management System (LMS) can import it; second, it structures the datamodel (i.e. data tree) that user activity can be stored within; and third, it outlines communication methods for the content to send/retrieve user activity data to/from the datamodel that is stored by the LMS. In layman’s terms, SCORM establishes a standard for communication, allowing content and LMS’s to speak to each other; distribute, record and store data; and track learning experiences. In other words, it accomplishes exactly what most of us need our eLearning to do.
As mentioned above, SCORM is the industry standard and the foundation of most eLearning out there today. As such, this paper is not designed to list off the uses and capabilities of SCORM (no more than what is briefly discussed above). There are plenty of available resources that do that topic justice. Instead, we want to choose a more practical focus. When does it make sense to branch away from SCORM and utilize a different specification?
Where are we now?
Enter xAPI. xAPI is a relatively new technology. Like SCORM, it too is a technical specification for eLearning, however, it establishes a new hierarchy of responsibility between the LMS and content (i.e. which piece is responsible for what). For the purpose of this article, we’ll focus less on the technical differences of these two specifications and more on what those differences mean in application.
A majority of the narrative out there implies xAPI is a new replacement for SCORM. While we agree that there is plenty of overlap in what they can accomplish, this is a dangerously uninformed conclusion. In-fact, following this assumption can lead to a whole host of unnecessary and costly errors. This line of thinking is typically the result of product-driven problem solving. Meaning, the logical order of problem solving is flipped on its head. Rather than starting with the problem, it starts with a solution (i.e. a product), and works backwards to try and establish how that pre-determined solution can best solve the problem. This often leads to a solution that is clumsy, that doesn’t fit the unique context of a situation, and in many cases simply fails.
Instead, we want to encourage a more pragmatic approach to this discussion. The best solutions are those that account for the specific needs of the situation. Rather than a replacement for SCORM, xAPI is simply another option in the eLearning toolbox. It can be used effectively or ineffectively, same as SCORM.
So, how do you know what’s right for your organization? Lo and behold, context matters. Your learning goals and organizational structure matter. Approach matters. These are essential factors to consider in any eLearning program. The specification itself does not make great content, the ability to get the most out of the right specification in any given situation does. Now, maybe that’s not the sexy, convenient solution we were all hoping for, but it is the first step in realistically putting together a successful eLearning strategy.
SCORM Limitations
Before we go any further, it’s important to establish some base-line assumptions to get the best out of this article. As a reader, you (or your organization), likely fall into one of two categories. Either you are at the very beginning of your eLearning journey, deciding between SCORM or xAPI; or, you already have existing SCORM content and are weighing the benefits of transitioning to xAPI.
It’s important to realize, as we touched on earlier, SCORM is already fully established and integrated into current eLearning processes and standards. As a result, it’s more broadly understood, cheaper, and easier to work with. The benefit of xAPI is only realized if there are specific objectives that cannot be accomplished using the SCORM specification (which we will go into further). Barring those exceptions, from an application standpoint, the two specifications are very similar. Therefore, in any situation, it is vital to first grasp the limitations of SCORM before considering xAPI.
There are two primary restrictions related to SCORM. Because of how browser security has evolved, SCORM content must reside on the LMS within the same domain. External storage is possible by using a shell content package to be a middleman and relay data between the LMS and content stored elsewhere (i.e. SCORMCloud, scormGadget, SDXD), however, this is fairly complicated and still must be installed on the LMS. As a result, content distribution (selling your content while maintaining control over it), can be difficult. In addition, SCORM content must be web-based. This can create barriers when attempting to track, “real-world” learning events as well as other online (but not web-based) activities.
How does xAPI address SCORM limitations?
xAPI addresses these limitations through two key differences. First, xAPI is not a complex data model (like SCORM), but rather a simple structure for communicating statements. The data model is replaced by a simple statement structure. Any “actor” can perform any “verb” on any “object”. This openness, while technically more complex, allows for more nuanced data collection, particularly in a “real-world” context.
Second, xAPI defines a communication method for the content to send/retrieve the activity statements to/from the LMS/LRS. Thus, it removes the “packaging” specs and requirements because it does not have to be published into the LMS – it can be anywhere that is accessible to the learner. This removes the requirement that content must be web-based and makes distribution easier. Any content is possible so long as it can communicate back to the LMS.
In essence, these fundamental structural differences are what enable skilled designers and developers to use xAPI as a different approach to track behaviors, real-world activities, and distribute content.
Making a Decision
Shifting to xAPI and actually taking advantage of it, requires deeply thinking about your corporate learning environment. It’s not just a simple “re-authoring” of content, but a serious undertaking that involves the right coordination and structure from a foundational level.
xAPI redefines how content and the LMS interacts. It provides a mechanism for tracking behaviors that can occur outside the LMS and in normal everyday activities that are performance indicators. To help put this in perspective, let’s briefly recap a few appropriate circumstances that we’ve touched on throughout this article in which xAPI may really add value to.
Content distribution (you want to keep control of your content) but don’t want to rely on a 3rd party tool (like SCORM Cloud).
Offline capability is a requirement (and the LMS does not provide that functionality or you need it globally across multiple [unknown] LMSs).
Tracking any non-web-page content such as: apps, physical hardware, or other data (i.e. tracking your phone GPS, accelerometers, etc.) or tracking un-assessed activity such as “read a book”, “shared an article”.
Considerations
If your training needs fall outside the scope of SCORM, xAPI may represent a potential path forward for your organization, however, it’s important to realize the unique set of complications that come with that so you can effectively prepare. In general, the capabilities of xAPI discussed above are achieved by reducing the complexity and responsibility of the LMS/LRS for correctly interacting with content and passing that complexity and responsibility on to the content authors. In other words, the benefits of xAPI can be extremely difficult to realize without specialized content developers that understand the nuances and technical complexity involved.
For example, SCORM content with offline capability would have required a “player” to handle this and that player would have been provided by the LMS vendor. This is no longer the case with xAPI. The onus for storing data offline and reporting only when online becomes the responsibility of the content. In addition, all content needs a “connector” – something to send data to the LMS. The connector needs a method of LMS authentication and identifying the user to the LMS (which the LMS should already have knowledge of). The openness of the spec (verb library, etc.) means that much more knowledge of and responsibility for functioning correctly has moved, once again, from the LMS to the content (and thus the content author).
There’s absolutely nothing wrong with this approach. As we’ve mentioned, given the appropriate circumstance these differences can be leveraged to create powerful learning tools. What is important, however, is to recognize the difficulties of developing with xAPI in the broader eLearning environment and industry as a whole.
While the majority of authoring tools out there can actually publish to xAPI (in addition to SCORM), it is largely impossible to take advantage of the benefits of xAPI through these conventional authoring tools. They simply lack the requisite sophistication to effectively match the complexity of content at which xAPI becomes useful. Therefore, even though xAPI is possible through authoring tools, the type of content you would be publishing might as well be published in SCORM which is currently more stable and widely compatible across LMSs (this will be less important as xAPI adoption increases). In addition, if you are developing complex content (simulations, gaming, etc.) that is not developed using authoring tools, it will be easier to convert SCORM to xAPI than xAPI to SCORM. If there is any doubt about the xAPI standard, SCORM is often the safer option.
This is not meant to discourage the use of xAPI, rather it is meant to encourage serious content creators to realistically and correctly apply the development tools at their disposal to create better, richer learning environments that propel both the eLearning industry and education technology forward.