Is SCORM Dead?

About a week ago I tweeted:

from what i’m reading between the lines, #SCORM is dead to the ADL. they’re moving on. interesting timing considering #TAACCCT

I had no idea how much hand-wringing and consternation my off-handed comment would cause. It apparently caused (directly or indirectly) some heated discussions about SCORM being dead.

The problem is, I never said “SCORM is dead.” I said “SCORM is dead to the ADL.” Big difference.

Let me elucidate here.*

I posted my tweet after noticing several things:

1. It’s well-documented that the ADL has tried to hand SCORM off to other organizations without success for at least a couple of years — remember the LETSI SCORM 2.0 initiative? Unfortunately, lawyers got in the way.

2. I had recently heard that the ADL has decided to put a lid on SCORM and cease further development, with the lone exception being the possible addition of new data elements from the CMI-5 initiative. No refinements to sequencing and navigation, no web services.

3. In case you haven’t noticed, the ADL is working very hard to promote the Future Learning Experience Project and Project Tin Can. Their marketing materials repeatedly use the phrase “beyond SCORM.”

For example, a recent ADL newsletter contained this:

ADL launches Future Learning Experience Project
SCORM was built to support web-based delivery of learning content, based on initial design dating back to the late 1990s. While ADL continues to support SCORM and commits to supporting SCORM compatibility in new efforts, we have also begun new work to meet distributed learning needs beyond SCORM: the Future Learning Experience Project.

“New work” that goes “beyond SCORM” while “continu[ing] to support SCORM.”

Add it all up and you can make a pretty solid case that the ADL wants to move on to the next thing, and the next thing will be defined by the outcome of the Tin Can research coupled with the Future Learning Experience Project.

And your point is?

I could write a book trying to explain the troubled life of SCORM, and how it has been seen as a savior, an outcast, an anchor, and a noose. But I don’t want to do that. I just want to let everyone know that my tweet was simply an off-hand remark that it appears the ADL wants to move on to something else. The ADL wants to have “life after SCORM.”

In a private email thread, I told some of those concerned:

My point with my tweet was that I have a gut feeling that SCORM, as we know it, is being left behind. This isn’t a negative statement, though it could be construed that way. In my mind, it’s quite the opposite: the ADL (and others) appear to be very active and engaged with the learning technology community. I’ve never seen this level of activity. It’s just that what’s being worked on (in super-simple terms) is a modern tracking mechanism that really only has a cursory relationship to SCORM as we use it today.

Perhaps ADL’s work on SCORM is complete […], but SCORM still needs improvements, and from my admittedly limited observations, the ADL shows no intention of doing that work, choosing to focus on a successor to SCORM instead. Hence my comment that SCORM is dead to the ADL. Brad Pitt is dead to Jennifer Aniston, but he’s not really dead, y’know?

So please put away the pitchforks. SCORM is alive and kicking, though it probably won’t get that reconstructive knee surgery it’s been needing for the last 5 years.

Frankly, I think SCORM’s run-time model is flexible enough that it will remain relevant for years, and that makes me happy. I’m one of the few people who thinks SCORM can be very useful today even when using social media. Just because no one has done it yet doesn’t mean it can’t be done.

Lessons learned

My lessons learned:

  1. Some things are better left unsaid (untweeted), especially if they have the potential to be taken out of context.
    • that’s what she said!
  2. The power of social media means even little pipsqueaks like me can cause a ruckus, intentionally or not.

Lessons learned for others:

  1. Don’t take things out of context.
  2. The ADL needs to work on its marketing/messaging.
  3. SCORM is still cool.

* One of my favorite Disney songs ever.

SOAP for SCORM

At DevLearn 2010, Ben Clark and I presented a session named SOAP for SCORM on behalf of LETSI. The topic was the LETSI Run-Time Web Service (RTWS), a proposed modification of SCORM to use SOAP for communication rather than the current JavaScript model. I presented the first half of the session, covering the basic “what” and “why” ideas while Ben covered the technical “how” details in the second half.

This blog post is my attempt at documenting my portion of the session. Bear in mind that there was a lot of Q&A from the audience, and much of the session was ad-libbed. The descriptive text presented below may not exactly match was what in the session, but the gist is there.

If you’re interested in the nitty-gritty technical details, check out the Developer’s Guide on the LETSI website.

The Presentation

SOAP for SCORM: Linking Training Apps to Your LMS with LETSI's Run-time Web Service (RTWS)

 

Learning Education Training Systems Interoperability

Some quick background information on the LETSI organization.

LETSI stands for “Learning Education Training Systems Interoperability”.

LETSI believes in pushing training systems forward through agile, iterative software development. Make things quickly, get feedback, and make changes. In our current Internet age, we don’t have the time to take years developing a spec. Make something that works, then turn it into a spec.

