SCORM 2.0 white paper submission

I submitted my white paper for SCORM 2.0 today. I don’t see it listed on the LETSI site yet, but I’m hoping they received it and that it will be added soon.

I wanted to share a few things about my experience writing that paper. First of all, it wound up being a very informal paper, and doesn’t really follow the structure the LETSI folks had requested (sorry, guys). I went through a number of false starts (about seven, I think) trying to nail down what I wanted to say; even now that I’m finished, I still feel like I didn’t quite express everything I wanted to say. SCORM is just so… nebulous, and the potential for scope creep with SCORM 2.0 is so strong that I had a hard time keeping my comments focused and concise.

In the end, I wound up writing something of a stream of consciousness that mostly served to get some of my concerns and notions on the official record. When I see the scholarly work some of the other participants submitted, I feel rather embarrassed, but hey, such is life!

Speaking of other papers, I took the liberty of reviewing many of the submitted documents, and I must say, I’m impressed! There’s quite a range of material and opinions, and it looks like there’s some very interesting ideas in there. From what I can see, SCORM 2.0 might wind up being a simplified and cleaned up version of SCORM 2004, or it may be a completely different animal consisting of all kinds of new features supporting the latest trends in e-learning and web technology.

I especially agreed with one of Mike Rustici‘s points:

The ‘burden of complexity’ [should be] on the LMS developers. […] It only makes sense that the LMSs should have to do the hard work and that SCORM should be nearly transparent to content developers.

This goes along with my primary motivation: make SCORM easier for content developers! Otherwise no one will want to use it and it will become useless and will be replaced by proprietary workarounds. As Rustici says, “Sequencing needs to be simplified so that it is easier than creating your own alternative.” I say this is true for all of SCORM, not just sequencing.

White Paper Addendum

Here are a few odds and ends I left out of the paper that I think are worth putting on record. These are in addition to my previous suggestions for SCORM 2.0.

A lite API. If content aggregation remains part of the core spec, can we implement a ‘lite’ API that simplifies SCORM use for single SCO courses? (The reasoning being that single SCO courses shouldn’t be forced to use full manifests and other heavy configuration items that aggregated courses will require)

SCORM security via a Web service. One potential benefit for using a web service for SCORM in lieu of a ECMAScript API is security; ECMAScript is inherently insecure, and a web service (depending on the communication protocol being used) may be easier to encrypt and protect.

Frames and session states. I my paper, I only mentioned this topic in passing, but it’s worth fleshing out a little bit.

SCORM’s current ECMAScript API requires an active JavaScript connection with the course; If the course’s connection to the SCORM API is lost, the course can’t exchange SCORM data with the LMS, effectively killing the course’s tracking functionality. Any time a webpage is unloaded in the browser, that page’s JavaScript is terminated. This is a simplistic explanation, but the point is that the browser won’t allow JavaScript to maintain a session across pages. (A session is data that persists from page to page as a user navigates through a website.)

To get around this limitation, websites often use some trickery. The most common workarounds are:

1. Traditional framesets
2. iframes
3. Flash

The frameset workaround uses the parent frame to maintain session data; the parent frame never reloads, and thus never ends the session. All page loading/unloading occurs in a child frame.

The iframe workaround is much like the frameset workaround, except it uses a single inline frame instead of a full frameset.

The Flash workaround is simple: the HTML page contains a Flash movie that handles all content; the HTML file itself never reloads, allowing it to maintain a JavaScript session, while the Flash content does all the dynamic loading and unloading of content without impacting the HTML file.

Since SCORM requires an active JavaScript session to maintain communication with the API, most SCORM courses are forced to use one of these three workarounds. The problem is that all three of these methods have significant (and well-documented) usability and accessibility issues.

If SCORM 2.0 can implement some kind of Web service that eliminates the need for a JavaScript/ECMAScript API, we can also eliminate the reliance on these three workarounds. This will serve to make e-learning courses much more accessible, and reduce developers’ reliance on JavaScript.

Have you read any of the submissions?

If you’ve read any of the whitepaper submissions, I’d be interested to know which ones caught your eye or made the hair on the back of your neck stand up. And if you have opinions on the papers, definitely submit your comments to the LETSI site… they need all the feedback they can get. After all, SCORM 2.0 is for us; make sure your voice is heard!

---

Comments