SCORM 2.0 needs to learn lessons from the past:
- Don’t let whoever wrote the spec / documentation for versions 1 and 2 anywhere near the spec (well just don’t let ‘em write anything public facing). ;-)
- Nix sequencing. This should of been laughed away with the first draft (again, probably brilliant minds at work, but way over engineered).
- Eliminate metadata from the spec. Instead recommend that Dublin Core (or flavor of your choice) be used inline in the html entry point or injected via XMP. Allow it to be bolted on, but DO NOT make it a part of the spec. I get metadata. I think its critically important, but it doesn’t belong in the spec.
- Eliminate the manifest file and define an entry point naming convention (entry.*).
- Make a REST API spec. A solid API is all you need for interoperability. This should make it way easier for LMS / server-side developers and content creators alike to implement.
- Eliminate all of the packaging crud. Just zip your files up.
- Actually write real documentation for the API. Build lots of working examples. Make it approachable / accessible.
- Destroy all traces of SCORM 1.2 and SCORM 2004. Seriously. The biggest problem is I have with SCORM 2.0 is that its going to take years for it to become codified and implemented. All the while the existing specs will continue to calcify. We need a scorched earth policy folks–something that forces us to rebuild and move on.
Three simple steps to relevance:
- A simple packaging system (a zip file). Described in simple terms (one sentence please).
- An entry point naming convention (entry.*).
- A simple rest API. No bloat. Keep it simple and straightforward.
I have little hope that such a simple recipe will emerge from LETSI, but from my ivory tower this is the only way I can see the ocean. However, there is great conversation taking place and that’s reason to hope. I encourage everyone interested in the space to check out the links below.
LETSI Call for White Papers / White Papers:
Aaron Silvers - Get Involved:
Tom King - Get Involved + War of Words:
3 Comments
You said “The biggest problem is I have with SCORM 2.0 is that its going to take years for it to become codified and implemented.”
This is true for a number of reasons, most of which LETSI (and ADL in the past) could not control. When the documentation is finally completed (which takes alot of testing and reviewing) you have to wait for the system vendors to hit an “update” point in their software lifecycle. If SCORM 2.0 were released on Monday, and a vendor had just released a new version of their system on Saturday, they wouldn’t begin working SCORM 2.0 on Monday they’d wait until Thursday or Friday (maybe even Thursday or Friday two weeks from now). And, just like the documentation taking multiple test and review cycles, each vendor also needs those test and review cycles to ensure their product meets the specified requirements. And, let’s remember that each system vendor is on a different software lifecycle. SO…. In the interim, a “scorced earth policy” would mean destroying all of the systems and content that currently work.
Is any of this ideal or perfect? No, but welcome to the world of specifications and standards.
LETSI looks forward to seeing a white paper with your ideas for technical solutions, and we’d welcome any concrete recommendations for how to make this process faster and easier!
I think we’re at a great point to begin moving into the next generation of content packaging and operation. I tend to agree with you on the complexity and sophistication of the standards. However, it could have been far worse. For the most part, we have some protocols that work in a lot of cases where they likely would not have before. SCORM has enabled a lot of activity (I’d say advancement, but I don’t have a high opinion of most LMS or content tool vendors) in the vendor space and we’ve seen some good things come out of it - not the least of which is a propogation and acceptance that trackable content should be used.
I would like to see a tiered / abstracted protocol for the API. It’s nice, but unnecessary and counterproductive (when LMS vendors each support a different flavor of the implementation), to have control over the value of cmi.completion_status from the content. Why am I dealing with this string based logic from the content? How many fairly common methods am I having to set up a rube-goldberg chain to set? And how often is the LMS going to want to hear something only slightly different?
How about a common set of Wrapper > LMS API calls for a simple protocol tier. These could be delegates for more sophisticated classes or the simplest base classes for more sophisticated functionality.
setComplete(bool);
//toggles the completion of the SCO to the boolean value - let the LMS sort out how it’s going to set the completion_status variable since it knows what it wants anyway.
setScore(int);
//sets the score for the package
Anyway - you get the point. If we have a simple set of methods to work with that abstract as much of the functionality and sophistication away from the typical developer we’ll be doing a service to everyone. Frankly, some of the things we are trying to do really belong on the LMS end, IMO (the completion_status string setting is one example.) Imagine having 6 common simple calls… It’s more friendly than some of the relative complexities with current standard packaging practices (I know, i know… we have some control over that as developers by customizing our API Wrapper and framework — still…)
The biggest problem I have with the current standard packaging is the promise of reuse and sharability — not many are sharing content or reusing. I think we’ve focused on the manifest as the primary defining mechanism and we have ended up with monolithic packages, often with content that is compiled in places where it needn’t be (Flash). This makes the content largely non-reusable. This ISN’T SCORM’s fault… But it is a function of the focus of the standards. We have followed a pattern that has been built up by tool vendors…
More in a few - gotta jam.
Interesting - it’s the run-time part of SCORM I would have got rid of first, as it’s what seems to cause the most problems.
But I agree totally about creating a much simpler packaging spec. It’s what I argue here: http://www.learningconversations.co.uk/main/index.php/2008/08/08/scorm-warning
However, one of the main problems with SCORM is it’s just not rich enough… It’s only about delivering and tracking content. What happens to the learner interactions, the forum posts, the wiki entries, the shared bookmarks? None of that gets moved across.
My vote is to document and use the already open standard which is the Moodle backup format (XML containing all the database entries + course files all contained in a single zip file). This format should be rich enough for most LMS’s to interpret.