LETSI believes in engagement with standards bodies and vendors throughout the process. If a new technology is to become mainstream, it’s vital to get vendors in on the action. Make them stakeholders and get them involved in the project at an early stage.

Unlike some standards bodies, LETSI is transparent and open — there are no strings attached. Membership is not limited to corporations or agencies. Want to have a say in the future of training technology? Join LETSI and you could be on the conference call next week.

 

What is the RTWS? An alternative to JavaScript

Simply stated, LETSI’s Run-time Web Service (RTWS) is a replacement for the SCORM JavaScript API. There are some other features that go beyond SCORM 2004, but the bulk of the RTWS is focused on replacing the JavaScript communication system with a SOAP system.

 

SCORM API: A JavaScript object in a web browser window

The current SCORM architecture requires that courses be launched in a frameset or pop-up window.

 

Course pop-up window communicates with LMS browser window via JavaScript

The course frameset/window contains a JavaScript-based API that communicates with the parent frame/window (the LMS website).

 

LMS browser window communicates with LMS server/database via JavaScript and server-side scripting

The LMS website typically performs data gets/sets on a database using a combination of ajax (xmlhttprequest) and server-side scripting (PHP, ASP, Java, etc.).

 

LETSI Run-time Web Service: A direct connection between the course and the LMS via SOAP (XML)

The LETSI RTWS changes the architecture to eliminate the middleman (the LMS website), allowing the course to directly communicate with the LMS backend using SOAP. (SOAP can be loosely described as XML sent via HTTP requests.)

 

What does this mean? (and why should I care?)

 

No more dependence on Web browsers

Replacing the JavaScript API with a SOAP system means the course no longer needs to be launched from the LMS. If the course is no longer required to be launched from an LMS, the web browser itself becomes optional, enabling the course to be launched from a variety of environments, including mobile apps, desktop apps, hybrid Web/desktop apps such as Fluid, Prism and Adobe Air, and other software solutions such as virtual worlds and serious games. This effectively makes SCORM’s CMI data model available to almost every software/web-based training solution.

No dependence on the web browser also means the course content can be hosted anywhere, and is no longer required to be stored in the LMS system.

Note: In some prototypes, the course must be launched from the LMS for the first attempt. This is due to registration requirements that are still being ironed out.

 

Better security

The JavaScript API has long been the weakest link in terms of security; it’s easy to hack and can’t be encrypted. Replacing the JavaScript API with SOAP (XML served via HTTP/HTTPS) enables courses to use discreet, secure communication via HTTP POSTs, similar to banks and other sensitive systems. RTWS courses will be protected via a combination of a shared key (a hash stored in both the LMS and the course’s code), user name, user ID, and a secure password incorporating SHA-1 encryption.

IMPORTANT: Since the shared key and the password are contained in the course’s code, the course will only be secure if the developer keeps it secure. For example, using JavaScript to handle your SOAP calls will make your data viewable to the client. If you keep all of the SOAP work behind the scenes using server-side code, your course will be much more secure.

 

Better accessibility

The accessibility benefits of the LETSI RTWS are debatable, but here are some of my personal beliefs about how the RTWS can make a course more accessible:

1. Since the RTWS discards the SCORM JavaScript API, a web-based course can be built to run without without a single line of JavaScript (traditional form POSTS and server-side code can process the SOAP requests). I’m not saying JavaScript is bad, but it’s a fair assumption that in most cases pages that don’t require JavaScript are more compatible with alternative browsing devices.

Also, as a developer, I know first-hand that when JavaScript is *required* for a course, many developers feel they’ve been given carte blanche to go hog-wild with JavaScript; for example, they might use it for interactive widgets that require a mouse (not keyboard accessible) and dynamically update/generate page content using ajax (difficult for screen readers and braille displays). These situations are problematic for people who use assistive technology; by eliminating SCORM’s JavaScript requirement, we can force developers to take a closer look at why and how they’re using JavaScript, hopefully leading to a more accessible course.

2. No reliance on web browsers means a course can be built in a desktop app or other environment that may (or may not) be more accessible than a web site or Flash movie. Of course, this is completely up to the developer, but the possibilities are there if the developer chooses to go down that path.

 

Less restrictive development environment

Under the LETSI RTWS, courses no longer need to be uploaded to the LMS and can be stored on ANY web server. There are several useful byproducts of this:

1. Course manifests no longer need to list every course asset. (Manifests are still required because they contain core data about the course, including the shared secret.)

2. If you’re a course vendor, you can maintain control of all of your course materials and simply provide a link and manifest to clients. No more ZIPs!

3. Since the course materials remain on your server and are not required to run on the LMS server, you’re free to use server-side code (previously a taboo in SCORM).

 

What’s the catch?

 

Requires more work

Despite their often negative reputations, LMSs provide a key service for your SCORM course: a SCORM API with error-checking (including error/debug messages) and behind-the-scenes handling of the CMI data model for you. The RTWS is not currently equipped to provide detailed error messages regarding the use of the CMI data model; if you choose to use the LETSI RTWS in place of the SCORM API, you will no longer have the benefit of the SCORM API’s error messages.

