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.
To get around this limitation, websites often use some trickery. The most common workarounds are:
- Traditional framesets
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.
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!