Is your elearning broken?

Many years ago, one of my first elearning projects was for the National Health Service. We were working with the Modernisation Agency (MA), an organisation within the NHS with the explicit aim of improving the patient experience (Wikipedia).

It was also my first introduction to "Lean Thinking", the idea that by reorganising how we do things, and removing waste, you can increase the "value" you bring to your customer (Lean Enterprise Institute - What is Lean?).

The MA had been tasked by the then Prime Minister, Tony Blair, to reduce the wait at Accident and Emergency to fewer than four hours. Their research had shown that this was totally possible by using a Lean approach. By focussing on how patients flow through hospitals and removing blockages, they were able to consistently drop the waiting time to below that target.

We were brought in to help roll out those changes to almost every hospital in the country. It was a massive programme, with two (at first) components:

1. A set of elearning modules, designed to teach everyone involved the basics of the approach
2. Training for local facilitators who would help their hospital teams to implement the approach in a way that worked for them, through a structured set of sessions

In theory, it was a brilliant plan. A consistent message went to everyone, that was to be worked out locally.

In practice there was one big flaw, which is still evident in most elearning even today...

The elearning packages were full of detail, practice activities and useful information. The instructional design was superb (partly down to the truly "agile" way in which they were developed with our subject matter expert - but that's another story...)

Our target audience, a mixture of nurses, bed managers, administrators and other hospital staff also felt the packages were a great help as they went into their facilitated sessions.

But they gave us one important piece of feedback:

They couldn't find the useful stuff...

It was fine while they were working through the modules. Everything flowed well and gave them a lot to think about in a very structured way. It was afterwards that was the problem; when they were trying to make things happen back at work, or even during the workshops. They would remember that there was something useful and relevant for them right now, but the only way to find it was to trawl through from the beginning until they found it.

It was like giving them a book that they could only read sequentially, with no contents page and no index. Not ideal.

To solve this immediate problem, we built a separate knowledgebase. We took all the useful content from the elearning packages, and built it into a standalone menu-driven website. In addition, and this is key, we incorporated a search engine into the website. This was before content management systems became mainstream, so we used a fantastic piece of software called Zoom Search (which I've discovered is still available: https://www.zoomsearchengine.com/zoom/). It indexed our knowledgebase, and provided an interface for people to find what they needed, when they needed it.

This was our first introduction to the need to support just-in-time as well as just-in-case.

These days, the idea that you build activities (or experiences), supported by resources, is very common. It's espoused by people like Nick Shackleton-Jones and Cathy Moore amongst many others, including me.

The problem is that our learning systems don't really support it - in particular, SCORM.

The whole idea behind a SCORM package is that it is portable (able to move from one system to another), and therefore it must be entirely self-contained. If you adopt the SCORM philosophy properly, your SCORM package won't link out to, or rely on, any materials outside of the package.

To run inside a Learning Management System (LMS), a SCORM package must be "launched" using a list of starter files stored in a "manifest" file. The LMS doesn't actually know anything about the content other than what is stored inside the manifest, and what is provided in a separate metadata file. In most cases, all you'll get is a title, and maybe, if you're lucky, a description.

It is impossible for any search engine to reach inside the SCORM package to understand what is inside it. And similarly impossible to create an index that allows you to link directly to a specific page inside the package. Everything has to go through the starter file.

That's why our elearning is broken. It's impossible to search, therefore impossible to meet that "just-in-time" need, and thus incredibly difficult to create materials that will ever be used more than once.

Some people have tried different solutions:

There are authoring tools that allow you to index and then search inside the package. But this relies on you already being inside the package - ie. knowing which one to look at. It still doesn't give the experience we expect from our daily lives of a single search engine that will find what we need from wherever it's stored.

There are some authoring tool and LMS combinations that are tightly integrated, so that the LMS is able to index the data stored in the authoring tool rather than in the SCORM package. That's great if the combined system works for you. But you are rather locked in at that point (not that that's a bad thing, it's just something to be aware of).

There are some learning architecture approaches which keep the activities inside the SCORM package, and any resources outside the package, probably stored in a separate content management system. This does break the SCORM philosophy of being self-contained, but can work well, particularly if you're able to use some neat developer tricks to display the resource content as a "modal popup" from within the package. What it does mean is that you need to be really careful to keep the two content sources hooked together and synchronized.

It is possible, in theory, to use a content authoring tool that puts its content completely outside of the LMS, and uses xAPI (Exploring the potential of xAPI booklet) to pass learning records out to a record store. This would, again in theory, make the content available to any suitable search engine and allow you to build both experiences and resources in the same tool. These tend to be systems that are in the Learning Content Management System arena, but I've not yet found one of those that can build experiences as rich as the more traditional authoring tools.

So, this story isn't over yet. There's a lot of work to be done to fix the problem.

In the meantime, we need to decide on where our priorities lie. Is it with learners who need an experience, or learners who need resources? It's unlikely you'll find that the same tool works best for both.