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.
Using SCORM for sequencing and navigation is NOT the norm and never will be. Personally, when I create a course system, I begin by making it work in what I call standalone mode: no reliance on any server-side process. This allows the course to be used in non-tracking environments, such as from a CD-Rom, a USB thumb drive, or a plain vanilla website. Standalone mode usually means an HTML-based course using cookies and JavaScript, or a Flash-based course using a Shared Object. Once I get the system up and running and behaving as I planned, including navigation and determining the course’s completion status, I fork my code to include a SCORM option. This approach also provides the flexibility to add a third fork for any other tracking system I may need to support, such as AICC or (gasp!) proprietary LMS code.
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.)
- Create a standardized JavaScript wrapper. This wrapper should use a single global object to contain all variables (properties) and functions (methods). The pipwerks SCORM API wrapper was created to fill this void, but I’m sure it can be improved upon. A standardized wrapper would facilitate interoperability between SCORM-conformant content produced by off-the-shelf products and home-brewed projects.
Consider this scenario: Joe Developer has created a full HTML-based course, which is considered a single SCO. Joe wants to drop in a couple of Flash-based interactions created in Adobe Captivate or Articulate Engage; the results of these interactions need to be tracked within the framework of Joe’s course. This is currently not possible (or at least not very easy); if the Flash interactions are published with SCORM enabled, they will try and call LMS Initialize, and they will try to use custom functions contained in the wrappers provided by their respective companies. If there were a single, standardized wrapper, the Flash files output by these products would use the same syntax and functions as the home-brewed course, enabling Joe to easily integrate their code with his own. This might include a check for an active LMS API, which would eliminate the troublesome call for LMS Initialize in the Flash files.Granted, The Flash files might also use a variety of browser communication methods that could cause problems, from LocalConnection to FSCommand to ExternalInterface, but using a standardized wrapper would go a long way towards bridging the gap.
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.
Hopefully, you will take advantage of the LETSI solicitation for whitepapers and get involved. It will only be as good a spec as the support it receives. It will be a shame if people like you only participate after it’s done. At that point it’s too late to incorporate what you need it to support.
yes, yes, and yes.
for the past four years i have build all of our courses in flash and have used only a handful of cmi elements (core.lesson_status, core.lesson_status, core.score.raw, and core.student_name if i’m feeling fancy).
i so despise packaging courses for the lms that in the past three years i have built four tools to package courses for us – first in php, then in rails, then as a script ‘wizard’ with a minimal gui, and finally as a full-fledged cocoa app. and with each of those tools, i have done my best to make the imsmanifest as *minimal* as possible.
i’ve been following your blog and your work for some time now, and i sincerely appreciate both your opinions and code. thanks and keep it up.
I`m using scorm to provide my educational content but I`m not familiar with scorm mechanism .I think now SCORM really help me to categorize my courses in short time but there is some little problem for me like below description:
folder created via scorm will rename without any specific rule and make tracking ability difficult to me ,
I like my scorms would have a mechanism to add a security capability to my flash movies . for example if user try to view flash movie (swf file) directly (without using scorm structured mechanism) then related movie stop automatically ,
Of course I`m not advanced with scorm structure but I just told my desire 😉
AMEN! We have a full actionscript dot syntax in our runtime-makes it as easy as instantiating a new object like new Array(). Even with that I never use all of it. Our course authoring tool also builds manifests and i find myself always trying to thin the file out-most of our customers don’t want sequencing, they hate LMS provided TOC’s, i keep metadata to almost nothing, my clients never do any kind of sco reuse via the manifest, most want one sco for the whole course and build an internal navigation. It doesn’t help that every LMS seems to deal with sequencing rules differently.
I’d also like to have altenative api’s rather than just javascript, i’d rather use a direct web service call from flash rather than going via external interface.
Interactions/objectives must be simplified maybe have a new test object which would allow for multiple test scores in one sco.
Suspend data needs to be bigger or other spaces made for custom stuff.
Rewrite sequencing and navigation to make it simple-and get a better certification process so all lms’s can interpret the same.
Also their needs to be some kind of api that allows the course to define the look and feel of how the lms displays. My clients hate how it’s very jarring to go from sco-to-TOC-to-sco. They want visual cohesiveness. So maybe a way were the sco can consume other info from the lms like the activity tree(and it’s status) etc and be able to display it.
And they want the content to be intelligent on what it is playing on-ie phones.
The sharable thing honestly needs to be re-thought as in the industries i’ve worked in for the past 10 years it’s not being used-that says something and makes me wonder about the use of an imsmanifest. Private industry has not embraced this idea the way academia has.
Another thing that needs to be looked at is a way to update/add to certification courses that then allow formally completed users to come back and complete the new parts(including guidelines for how LMS’s will deal with it when the course is updated). They hate having 15 update courses every year and. Maybe SCORM needs to define a curriculum standard as well.
I’m bias as a content developer but I see a lot of issues with LMS’s doing just enough to get by with SCORM or advertising incompatibilities as”Mis-Features”, like it’s a benefit. That rub has a lot to do with the LMS’s proprietary courseware and runtime vs the scorm support they tacked on. I’m not sure that LETSI can fix that-but it does affect the reputation of SCORM.
Well said! As a newcomer to SCORM, I’ve been somewhat dismayed to discover just some of the needless complexity you discuss (and very pleased to see some to the great code on your site). Seems to me that SCORM has a classic case of the gallopin’ feature bloats.
Separating things out into modules would, I think, be the perfect way to handle this.