Preach it Rands.
When Rands says, “sales is historical” I just hear chanting in my head: “history is a trap.” Then I start thinking of the innovators dilemma and how to avoid the historical quicksand.
Passionate geek alert–you might want to approach with caution until there’s a little less juice in the pipe. I’m a pretty persistent change monger and now my battery is all charged up. Now to just find a few geeks who are willing to plot nerd-world domination and fix bayonets. I wonder if the big cheese will let me cordon off my office and declare it a separate organization…
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:
Last week a link was quietly dropped on the TechSmith website which includes the ActionScript 2 source code and graphical assets for Camtasia Studio’s ExpressShow Flash playback wrapper. This package allows Flash developers to the customize look / feel and behavior of the playback controls, hotspots, quizzing and captioning for Camtasia Studio 5.x ExpressShow screencasts. Instructions for compiling and using the new wrapper with Camtasia Studio are included in the zip. If you end up creating a custom skin or adding some cool behavior leave a link to a screenshot or screencast.
Simplicity. A word to live by. An unending quest. The holy grail of software. As software makers our raison dâ€™Ãªtre is making complex tasks easy. We’re back to that elusive word–simplicity. In a beautiful twist of irony it turns out that even thinking about simplicity involves a great deal of complexity. Enter John Maeda’s Ten Laws. I’ve read Maeda’s laws in the past, but as I’ve matured as a software developer they resonate more and more with each passing day. Here are a few of my favorites: