SCORM 2.0 – Simplify And Make eLearning Relevant
Posted by brooks in SCORM on Jul 29th, 2008 | 6 commentsSCORM 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:
The Elearning Industry Is Dead
Posted by brooks in SCORM on Jul 8th, 2008 | 9 commentsI’ve got lots of respect for Tom King, but I’d say he’s underselling the depth of the problem. In my view, DOD dollars are the only thing propping up the current system.
I’m not sure I’ve ever met anyone, outside the DOD / ADL who doesn’t think SCORM and AICC are over engineered pieces of junk. And the LMS / LCMS products and vendors engender pure hate at every contact point whether purchaser, content develoeprs, admins or end users. Do a couple of white-papers do anything to help remedy the situation?
Event-Based LMS / Flash Communication
Posted by brooks in Flash, SCORM, Tutorials on Jun 7th, 2005 | 10 commentsThose who work in the eLearning field, know that Flash SCO (Shareable Content Object) to LMS (Learning Management System) communication is an ugly mess. The SCORM RTE specification requires JavaScript as the communication bridge between a SCO and and the LMS. JavaScript is asynchronous in nature which means that any time you make a request for information from the LMS you must enter into some type of “loop” waiting for a response–typically this takes the form of an interval, or a frame based loop. In the past I’ve used setInterval to evaluate whether properties returned from the LMS have changed, but this always felt rather ugly to me so I decided to implement an event based system which uses Object.watch and EventDispatcher. Here’s what I came up with:
/**
* @author Paul Brooks Andrus
* Creative Commons License
* http://creativecommons.org/licenses/by/2.5/
* This work is licensed under a Creative Commons Attribution 2.5 License
* June 6, 2005
*/
import mx.events.EventDispatcher;
import mx.utils.Delegate;
class Watcher {
function dispatchEvent(){};
function addEventListener(){};
function removeEventListener(){};
function Watcher() {
EventDispatcher.initialize(this);
}
/*
* Creates a watched property using the scope of the first parameter
*
*/
public function watchProp(s:Object, p:String):Void {
s.watch(p, Delegate.create(this,returnProperty), s);
}
/*
* Removes watch from the scope defined by the 4th parameter, returns
* the value of the watched property and dispatches an event object
* with all the information from the watch
*
*/
public function returnProperty(p:String,ov:String,nv:String,s:Object){
s.unwatch(p);
dispatchEvent({type:"change", prop:p,value:nv,old:ov});
return nv;
}
}
The solution, as you can see, is simple, reusable, very clean and allows the use of the familiar event-listener model. You can download the source here.
