Disclaimer: This post has a buttload of jargon. I can only apologise.

We had a great deal of reluctance when Curtis and I discussed how that our learning platform must support SCORM content… I think we were both in the mind that having worked for so many organisations producing SCORM packages and looking after learning management systems of various shapes and sizes, we knew that SCORM sucked. But it was popular, so it would be naive to leave it out.

For the uninitiated among you, SCORM is an industry-standard specification for e-learning packages. It’s the protocol that allows most e-learning packages to “talk” to a platform like Moodle or Experience for example.

Painfully for us, and for most professionals working in the learning tech sphere, SCORM is ridiculously popular. It’s just the ‘done thing’. But it’s bad. Here are a few reasons why:

  1. It’s not backwards compatible. There are multiple versions of SCORM. And they don’t work well with one another. For example, a SCORM 1.2 package will not work on a LMS that only supports SCORM 2004 or vice versa.
  2. It spits out very high-level information. SCORM will tell you that John Doe completed a training package, but that’s about it. It couldn’t tell you whether John Doe was engaged and it doesn’t necessarily interlace with other information sources like call centre records or an apprentice management app. This makes for quite a poor level of understanding of learner behaviour.
  3. It doesn’t always work. SCORM is reliant on a continuous uninterrupted session with the LMS. Dropouts are common and will usually result in disgruntled learners being asked to do the same e-learning package again and again until the LMS “gets it”. Which just flat out bad user experience.
  4. It’s old. Old in itself isn’t necessarily a bad thing. But it’s bad in the case of SCORM because we knew about its flaws for a really long time, but the industry is yet to catch up on moving towards something better.
Millennium cover.jpg
For context, SCORM’s inception was in 1999. That’s the same year that gave us “I want it that way” + when the Euro was established.

It’s been a while. I think we should move forward.

OK fine. So we established that SCORM isn’t ideal. But is there anything better out there?

The short answer is yes. 

The veterans in the EdTech sphere will know about xAPI. Sometimes referred to as TinCan or Experience API. Please don’t ask me why it has so many names, I don’t actually know. 

In fact, I’d go as far as saying that way xAPI has so many names actively contributed to creating confusion around what it is, what it does, and ultimately hampered the process of making it the go-to protocol.

Anyway, I digress… xAPI is better (and I’ll explain why… bear with me). But it is not popular.

So what is xAPI anyway?

In a nutshell, it’s another protocol. Much like SCORM. It sets out a bunch of rules and schemas around how a LMS and a learning resource communicate.

If you’re feeling nerdy, read all about it here.

More critically, xAPI is better, because of reasons including:

  1. The schema is extremely pliable. xAPI has very few restrictive paradigms. 
  2. It’s backwards compatible. You can map SCORM statements across to xAPI, but not vice versa.
  3. The data you get out of it is significantly more informative. 

If it’s so good, why is it not as popular?

I think there’s a whole bunch of reasons xAPI hasn’t yet taken off. As I mentioned earlier, it has a number of names which creates an aura of confusion around what it is and how it works. For one thing, people don’t know what to Google to find out more about it.

Secondly, the entry barrier is a bit higher…

For a SCORM package, all you need is an authoring tool and a LMS.
For xAPI packages though, you need a third thing, called an LRS (Learning Records Store).

In a nutshell, an LRS is a database where xAPI statements get stored… statements such as:

  1. Jane browsed slide 2 of 16
  2. John answered 13 calls yesterday.
  3. Joe created a new event.

As you can see, xAPI statements are a bit more qualitative and descriptive in their nature. They describe an actor, a learning object and a verb. They may be simple statements but there’s a lot of data tucked in there… And that data is being churned more frequently than it would in an equivalent SCORM package. 

All that data has to go somewhere, and that somewhere is usually an LRS. The problem there is that an LRS is another thing to worry about. It’s an additional system that you have to maintain & know how to use. 

Harvesting, codifying, and analysing performance & training data is a critical capability for growing businesses and academic institutions. That’s precisely what an LRS enables.

What does Nucleus have to do with any of this?

We (i.e. Nucleus) want to see the industry eject itself forward into the future, rather than embrace the comfort zone of the past. I for one want to see the industry go SCORM-free before I go into retirement on a sunny beach somewhere. This meant that we had to tackle the issue of “How do we get people to try xAPI”…

First and foremost, we are keeping SCORM support (at least SCORM 1.2). The rationale here is that SCORM is popular, and is going to be around for a little while longer whether we like it or not. 

We are however mapping SCORM statements to xAPI statements. This means that our customers, the ones that use Nucleus Experience, can actually get meaningful xAPI data out of old SCORM packages, which is nice. We are also hoping that by doing this, SCORM-aficionados will get to know xAPI better and come to appreciate the data fidelity, and slowly move on over to xAPI.

Secondly, we are offering all our customers an LRS, out of the box. It’s already built and integrated into their instances of Nucleus Experience (the LMS counterpart if you will), so they don’t have to worry about maintaining it in any way.

Screenshot of a custom xAPI statement injected into the built-in LRS

Thirdly, we are working on educating our users on when SCORM may not be the best option, and we are giving them the tools necessary to produce xAPI instead and know how to get the best out of it.

Subtle indicators: In the Experience learning platform, we use exactly the same icon for xAPI and SCORM, but we indicate to the user that xAPI is preferred through colour. A colourful symbol beside a B&W one communicates that it’s a more modern option.

We are also adding xAPI export as an option to our Authoring platform by default. You can still export to SCORM if you want to, but at least now exporting to xAPI is the default thing.

Last but not least, we have developed API endpoints for our LRS instances. This allows our users to push data into their LRS or take it out and put it in another business intelligence system like Tableau or QlikView for further analysis. It’s free of charge of course. 

We think that by allowing our users/admins to hook up Nucleus Experience and the LRS within into their organisational ecosystem, it might ease the burden of tech adoption.

Thumbs Yes GIF by SpongeBob SquarePants

Anyway, over to you… What do you think? Have we convinced you to try it out?

Go on. Head on over to https://experience.nucleus.ac

Tim Tamimi

I'm proud of having worked for the likes of Ofsted and colleges + universities in the South West for 7 or so years before cofounding Nucleus with Curtis. I'm thrilled that we have this opportunity to give EdTech a facelift through taking an effectiveness-led approach to developing learning solutions.

Leave a Reply