In the RTWS each ‘set’ request is an XML document created by your course and submitted to the server via HTTP. Since your course is creating and submitting the XML, it must use its own logic to determine if there are any errors, such as malformed XML or misuses of the CMI data model. For example, if your course accidentally tries to set a read-only field such as learner_name, you will not receive any error messages. It is up to your course to ensure the specifications of the CMI data model are being followed.

(Hopefully in the near future there will be 3rd-party libraries or frameworks that will provide this logic for you so you won’t have to write your own.)

Also, your course must be using a technology that supports SOAP.

 

Only supports single-SCO courses

The RTWS currently only supports single-SCO courses, and does not support SCORM 2004’s Sequencing and Navigation rules.

On a related note, since the content is being abstracted from the LMS, the LMS’s SCORM “player” will not be available to the RTWS course.

 

http://letsi.org/rtws

You can read more about the RTWS at http://letsi.org/rtws

Reminder: LETSI membership is open to the public. If you’d like help shape the RTWS (or other LETSI projects), join us!

Additional notes and tidbits not covered in my portion of the presentation

  • I briefly demonstrated a prototype I created for Flash-based courses. My prototype uses a modified version of my pipwerks SCORM ActionScript wrapper, allowing developers to simply swap out the pipwerks SCORM class file with a new pipwerks LETSI RTWS class file and still have their course behave as it did with SCORM 2004. This prototype is not available to the public yet, but when I’ve worked out the bugs I will be sure to post a blog entry about it. Stay tuned!
  • The LETSI RTWS is based on the SCORM 2004 (4th Edition) spec and uses the same CMI data model.
  • Because the RTWS uses a new launch approach, support for querying the course’s attempt history has been added to the data model (see GetAttempt and GetAttemptList in the RTWS documentation).
  • Unlike SCORM, a Get request in the RTWS returns the entire data set in an XML file. It’s up to the course to parse the XML and extract the value for a particular CMI element. I’ve whipped up a document mapping the CMI elements to their XML equivalents.
  • A Set request can be partial (set a single or small group of elements) or complete (set the entire data model).
  • SCORM’s Initialize() and Terminate() methods are not currently used in the RTWS.
  • Rustici Software (scorm.com), Booz Allen Hamilton, and Meridian are all creating LMS prototypes that support the RTWS.
  • Rustici Software hopes to fold support for the RTWS into its SCORM Cloud service once the RTWS is ready for prime-time.
  • The ADL (owners of SCORM) are not involved with the RTWS, but they are aware of its existence and are monitoring the situation. In a separate action, the ADL is requesting input on the future of SCORM via Project Tin Can. It is LETSI’s hope that the RTWS, when ready, will be folded into the ADL’s plans for SCORM and that the two will co-exist peacefully.

DevLearn 2010 Recap

And so ends another whirlwind of a week known as DevLearn.

Could the timing have been any better? My San Francisco Giants (yes, my Giants!) won the World Series and decided to have the largest parade in San Francisco history on the first day of DevLearn. It just happened to be a block from the conference site, which was A-OK with me! In their honor, I wore my Giants jersey the entire day.

In a quirky turn of events, I also wound up being a speaker at DevLearn this year, alongside Ben Clark of Rustici Software. We co-presented “SOAP for SCORM“, an introduction to the LETSI Run-Time Web Service. Aside from the requisite technical glitch, our session went well, and we had a great group of attendees.

Update: Here’s a separate blog entry covering our SOAP for SCORM presentation. Major thanks to Avron Barr, LETSI, Ben, and the E-Learning Guild for the opportunity.

As with any conference, each year there are always some outstanding sessions, and always a few duds. Being a tech guy who happens to have an MA in instructional design (as opposed to an instructional designer who happens to do some tech) I’m usually disappointed by the lack of in-depth technical sessions. This year was par for the course. There were some very good high-level sessions on technical topics, such as the introduction to DITA, but nothing particularly deep. Again, I’m a tech guy and perhaps not the main target of the conference; most attendees appear to be subject-matter experts, trainers, or instructional designers who happen to do their own technical work. DevLearn is a very good fit for this demographic.

I particularly found Ginny Heenan’s session about quantifying billing rates and handling the business side of e-learning very useful, and thought Koreen Olbrish’s session was a great primer on some of the latest and greatest technologies.

My favorite moment? Probably Richard Culatta‘s ‘six-minute perspective‘. Funny, very well-written, excellent slides, and most of all, great points. Inspiring in a very TED-esque way. Nancy Duarte would have been proud.

