Most e-learning developers don’t care about SCORM and only (begrudingly) learn enough to get the job done. I don’t blame them. The other day I was reading some old Drupal community posts (circa 2005) about adding SCORM functionality to Drupal. One comment stood out:
SCORM was the big buzz in 1999 and 2000 when I was at Oracle Denmark working on “object oriented” e-learning […] but it is no surprise that it is not so much a real world success, as it is more pleasing to the theorist, than to the producer.
“More pleasing to the theorist than to the producer.” I’m not sure if the author was referring to his own work or SCORM, but I think the phrase certainly applies to SCORM. This crystalizes what I’ve been trying to do with my SCORM wrapper and ActionScript classes: simplify SCORM so the average web developer can get their courseware to work in SCORM-conformant LMSs without having to become a SCORM expert.
This brings up the never-ending question when it comes to using SCORM in courseware: What are you really trying to do with SCORM?
What was SCORM designed to do?
SCORM stands for Shareable Content Object Reference Model. What does this mean? According to the ADL website, “SCORM is a collection of standards and specifications adapted from multiple sources to provide a comprehensive suite of e-learning capabilities that enable interoperability, accessibility and reusability of Web-based learning content.”
The general idea is that a course developer can re-use elements from course to course, be it a small piece of content such as an image or an entire course lesson. A common example is from the military: if the Army has created a course that contains a lesson in how to safely use a fire extinguisher, any other branch of the military should be able to import that exact content into their course without having to re-write or re-develop any of it. This avoids duplication of effort, which (theoretically) saves the government a ton of money.
SCORM also serves as a communication standard for courseware, which allows a developer to create a course that can be used in any SCORM-conformant LMS. Before SCORM (and AICC), many LMSs only supported their own proprietary course-to-LMS communication systems. This meant that if a course developer or vendor wanted to make their course work on more than one LMS, they had to re-code the course to use each LMSs’ proprietary system. Even worse, not all LMSs had the same feature support, such as quiz scoring and bookmarking. When the US Military required SCORM to be supported by LMS vendors, it was basically ensuring its courses wouldn’t need to be re-developed or re-coded for each LMS, and established a baseline of feature support that would be expected from all LMS vendors.
That’s nice, but…
As I explained, the SCORM developers devised a complex system of cataloging course content (the metadata you find in the imsmanifest file), as well as a sequencing and navigation schema which should allow a developer to simply insert a link to content (or another SCO) in the manifest, and let SCORM handle the rest. Sounds great, but guess what? Full-blown SCORM is impractical and unreliable.
The theorists who devised SCORM will say that you should be building courses using an intricately woven set of reusable SCOs, bound together by an imsmanifest XML file bursting with links to course content files and related metadata. They have attempted to provide a sequencing and navigation system that can be used to navigate within and between SCOs. These are noble efforts, but they don’t really help most e-learning developers.
Why? Two reasons: Shareable content is problematic to implement, making it useful to only a small percentage of developers, and SCORM is usually not the starting point for a SCO’s internal navigation mechanisms.
Shareable content is problematic to implement
The whole theory behind SCORM’s content and SCO interoperability is really nothing more than theory. It’s not useful for most e-learning developers. In their attempt to maximize flexibility and practicality, the SCORM guys actually made SCORM a less practical option, and more of a headache to use.
Shareable content (including SCOs) implies that the content is generic enough to be reused in different organizations and with different course styling/visualization. This a long shot, and doesn’t take into account the myriad visual design styles developers may choose to use. The only way around this issue is to use a strict formatting approach, which might work in a tightly controlled organization, but not in a general community sense. But for argument’s sake, let’s say everyone agrees to use the same color schemes and fonts in their files. There’s an even bigger issue to deal with: the technology itself, namely file formats.
What if one developer only works in Flash, while the other only knows HTML? What if one Flash developer only uses ActionScript 2 while the other Flash developer only uses ActionScript 3 (the two are completely incompatible)? What if one developer uses XML with Flex while another only uses rapid e-learning tools such as Captivate and Articulate Presenter? For that matter, how can SCORM support the growing online synchronous e-learning market or the booming mobile learning market?
When you stop and look at SCORM’s reusability/shared content model, it simply can’t support today’s rapidly evolving web-based technology. And for the few organizations that manage to use SCORM for this purpose, it’s an extremely difficult task to manage. So what about the developers who don’t use SCORM for shareable content, but choose to simply use SCORM as an LMS communication protocol? SCORM becomes overkill, most notably with the sequencing and navigation feature.
SCORM is usually not the starting point for course navigation.
Third-party rapid e-learning tools use the same approach: get the course to work on its own, then when publishing, go ahead and add the required tracking code, be it AICC, SCORM, or the numerous other formats that have popped up over the years. Thus, navigation is almost always handled internally and not via SCORM.
Continuing with this train of thought, my interaction with the e-learning community has led me to believe that many e-learning developers are either SMEs using rapid e-learning tools, or are traditional web developers doing some freelance Flash or HTML work. In the case of the web developers, they build the course to do what they want, with the minimal functions they need for their client. When it comes time to load the course in the LMS, they suddenly realize they need to add SCORM support; SCORM was never considered an integral part of the course, and is considered something of an inconvenience that must be tolerated for the sake of making the course work in the LMS and keeping the client satisfied. The SMEs using rapid e-learning tools are lucky because they can just change the publishing preferences; the web developers have to go in and augment their code by hand. In either case, the course developer did not start the project thinking “I’m going to use SCORM to handle my navigation!”
What do you want SCORM to do, then?
SCORM is not perfect, but we must concede that it’s still the strongest available technical standard for elearning. There are others (AICC, Common Cartidge Alliance, etc.), but SCORM is by far the most widely supported standard. The exciting news about SCORM is that it is being handed off to a new organization, LETSI, which will hopefully breathe new life into the standard. Matter-of-fact, LETSI has solicited white papers and suggestions for improving SCORM from the general public. Knowing this, we should stop and seriously consider: What do we really want SCORM to do? What should it handle, and what should it keep its sticky fingers off of?
Here are my thoughts. Please add your own in the comments section!
1. SCORM should be broken into separate and clearly differentiated APIs or functionality. The first — and only mandatory — API should be simple course-to-LMS communication. The second should be a reusability/shareable content mechanism that can be used if desired. The third should be an optional navigation API that can be used regardless of whether shared assets are in play. A fourth potential API could be a quiz/exam API that provides an easy-to-use framework for handling quiz data and results. (And NO, the IMS’ QTI specification is NOT easy to use by any stretch of the imagination! Let’s not pretend it’s the best solution, because it isn’t.)
2. SCORM’s course-to-LMS communication protocol should be simplified and strengthened. As-is, SCORM already does a decent job at this task, but there are a number of ways it can be improved.
- Simplify (or eliminate!) the imsmanifest file. For courses that don’t use shared resources and don’t use SCORM for navigation or sequencing, the imsmanifest is an extremely bloated and annoying document. It is by far my least favorite part of the SCORM spec., and I know I’m not alone in that sentiment. When talented developers who write code in their sleep have a hard time writing what should be some simple XML, and wind up relying on plugins and third-party applications to auto-generate their manifests, you know there’s a problem somewhere. There must be a way to simplify the manifest if SCORM is only being used as an LMS communication protocol.
- Use proper data types. For instance, don’t return a ‘stringified’ boolean, return a real boolean.
- Simplify syntax. This means creating an easy-to-use set of base commands such as API.init(), API.quit(), API.set(prop, value), and API.get(prop) instead of the more verbose (and boring) API.Initialize(), API.Terminate(), API.SetValue() and API.GetValue(). (On a related note, API.Initialize and API.Terminate should NOT be required to pass an empty string (“”); the empty string serves no purpose and only creates the potential for more unnecessary errors.)
3. All CMI elements should be re-examined for usefulness. Personally, I never use over 2/3 of the existing elements, and find many of them confusing or hard to use. And this is after 3+ years of constant SCORM development! SCORM should be as streamlined as possible; additional functionality should be separated from the core, and usable on-demand as a plug-in module.
4. Provide more space in the database for developers to store custom data. “suspend_data” is constantly abused by developers who need some space to store their custom data; there’s no reason a new, larger space can’t be assigned for developers to use at their discretion.
What do you think?
I’m sure I left a lot of things off this list, and I’m sure many of you have ideas I’ve never thought of. Share your thoughts! There’s a good chance they’ll be read by others, and your idea may be a spark that helps revolutionize online education! Or not. 😉
If you have some free time, take a look at some of the ideas LETSI is toying with for SCORM 2.0 [link no longer available]. I think they’re on the right track, so long as they don’t let advanced functionality get in the way of the (hopefully) streamlined basics, which is probably what the vast majority of developers will use.