likes / dislikes - SCORM edition

Things I like about SCORM:

1. Portability. The wonderful theory that I should be able to export a course package from one LMS and seamlessly import into another LMS. It's nice to have these kind of dreams....



2. The API. There is an abundance of examples and sample code and wrappers to help you make your first Learning Object communicate with an LMS, and being able to design Flash Objects that pull the user name and report scores is kinda cool and easy when you get the hang of it.



3. Authorware. Over the past five years, Course and Assessment creation software has made leaps and bounds in quality (Adobe, Articulate). I do believe this area has a lot of room for new companies to enter the compitition, which is great because we should see a steady improvement in solutions.



4. Branching. If properly supported by an LMS, it will allow course designers and developers to create a learning path that adapts to the user, which is the first step in emulating how a teacher adapts to a student.

Things I dislike about SCORM:

1. Out of date, clunky Dreamweaver extensions. Did developers just give up? it seems like there should be more options when it comes to compiling a SCORM package from a Dreamweaver site.



2. Inconsistency in LMS SCORM implementations. I've seen packages being imported to Course Level, Module Level and Asset Level depending on the LMS, I've seen numerous LMSs just ignore SCORM interactions.



3. 2004 Sco to Sco navigation - I feel like this should be easier to implement than it sounds.



4. Limited use of CSS. Because SCORM packages are these 'self dependent' objects, it becomes impossible to properly maintain the look and feel of a facilities e-learning products using CSS. There are ways around this on an LMS by LMS basis by looking into the folder structure where courses are imported to, but this is simply a hack and not a solution. Obviously we can still have one CSS per SCORM object, but what happens when a facilities rebranding occours? each object's style sheet will have to be updated and then the package will need to be re-imported.



5. The fact that the people most interested in working with SCORM, are usually teachers, subject matter experts or instructional designers and not usually developers. This is not really anyone's fault since we are talking about a standard for web communication which understandably becomes a developers game, but it is a shame that the current state does not allow for enthusiastic educators to quickly turn their ideas into SCORM materials. I think as more and more Authorware becomes available this problem will eventually shrink, with Developers being moved from working directly with the educators to creating software for the educators.

That's all, Stay Classy Internet.