My least-favorite moment? Probably Allen Interactions’ Zebra after-party/demo. DevLearn was heavily branded with the Zebra theme, and it looks like Allen Interactions paid some big big marketing bucks this year. They were trying very hard to make it feel like an industry-changing event. I don’t begrudge them of their marketing efforts. However, it ruffles my feathers that Allen Interactions required everyone to sign a non-disclosure agreement before they could attend the main demonstration — they had already demoed much of the same material in the Expo hall without requiring the NDA! Makes. No. Sense. Then the demo itself failed to live up to the immense hype. I’m not sure what I’m allowed to say because of that silly NDA, but let me leave it at this: Zebra looks perfectly useful, but the demo was hokey and the entire dog-and-pony show was very tiring. (Sorry, guys, just calling it like I saw it. But thanks for the cupcakes, and my daughter loves her new toy zebra!)

Update 11/10/2010: Allen Interactions has sent an email to attendees providing more information about the NDA:

We have been asked what can and cannot be said about Zebra with respect to the Nondisclosure Agreement (NDA). Several product features we demonstrated and discussed at the event were still in the process of patent application. As these applications have now been filed, you are free to share any information about Zebra you heard or saw.

Doesn’t really change my opinion, but now I can tell you: the very first live demo they performed was creating a page-turner. Literally! It was a photo album with next and back buttons. Zebra may very well revolutionize the industry, but it won’t be because of the hokey DevLearn demos.

Speaking of vendors, Open Sesame probably had the greatest marketing ploy of the entire conference: they gave away free black hoodies with their logo on the back. They also gave you a key. If they spotted you wearing the hoodie at the conference, they’d give you a chance to see if your key unlocked their box. What was in the box? A free iPad, of course! There were tons of folks wearing Open Sesame hoodies and talking about their company. Very clever!

Sessions and vendors aside, in my mind, the true value of DevLearn is the informal learning and networking that occurs in hallway conversations. Putting faces to the people you know on Twitter. Meeting people who do what you do but in a different part of the world. People who share your excitement about a topic that your mom doesn’t understand.

One unexpected treat was meeting some of the folks who use my pipwerks SCORM wrappers. Since the wrappers are free and don’t require any kind of registration, I usually have no idea who’s using them. It’s very gratifying to meet developers who have successfully used the wrappers in their projects… it feels great to know that the wrappers have been useful. Thanks for coming to talk to me!

Of course, I can’t list every person I ran into this year, but suffice to say I had some great conversations with old acquaintances and people I had just met, including Brian Dusablon, Ben Clark, BJ Schone, Gary Hegenbart, Aaron Silvers, and many, many more. Being an introvert, I’m usually uncomfortable in social settings, but this year was quite fun. Guess I’ll have to do it again next year.

Speaking of next year, DevLearn 2011 is scheduled to take place in Las Vegas at the City Center. Maybe I’ll get to check out the death ray in person!

SCORM security (two kinds of SCORM people)

I’ve had a flurry of emails and messages regarding my SCORM cheat the past few days, and have received feedback from a number of well-regarded SCORM aficionados, some of whom contributed to the standard and helped make SCORM what it is today. This is wonderful, I’m very happy to hear from everyone, especially regarding such an engaging topic.

But as I hear more from these seasoned SCORM pros, I’ve made (what I believe to be) an interesting observation: there is a sharp division between die-hard SCORM developers and casual users. I suppose I’ve felt this way for a long time, but it’s really coming into focus this week. Let me try to define the camps.

  • Die-hard SCORM developers (aka scormmies). The scormmie is a person who understands what SCO roll-up means, and can hand-code an entire manifest. A scormmie thinks the word metadata is sexy. This person believes a course should be designed to use SCORM from the start, complete with sequencing and interaction tracking; if the course isn’t running in an LMS, it won’t function without being loaded into some kind of SCORM player or test suite. Scormmies get angry if their LMS hasn’t implemented the entire SCORM spec.
  • Casual users (aka shruggies). The shruggie is a person who doesn’t care about multi-SCO courses. Shruggies don’t want to be bothered by the technical details, and use rapid e-learning development tools to build courses, freeing them from needing to know any of the technical mumbo-jumbo. Metawhat? “SCORM… yeah, that’s one of the publishing options in [insert product name here], right? So it will work with my LMS?”

The e-learning market has changed significantly

Over the last week I’ve mostly heard from scormmies who make comments such as ‘well, if a developer knows what they’re doing, they’d never make their course that vulnerable to begin with!‘ and ‘a developer should never design a course to only require a completion and score… that’s asking for trouble.

The problem with this line of reasoning is that the e-learning landscape has changed dramatically since SCORM was first conceived; the scormmie used to be the majority. Now, with the proliferation of e-learning development tools and LMSs, the scormmie is a minority. Most “e-learning developers” are not programmers by trade, and are not familiar with the very complicated and intimidating SCORM spec. They use tools that do the heavy lifting for them.

