Extending the SCORM wrapper and ActionScript classes

I’ve had a number of people ask me about extending my SCORM helpers (the JavaScript-based SCORM API wrapper and the two ActionScript classes) in order to completely remove the need to know any of the “cmi” calls.

For instance, being able to do something like this:

scorm.bookmark = "page1";
scorm.status = "incomplete";Code language: JavaScript (javascript)

instead of

//SCORM 2004
scorm.set("cmi.lesson_location", "page1");
scorm.set("cmi.completion_status", "incomplete");

//SCORM 1.2
scorm.set("cmi.core.lesson_location", "page1");
scorm.set("cmi.core.lesson_status", "incomplete");Code language: JavaScript (javascript)

This level of abstraction is very attractive for a couple of reasons: it means the developer doesn’t need to know SCORM 2004 versus 1.2 syntax, and it uses more concise code (which is easier to type and generally means less typos).

So, understandably, people are asking me why I haven’t added this level of abstraction into the SCORM helpers.

I have three reasons: SCORM is not that simple, the functionality between SCORM versions is significantly different, and extending the helpers that far means writing a complete (non-standardized) replacement syntax for SCORM.

SCORM is not that simple

SCORM is very complex, and trying to abstract the cmi calls gets very sticky very quickly. The examples I gave a moment ago are very simple examples that lend themselves well to an abstraction layer. However, SCORM can do much, much more; when you start getting into objectives and sequencing, this abstraction model becomes very difficult to maintain.

For instance, the “interactions data model element” (section 4.2.9 of the SCORM 2004 RunTime Env documentation) uses elements such as “cmi.interactions.n.objectives.m.id” where n and m are variables. The abstraction layer would need to handle these somehow, which leads to code such as

scorm.interactions[n].objectives[m].idCode language: CSS (css)

To me, this isn’t much of an improvement in ease-of-use, but for argument’s sake, let’s say it’s do-able and move to the next point.

The functionality between SCORM versions is significantly different

Simply put, SCORM 2004 can do more than SCORM 1.2. They share a set of basic functionality (bookmarking, setting lesson status, saving suspend data, etc.), but SCORM 2004 includes sequencing and navigation features that aren’t available in SCORM 1.2.

If someone unfamiliar with SCORM functionality tries to use the SCORM helpers in a SCORM 1.2 environment, they might attempt to use SCORM 2004 features that aren’t available, resulting in errors.

It would also take a significant amount of work to abstract all of the dense sequencing and navigation elements. Considering 80% (my guess) of SCORM users consider the sequencing and navigation feature to be broken and unstable, is it even worth it? Probably not.

But assuming we decided to continue with the project, we’d come upon my third concern…

It becomes completely non-standardized syntax

The point of a standard like SCORM is to ensure everyone uses the same terminology. My SCORM helpers are designed to make a developer’s life a little easier while still adhering to the SCORM standard. When you ‘wrap’ the SCORM code in its entirety, you will wind up with some people using SCORM without understanding it at all.

If the goal is to make SCORM easier to use, that can be a good thing. But there needs to be a balance between ‘easy’ and standards-compliant. By making developers use the “cmi” elements in their get and set calls, I’m basically ensuring that they’re looking at SCORM documentation in some form, which hopefully means they should understand what SCORM can and can’t do.

Bridging the needs

I confess that when I wrote the wrapper and ActionScript files, I made an attempt at abstracting or wrapping the entire SCORM spec. As you can imagine, it wasn’t fun. After stepping back and evaluating the situation, I decided to stick to the ‘core’ functionality contained in the current pipwerks SCORM wrapper and ActionScript classes.

Remember, the pipwerks SCORM helper files perform other dirty work, too: The primary purpose for the pipwerks SCORM API wrapper is to locate and connect to the SCORM API in the LMS, while maintaining a clean global space. The primary purpose for the pipwerks SCORM ActionScript classes is to handle Flash-to-LMS communication automatically, so you don’t need to get your hands dirty with ExternalInterface. (Anyone who’s had to use SCORM with FSCommand or GetURL knows what a pain Flash-to-LMS communication used to be!)

These functions were my primary goals; simplifying the syntax was almost an afterthought. However, as I mentioned at the beginning of this post, I’ve received a number of emails from people asking about extending the wrapper to include all SCORM syntax. I interpret this to mean that a lot of people are interested in using standards, but most of them don’t want to be bothered with the details or have to learn the whole standard. This means they view SCORM as an important standard, but also find it difficult and inconvenient to implement. I agree.

This kind of reminds me of the Macintosh. People wanted to have a computer and be able to do cool computer stuff (games, word processing), they just wanted it to be easier. They didn’t want to be bothered with details about the operating system or hardware specs; they just wanted it to work out-of-the-box, no muss, no fuss.

SCORM isn’t about ease-of-use. If it was, we wouldn’t have these crazy imsmanifest files that are total overkill for simple courses (I wish we could use JSON for a manifest!). SCORM 2004 has been around for four years, but SCORM 1.2 is still going strong. Why? SCORM 1.2 is easier to implement.

Soaking all this in, perhaps I should resume my work extending the SCORM wrapper (and maybe get some of you to pitch in a bit! ;)). One of the ideas I’ve been kicking around is leaving the wrapper and ActionScript files as-is but creating extensions for them. This way the extension is available if you want it, but if you don’t, you can just use the core functions.

What do you think? Please weigh in if you have an opinion.