SCORM 2004

February 6th, 2004 § 2 comments

The long-waited new SCORM version, previously referred to as 1.3 and now renamed to SCORM 2004, was released in the last January 30th. It’s basically what had been promised with a few last-minute changes.

Of all changes, the most significant is the inclusion of the sequencing and navigation models. Those changes were among the most requested by users and will certainly help to improve the quality and flexibility of courses running under any SCORM-compliant LMS.

Sequencing, as the name itself says, is about the behavior of a course; about the way progress is defined on it. Sequencing delineates the requisites and constraints placed on each learning object allowing the course creator to impose a logical order between them so that all users can execute the course in the same consistent way.

Navigation, on the other hand, allows a course to initiate navigation events as they are being executed, in response to user actions. It follows the constraints placed by the course’s sequencing model, however.

Both sequencing and navigation add to the range of run-time options available for SCORM-complaint courses, even though, as remarked in the standard specification itself, they are not full-blown systems, able to provide for all the needs of a course. The specification is meant to create a simple, albeit usable, ways to courses improve on their communication with users.

All other changes in the specification, whether in the run-time environment or in the content model, are merely evolutionary. New elements were added and some others were changed to allow for a better interaction between a course and its SCORM host, but they don’t change the way the standard works. On the other hand, the specification itself was reformulated to clarify some existing doubts about the way some elements and methods in the run-time should be implemented, and that’s a huge benefit by itself.

On the whole, this version was intended to evolve rather than to revolutionize the standard. The standard’s existing flaws are still there, and much of what’s needed to really make it useful at large (at least, in my opinion) are far from being implemented. Nonetheless, this new version at least signals that the standard will continue to go forward, and I hope future versions will bring more significant changes to it.

§ 2 Responses to SCORM 2004"

  • John Benson says:

    Can you expand on “The standard’s existing flaws are still there, and much of what’s needed to really make it useful at large (at least, in my opinion) are far from being implemented.”

    that is, what are the existing flaws?

    what do you mean by “…what’s needed to really make it useful at large”

    thank you


  • Ronaldo says:

    John, I elaborated on the issue of existing flaws in the standard on my firstpost about the subject which you can find searching for “SCORM” in the site’s search function. To sum it, I consider the reliance on client-side programming to be the biggest flaw in the standard.

    About what’s needed to make it useful at large, I believe SCORM must allow for server-side processing by way of a common API. It’s impossible, for example, to create a database of questions for random use in a course unless you put it in the client, in case which the database can’t be expanded without republishing the course. Also, since the answers are also on the client, any users that knows how to use the view source command in the browser can see the answers — unless they’re obscured somehow. That’s but one example of the problems with the current standard. There are many other issues involving security, transactions, tests, and thegeneral flexibility of the standard that makes it less useful than itcould be.

    I hope this helped.

What's this?

You are currently reading SCORM 2004 at Reflective Surface.