If you survey most e-learning development tools (which is a booming market), the courses they publish are almost exclusively single-SCO courses that only use the simplest core SCORM functionality: completion status, lesson location (bookmarking), score, and suspend_data. These products are designed to create courses that work without SCORM, which means they only add the minimal SCORM code needed to get the course running on an LMS; all other logic is generally handled internally. They certainly don’t use sequencing and navigation or cmi.interactions.

LMS vendors generally advise customers to buy these off-the-shelf tools to build their courses. E-learning conferences are packed with tool vendors and advertisements selling the virtues of a ‘no technical expertise required’ tool. At work I sometimes get calls from vendors trying to sell me the latest and greatest tool.

The majority of courses are no longer developed by scormmies

All of this leads to one point: I think some of the SCORM guys have lost touch with the current market and don’t realize just how much of a problem a simple SCORM cheat like mine could be. Sure, it probably wouldn’t work on courses developed by seasoned scormmies because multi-SCO courses that utilize interactions are much too complicated for my itty-bitty script to tackle… but courses developed by mainstream development tools are easy targets. Ducks in a barrel. So long as the API is JavaScript and unprotected, a script like mine can bypass the SCO completely and set the course to complete before the learner even gets past the table of contents. The only way to figure out if someone cheated is to run a completion report and look for unusual patterns, which is highly unlikely in most corporate environments. As a friend noted the other day, there are many more script kiddies who can write cheats like mine now than there were when SCORM was first proposed.

Who gets the blame for the vulnerability?

Can the tool makers be blamed? Maybe, but hey, their #1 priority is satisfying the needs of the community, and the community wants quick, easy, and ‘can run on a CD-Rom’. Could the vendors have implemented more sophisticated SCORM mechanisms? Yes. However, everyone chooses the path of least resistance (and least development dollars), and we all know SCORM development is not a walk in the park. I’ve been using SCORM for five years and still avoid most of the complicated stuff because it’s … well … complicated.

The community at large (aka the shruggies) has bought into the notion that SCORM is the standard for e-learning. This is what the scormmies wanted, and it made the most sense for everyone involved, even the tool vendors. But how many people knew about the security vulnerabilities in the JavaScript-based API? A lot: the SCORM authors, the ADL, LMS vendors, tool vendors, and a number of prominent SCORM developers. Did any of these people warn the end clients of the risks? Maybe, but I personally have never been warned of any SCORM security issues in my five odd years of SCORM work. I’ve never been told “don’t use SCORM for that because it isn’t secure.”

Why didn’t anyone act?

I wasn’t privy to the early conversations, but I’ve been told that SCORM developers have said “don’t use SCORM for high-stakes assessments” from the very beginning, circa 2000. If this is the case, why has nothing been done to improve SCORM’s security? It’s only been about nine years. Did convenience beat out security in the race to implement the standard?

I get the impression that the scormmies (and remember, my term scormmie just means a person that works with SCORM, not necessarily an official representative) felt no one would bother trying to hack the system, and that a well-built course would be so difficult to cheat that it would be easier to simply take the course. With today’s simplistic single-SCO courseware tools, I don’t think this is a valid argument anymore.

I’ve also heard from scormmies that we’re still fine, because everyone knows SCORM shouldn’t be used for high-stakes training. I think a significant number of corporate, military and government trainers would disagree with that assessment, because the LMS salesperson never mentioned it. Neither did the e-learning development tool vendor. Oh, and that instructional designer we hired out of college? She’s heard of SCORM but has no clue how it works. Isn’t it safe since you have to log into the LMS with a password? There’s a padlock icon and an https protocol… that means it’s secure, right?

Nope.

Simple-SCO courses are used for all kinds of sensitive training nowadays. Compliance training alone is huge these days and can be found in examples from almost every simple-SCO tool vendor. As a colleague recently remarked, “it’s all low stakes until someone’s attorney gets involved”.

No hard feelings!

I would like to point out that I am not targeting anyone in particular, have no animosity towards anyone, and have the utmost respect for the scormmies and what they do (I’m half-scormmie myself). I’m an optimist with a very critical eye, and this post is intended as constructive criticism… criticism intended to cause positive change.

It simply became apparent to me that at some point the scormmie community dropped the ball and got complacent; it seems as though the whole community assumed no one would bother to hack a course. Well, I did. And I used public documentation to do it. It took two hours while I was flying on an airplane, and I’m not the sharpest tack in the box. I’m sorry if my cheat script caused a stir (and if this blog post makes some people uncomfortable) but we need to talk about this issue. Now.

What’s the solution?

OK, we’ve covered enough of the criticisms and the importance of working towards a solution… I’m ready to let it rest. Let’s finish on a positive note: SCORM uses existing technology and standards, and if multinational banks can protect billions of dollars from cyber-criminals using standard web technology, we should be able to secure our courseware, too. I personally think we should be able to figure something out in the next couple of months and that it ideally shouldn’t require much work to implement — no need to wait until SCORM 2.0 comes out!

