What do you want *your* SCORM to do?

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.

Advertisements

MooTools 1.2 & Opera 9.5 released, FF3 coming soon

Some quick development news:

  • MooTools 1.2 has finally been released. MooTools is really great, I hope more people start using it.
  • Firefox 3 should be officially released this Tuesday (June 17). Party on.
  • Oh, while I’m at it, I guess I should mention Opera 9.5 was just released, too. I’m not a big Opera fan, but v9.5 includes some important advances in CSS3 support, which hopefully will help other browser developers to make some progress with their own CSS3 implementations.

Just the Macs, ma’am

The transition is almost complete: I have ditched my Windows-based PC for a MacBook Pro.

My reasons?  Well, I could write a whole bunch of fluff about how as a developer I need to be able to test my work on multiple operating systems, and a Mac (with BootCamp and/or Parallels) allows me to do that.  

Or maybe I can tell you that when I attended the Google I/O conference a week or two ago, I felt completely un-cool because I wasn’t slinging around a MacBook Pro, unlike (at quick glance) half of the attendees at the conference.

(Side note: second most popular laptop?  IBM/Lenovo ThinkPads.  They were all over the place, too.)

Maybe I can say it’s because I finally watched An Inconvenient Truth the other day, which — unintentionally — pointed out yet another inconvenient truth: Keynote is way better than PowerPoint.  (Al Gore’s famous slide presentation was done in Keynote.)

I could say that using a Mac will make me more creative, or that a Mac’s built-in accessibility tools can help me design web sites and courseware that work for people with disabilities.

Perhaps I could tell you that I simply wanted to return to my roots: I was a die-hard Mac user for a solid decade before turning to the Dark Side.

In reality, I had no single reason to switch from Windows to a Mac, but have felt the urge bubbling for quite some time, for all of the reasons above and more.  One of the best reasons was: I wanted a lightweight but powerful laptop.  Simple enough, eh?  But the tipping point was something even simpler (and IMHO) funnier: Apple has a back-to-school sale going, which meant a free iPod Touch if I bought the MacBook Pro.  Sweet.

So now I have a MacBook Pro AND an iPod Touch.  I feel like such a hipster, only without the cool hair, cool clothes and bad attitude. I suppose a real hipster would scoff at the iPod Touch and say I should have gotten an iPhone. I’m not ready for that commitment yet… Apple needs to ditch AT&T before I get that particular toy.  😉

Anyway, now that I’ve been playing with my new Apple goodies for a few days, I’m really appreciating (rediscovering?) the excellent user interface design, where it’s apparent that a lot of thought went into every aspect of the the UI.  And, of course, the MacBook Pro “just worked” from the start.

(Side note #2: Ubuntu also runs great out-of-the-box if you ever want to give Linux a shot.)

I’m also really enjoying the software that comes with a Mac. I don’t know if it’s a fair knock against Windows, but the software that comes with OS X feels more useful, and is certainly easier to look at! Apple’s iWork suite is cool, too; I already mentioned Keynote, and “Pages” is much slicker and easier to use than Word. Too bad I can’t use iWork applications at the office since none of my coworkers have Macs.

The iPod Touch has been a lot of fun, especially using Safari with the built-in WiFi.  I’m definitely going to start paying closer attention to how my websites and courseware fare in small-screen mobile environments.

Are YOU a Mac user?

Are you a Mac user?  Have any tips or recommendations?  I’m using Parallels to run Windows XP, so I still have access to my Windows-only stuff.  However, when it comes to Mac software, I’m starting over and need to figure out what’s hot and what’s not. I have iWork 08 and Adobe CS3, but not much else.

Anything else I should be using?  🙂

Link: Opening Up the IMS

Good post from Michael Feldstein at e-Literate:

There’s something fundamentally contradictory about open standards being developed behind closed doors.

Over the past 18 months, I have had the privilege of participating in the IMS work on a regular basis. During that time, I have mostly kept my mouth shut about the openness issue. Out of respect for the staff and the board, I wanted to experience the process from the inside and see how it works today before advocating change. But at the Learning Impact conference last month, I decided to speak out.

At one point I said, “I know plenty of people in the ed tech community-good people, exactly the kind of people that we need to participate-who think that the IMS is some kind of secret society.” I got a fair few “amens” from other participants, both publicly and privately.

Amen, indeed, brother!

Read the entire post at e-Literate

Link: Web Accessibility Checklist

The talented Cameron Moll has posted a link to a Web Accessibility Checklist prepared by Aaron Cannon, a (blind) member of his web development team.

Aaron’s checklist is an easy-to-understand list of accessibility dos and don’ts. Most of these are so simple and easy to implement that there’s really no excuse to NOT use them in your work!

Kudos to Aaron and Cameron for sharing this with the community!

Link: Hardware tips for screencasting

Ran across this short but useful blog entry from Layers Magazine.

I know many people who use assorted ‘screencasting’ tools (Captivate, Camtasia, Firefly, etc.), and my guess is that very few of these people give much thought to the hardware they use for their projects. Hardware has a huge impact, and can be the difference between a successful screencast session and a computer that keeps crashing.

This author gives a nice simple overview of the topic, and also gives some practical tips about creating screencasts. Read “Screencast Success