xAPI is NOT The Next Generation of SCORM

...And that’s a good thing!

In the beginning…  when the morning dew was still fresh in the air and a new day’s sun lit the meeting room, the folks at the ADL started to work on a new update to the SCORM specification.  SCORM was a decade old by now, with the only serious update having been delivered in the form of SCORM 2004 six years prior, appropriately, in 2004.  But it didn’t take long to realize that SCORM simply wasn’t going to update, grow, or evolve to meet the needs that existed at that moment, let alone moving forward into whatever new forms training may take.

The primary problem with SCORM is its core philosophy: SCORM is state-driven.  SCORM doesn’t report that a student completed a course.  You can extrapolate that from what SCORM reports, absolutely.  But SCORM reports the current STATE of the student’s enrollment, that the student IS completed with that course.  There is a difference.

With SCORM, the student first enrolls into the course, and the state of the enrollment/course is “Not Attempted.”  Then, the student attempts the course by launching it, and the state becomes “Incomplete.”  Eventually, if all goes well, the student finishes the course and the state becomes “Completed,” “Failed,” or “Passed,” depending on how the course reports, and how the student performed.  Along the way, you COULD collect other data, but few people actually used that function, apart from the score, because it was difficult to use, and had very little support to report in a meaningful way.  For example, you COULD collect test questions and answers.  But many Learning Management Systems didn’t give you a way to report on all the answers every student gave for a given question. And if they did, there was no consistency in how detailed such a report would be.

There is also the rather large elephant in the room: You pretty much HAD to be logged into the LMS for SCORM to work.  Yes, there have been some methods employed to divorce the content from the LMS proper.  But many times that was done with the digital equivalent of smoke and mirrors, and wasn’t the most stable practice. That sired ANOTHER digital elephant in the room, SCORM’s reliance on JavaScript.

Back in 2000, JavaScript was the only language used in webpage-centric material.  And JavaScript has had a lot of issues.  One of those issues was cross-domain requests.  Browsers, for obvious security reasons, generally block JavaScript requests made from one domain (such as example.com) to another domain (such as AnotherDomain.com) unless done in a very specific manner.  And most LMSs do not support that without the above-mentioned trickery.  There’s also that whole issue with mobile device support, too.

So, for those not keeping score, the “next generation of SCORM” would need to solve the following problems: 

  1. Change from a state-driven reporting system to a reporting system that would allow administrators to collect more accurate and detailed information about the student
  2. Provide a more detailed way to report student progress apart from completion state
  3. Provide a way to launch the content from outside the LMS, potentially divorcing it entirely from the LMS, and even possibly removing the need for an LMS entirely
  4. Allow content to use languages other than JavaScript

As a result, the next generation of SCORM that these fine folks where framing was envisioned to be… The Actively Narrating Technical Interface-Sharable Content Object Reference Model, otherwise known as the ANTI-SCORM.  OK, they didn’t call it that. But we all know they should have.  And with that, they gave SCORM a silent, respectful nod, and walked away.

But it wasn’t a complete loss.  From the ashes of the opening effort came the Experience API.  A completely new, and somewhat radical, way to track and record what the student is doing, when he or she is doing it, and any data you can imagine describing how he or she is doing it.  It represented a massive departure from the ways of SCORM.

xAPI is EVENT-DRIVEN. Essentially, when a user interacts with an activity such as clicking a button, launching a course, playing a video, or doing anything that requires the student to actually do something, the content can immediately notify the server, the Learning Record Store, of what has happened in a “statement” that could be read like normal speech.  “I did this.”  “Anthony launched the course.”  “Craig played the video.”  The content can also be built to include an arbitrary detail of information such as how long it took the student to click the button or play the video, which parts of the video were played, what OS and browser the student was using at the time, what time it was at the time, and so on and so forth.  The author of the content had nearly unlimited ability to collect whatever information was available.

These statements can also be stitched together to see all the steps the student took, how long it took, how many steps were repeated, etc…  This allows the administrators to get a much better understanding of the student’s experience with the course.  This allows for a much better view of any problems that might exist in a course, where things may need to be corrected, or updated, made more clear to the student.  This not only allows the administrators and content authors to ensure the best content is available to their students, but it can also provide the needed data to illustrate to the business leadership how training is impacting performance.

It also removes the JavaScript requirement.  xAPI content can be computer programs or mobile applications.  xAPI content could be an IoT device.  It could be practically anything that allows the content to send statements to the LRS.  This also means that it no longer has to be launched from the LMS.  Using xAPI as the reporting method, you might not even need an LMS at all anymore (although, that is a topic for another article, because some still do need an LMS, even with xAPI).  In every way, xAPI became the ANTI-SCORM.

And that’s not a bad thing.  xAPI is not meant to directly replace SCORM.  It is meant to meet the needs of an evolving Internet.  It is meant to meet the evolving needs of businesses.  It is meant to take us into the future, not concern ourselves with the past.  It is meant to be everything SCORM is not: flexible, granular, flexible, portable, flexible, consumer friendly, and, most importantly, flexible!  xAPI is meant to be more than SCORM could ever be, given the core philosophy on which it was based.

So xAPI could not, and cannot, be the next generation of SCORM.  It’s something new.  It’s something different.   And that’s not a bad thing.  It allows us options to use SCORM or xAPI.  So worry not, skilled solicitors of SCORM services, your old, well “friend” probably isn’t really the word I’m looking for here, but it isn’t going anywhere any time soon.

Both will co-exist for years to come.