Here are some suggestions I’ve heard:

  • using a secure web service to handle important duties such as processing completions and scores
  • rolling up SCOs in a way that forces the LMS to analyze multiple SCOs before setting pass/fail (a second ‘dummy’ SCO could be used if the course is a single-SCO course)
  • using form posts to submit the completions (the form post would contain a unique encrypted key that must match a key on the LMS)

Personally, I’m especially interested in ideas that don’t require modifications to LMS implementations and might only involve a strategic re-organizing of a SCO’s manifest or SCORM code. Perhaps using a SCO roll-up can become a security best practice, even if the course only uses one SCO? That type of simple solution would be ideal since it wouldn’t require modifications to an LMS or SCORM spec — it would only require a broad marketing effort to get the word out to all SCORM developers and toolmakers.

I would love to hear other ideas, as I feel we can probably come up with any number of workable solutions.   Please add to the discussion! Remember, these need to be solutions that can be implemented easily and by the single-SCO type of courseware tools flooding the e-learning market.

By the way, while we’re at it, can we improve accessibility in our e-learning, too? 😉

SCORM resources

I recently emailed a shortlist of good SCORM development resources to a colleague, and figured I should probably post a list here, too. This is a quickie list, and I’m sure I’m leaving someone out. If you know of any resources I’ve missed, please add a link in the comments. This list is presented in no particular order.

  • Claude Ostyn’s site. He passed away in 2007, so there haven’t been any updates since then. His materials present a nice overview including lots of examples.
  • The ADL website. Their SCORM Documentation Suite is the official documentation. Must-have for any SCORM developer.
  • Redbird DevNet [link no longer available]. They have a nice tutorial/walk-through of SCORM 2004 architecture.
  • Rustici Software. A for-profit business that works almost exclusively with SCORM. They’ve posted some helpful resources on their site.
  • Aaron Silvers has been writing about SCORM (especially with regards to Flash) for a long time.
  • adlCommunity. A site dedicated to advancing ADL’s technologies. There are some good resources for SCORM developers, including an overview of SCORM written by the late Philip Dodds, one of the chief architects of SCORM.
  • Academic ADL Co-Lab. An offshoot of the ADL that offers SCORM resources and training for would-be SCORM developers. Also hosts Joe Nelson’s custom SCORM JavaScript framework LibSCORM (“a boilerplate template that implements common SCO Tracking and Communication functionality”), which some may find useful.

Of course, I also have a few SCORM odds and ends on my site you may find useful:

For those of you who don’t know, SCORM 2.0 is in the works, and is being handled by Learning Education Training Systems Interoperability (LETSI). SCORM 2.0 is still in the formative stages and won’t be ready for a few years (minimum), but you can certainly join the conversation and help mold SCORM 2.0 by visiting the LETSI site.

Update: LETSI is no longer tasked with SCORM 2.0, which will remain with the ADL. LETSI will continue to work on e-learning technology standards, including a potential replacement for SCORM.

SCORM 2.0: high-level solutions or low-level tools?

Matt Wilcox posted an interesting argument about the development of the CSS3 standard; I think the central points of the argument can be applied to SCORM and where we’re potentially headed with SCORM 2.0.

After explaining some of the shortcomings of the current approach taken by the CSS3 Working Group, Matt writes:

What does CSS need to overcome these problems? First let me say what I think it really does not need. It does not need more ill thought out modules that provide half-baked solutions to explicitly defined problems and take a full decade to mature. We do not need the Working Group to study individual problem cases and propose a pre-packaged "solution" that either misses the point, is fundamentally wrong, or is inflexible. […]

The crux of the issue is that W3C seem to try providing high-level "solutions" instead of low-level tools. It’s a limiting ideology. With the CSS3 WG strategy as it’s been over the last decade, they would have to look at all of the problem points I proposed above, and come up with a module to provide a solution to each. But by giving [designers low-level tool functionality], we designers can build our own solutions to all of them, and innumerable other issues we have right now, and in the future.

As with the discussion regarding ECMAScript “Harmony”, I think LETSI should take a look at the meat of this argument and apply it to SCORM 2.0. Test cases are important for SCORM moving forward, but we can’t try to predict every issue a course developer might encounter — the possibilities are too numerous, and as we learned with Web 2.0, we can’t predict what technology (esp. browser capabilities) will be dominant in 5 years. What we can do is provide a loose framework or toolset that gives developers the flexibility to build their courses the way they want. This system would ensure interoperability by standardizing the tools and data management across LMSs.

You can read Matt’s post here: The Fundamental Problems of CSS3 by Matt Wilcox (via Dion @ Ajaxian)

Does SCORM need a little brother?

For many involved in the SCORM 2.0 project, the hope is that we can transform the SCORM 1.x caterpillar into a SCORM 2.x butterfly; that the gestation period of SCORM 1.x has ended, and soon SCORM 2.0 will emerge from its cocoon and dazzle the world with its beauty and agility.

What’s worrisome is that there appears to be a divide in the SCORM 2.0 community between the pro-aggregators and the non-aggregators, and from the looks of it, this divide will ultimately leave one side of the aisle unhappy.

Pro-aggregators

If there’s one thing I’m learning by reviewing the SCORM 2.0 white papers submitted to LETSI, it’s that the SCORM community is full of hope and ambition when it comes to truly reusable course objects. There are some really interesting ideas being proposed for SCORM 2.0 — especially as relates to social networking and Web 2.0 technology — and some folks are swinging for the fences. The biggest fear I sense from this group is that SCORM 2.0 won’t be aggressive enough when it comes incorporating new ideas or fixing the aggregation issues in SCORM 1.x, most notably sequencing and navigation.

Non-aggregators

The SCORM community is also full of e-learning developers who do not use aggregation, and are really in no hurry to try it. Yes, I’m one of them.

Hi, my name is Philip, and I don’t use content aggregation for my e-learning courses.

My SCORM 2.0 white paper [link no longer available] focused on the notion of keeping things simple, easy to use, and accessible. Content aggregation and the related issues of sequencing and navigation are by nature complicated and difficult to manage.

From my vantage point, it appears the vast majority of e-learning developers producing SCORM-enabled courses do not use aggregation, and choose to package their courses as all-in-one SCOs. I believe this is largely for two reasons:

1. Most commercial e-learning development software (Adobe Captivate, Articulate Presenter, Rapid Intake ProForm, Trivantis Lectora, etc.) do not natively support multi-SCO courses; they publish courses as self-contained non-shareable packages.

2. Most e-learning developers do not have the infrastructure, time, funding, management support, etc. to develop courses that use/reuse shareable content objects. This has no bearing on whether they think SCOs are a good idea — almost everyone sees the value in a true SCO world — it just means it isn’t practical for them at this point in time.

SCO what?

So if non-aggregators don’t use SCOs, what’s the point in using SCORM in their courseware? Simple: it’s the easiest way to guarantee basic course functionality and interoperability. They want to know their course will work in any LMS and has a standardized data repository for course data, including quiz results and bookmarking.

He’s not heavy, he’s my brother

Judging by the topics in the SCORM 2.0 white paper submissions, the pro-aggregators are currently the most vocal members of the fledgling SCORM 2.0 community. Non-aggregators are the (somewhat) silent majority. This is bound to cause some angst. I think there’s a way to keep both sides happy: spin off the communication element of SCORM (the SCORM RTE API) as a standalone standard.

Again, we must remember that SCO stands for shareable content object. If a course is not built to be shareable, it isn’t really a SCO, even if it uses SCORM for packaging. Spinning the communication element off into its own standard — without the name SCORM — would free SCORM to truly be a Shareable Content Object Reference Model, and would free non-aggregators from having to deal with the complexities of SCORM.

This would also allow the group responsible for the new communication standard to really dig in to the communication methodologies (ECMAScript API versus web service, etc.) without having to spend resources on other topics, such as content sequencing.

The biggest question would be: What should we call the new communication standard? I think we should use the name Course Content Communication Protocol (CCCP). That way the original sponsors of SCORM — the American government and military-industrial complex — would have to officially endorse the CCCP!

[Link for those who don’t get the joke.]

All kidding aside, I do believe we should consider removing the burden of the communication protocols from the SCORM 2.0 workgroup and let the discussions about SCORM 2.0 focus on aggregation. I’m sure I’m not the only one who feels this is a viable option; if anything, I imagine the companies that produce rapid e-learning development tools would be very interested in freeing themselves from SCORM while maintaining a high level of course interoperability.

Standards don’t foster innovation, they codify it

After all my ruminating on SCORM 2.0 the last couple of weeks, it was interesting to read about the latest news regarding the ECMAScript standard.

It was even more interesting to read some of the reactions, including those from Adobe’s Dave McAllister [link no longer available] and Yahoo’s Douglas Crockford. I swear this passage from Crockford could have come directly from one of the SCORM 2.0 discussions:

The success of this project will depend on the ability of TC39 to do a better job of managing the tradeoffs between innovation and stability, and adopting a discipline for managing complexity. Simplicity should be highly valued in a standard. Simplicity cannot be added. Instead, complexity must be removed.

It turns out that standard bodies are not good places to innovate. That’s what laboratories and startups are for. Standards must be drafted by consensus. Standards must be free of controversy. If a feature is too murky to produce a consensus, then it should not be a candidate for standardization. It is for a good reason that “design by committee” is a pejorative. Standards bodies should not be in the business of design. They should stick to careful specification, which is important and difficult work.

Just substitute LETSI for “TC39” and you have a very relevant, poignant piece of advice for the SCORM 2.0 workgroup as it moves forward.

A common thread in many of the posts I’ve been reading is that standards do not lead to innovation, but rather that innovation leads to standardization. Adobe’s Mike Chambers has a great compilation of comments on this topic. I especially found this quote on standards from Dojo’s Alex Russell to be very insightful:

we need to applaud and use the hell out of “non-standard” features until such time as there’s a standard to cover equivalent functionality.

LETSI has promised to foster innovation. Will LETSI attempt to codify innovative and non-standardized technology or practices into a standard? Will it only accept existing standards (royalty-free standards, at that)?

The Raising of SCORM 2.0 will be interesting to watch as it plays out.

SCORM 2.0 white paper submission

I submitted my white paper for SCORM 2.0 today. I don’t see it listed on the LETSI site yet, but I’m hoping they received it and that it will be added soon. 🙂

I wanted to share a few things about my experience writing that paper. First of all, it wound up being a very informal paper, and doesn’t really follow the structure the LETSI folks had requested (sorry, guys). I went through a number of false starts (about seven, I think) trying to nail down what I wanted to say; even now that I’m finished, I still feel like I didn’t quite express everything I wanted to say. SCORM is just so… nebulous, and the potential for scope creep with SCORM 2.0 is so strong that I had a hard time keeping my comments focused and concise.

In the end, I wound up writing something of a ‘stream of consciousness’ paper that mostly served to get some of my concerns and notions on the official record. When I see the scholarly work some of the other participants submitted, I feel rather embarrassed, but hey, such is life!

Speaking of other papers, I took the liberty of reviewing many of the submitted documents, and I must say, I’m impressed! There’s quite a range of material and opinions, and it looks like there’s some very interesting ideas in there. From what I can see, SCORM 2.0 might wind up being a simplified and cleaned up version of SCORM 2004, or it may be a completely different animal consisting of all kinds of new features supporting the latest trends in e-learning and web technology.

I especially agreed with one of Mike Rustici‘s points:

The ‘burden of complexity’ [should be] on the LMS developers. […] It only makes sense that the LMSs should have to do the hard work and that SCORM should be nearly transparent to content developers.

This goes along with my primary motivation: make SCORM easier for content developers! Otherwise no one will want to use it and it will become useless and will be replaced by proprietary workarounds. As Rustici says, “Sequencing needs to be simplified so that it is easier than creating your own alternative.” I say this is true for all of SCORM, not just sequencing.

White Paper Addendum

Here are a few odds and ends I left out of the paper that I think are worth putting on record. These are in addition to my previous suggestions for SCORM 2.0.

A lite API. If content aggregation remains part of the core spec, can we implement a ‘lite’ API that simplifies SCORM use for single SCO courses? (The reasoning being that single SCO courses shouldn’t be forced to use full manifests and other heavy configuration items that aggregated courses will require)

SCORM security via a Web service. One potential benefit for using a web service for SCORM in lieu of a ECMAScript API is security; ECMAScript is inherently insecure, and a web service (depending on the communication protocol being used) may be easier to encrypt and protect.

Frames and session states. I my paper, I only mentioned this topic in passing, but it’s worth fleshing out a little bit.

SCORM’s current ECMAScript API requires an active JavaScript connection with the course; If the course’s connection to the SCORM API is lost, the course can’t exchange SCORM data with the LMS, effectively killing the course’s tracking functionality. Any time a webpage is unloaded in the browser, that page’s JavaScript is terminated. This is a simplistic explanation, but the point is that the browser won’t allow JavaScript to maintain a session across pages. (A session is data that persists from page to page as a user navigates through a website.)

To get around this limitation, websites often use some trickery. The most common workarounds are:

  1. Traditional framesets
  2. iframes
  3. Flash

The frameset workaround uses the parent frame to maintain session data; the parent frame never reloads, and thus never ends the session. All page loading/unloading occurs in a child frame.

The iframe workaround is much like the frameset workaround, except it uses a single inline frame instead of a full frameset.

The Flash workaround is simple: the HTML page contains a Flash movie that handles all content; the HTML file itself never reloads, allowing it to maintain a JavaScript session, while the Flash content does all the dynamic loading and unloading of content without impacting the HTML file.

Since SCORM requires an active JavaScript session to maintain communication with the API, most SCORM courses are forced to use one of these three workarounds. The problem is that all three of these methods have significant (and well-documented) usability and accessibility issues.

If SCORM 2.0 can implement some kind of Web service that eliminates the need for a JavaScript/ECMAScript API, we can also eliminate the reliance on these three workarounds. This will serve to make e-learning courses much more accessible, and reduce developers’ reliance on JavaScript.

Have you read any of the submissions?

If you’ve read any of the whitepaper submissions, I’d be interested to know which ones caught your eye or made the hair on the back of your neck stand up. And if you have opinions on the papers, definitely submit your comments to the LETSI site… they need all the feedback they can get. After all, SCORM 2.0 is for us; make sure your voice is heard!

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.