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.
Advertisements

Customizing SCORM Manifests in Captivate and Articulate Presenter

Someone recently asked me if it was possible to customize Captivate’s SCORM manifest to reduce the need for manual editing after publishing. In her case, the manifest needed to be edited to include SumTotal TotalLMS’s custom SCORM extensions.  The answer is yes. Here’s how.

Find the Captivate files

Captivate’s publishing files are located at:

C:\Program Files\Adobe\Adobe Captivate 4\Templates\Publish

Make your edits

Find the manifest files (manifest.xml for SCORM 1.2 and manifest2004.xml for SCORM 2004), then make your edits.

If you’re adding custom SCORM extensions such as SumTotal’s c2l_cp extensions, don’t forget to include the supporting XSD files. If you’re using SCORM 2004 you can drop the extra XSD file(s) into the “Manifest2004” folder. If you’re publishing to SCORM 1.2, you’ll need to manually add the custom XSD file to your published files.

Rinse, repeat

You’ll need to repeat the process for every computer in your office that has Captivate installed. Otherwise someone on a different computer may inadvertently publish the Captivate project using the factory publishing templates.

What about Articulate?

You can do the same thing with Articulate Presenter. Their publishing templates are located here:

C:\Program Files\Articulate\Presenter\players\

Not so crazy about Moodle? Try Chamilo

Moodle, Moodle, Moodle. It’s popular. It has helped many people quickly set up their company’s web-based training. But truth be told, it doesn’t really do much for me. I have never found it fun or sexy or even intuitive. I imagine many people feel that way. So what’s Moodle got going for it, then? It’s FREE, it’s easy to set up, and there’s a thriving development community behind it that can help you when you get stuck.

Well, in case you didn’t know, there’s another game in town by the name of Dokeos. It’s not as well known in North America, but it’s huge in other countries. Dokeos mirrors Moodle in many ways: it’s easy to set up, uses the same technology (PHP/MySQL), is open-source, and has a very large developer community. Dokeos has a much different look and feel than Moodle, which I find a little cleaner and easier to use. (Disclaimer: I test drove Dokeos over a year ago and haven’t tried the latest versions)

But there’s trouble brewing in Dokeosland. Apparently there were significant differences of opinion regarding the future of Dokeos, prompting Yannick Warnier (the lead developer) as well as the entire development staff to leave the Dokeos project [link no longer available]. While this is probably very disconcerting to Dokeos users, Yannick and the former Dokeos developers are not leaving anyone hanging… they’ve forked Dokeos’ open-source code and used it to create a new LMS named Chamilo. It’s basically Dokeos under-the-hood, but with newer features and a new direction. They’re dedicated to the notion of open-source software, and are ensuring Chamilo stays open.

I highly recommend giving Chamilo a spin. I’m looking forward to trying it myself.

Side note: if you’re looking for more alternatives to Moodle, you can also try Ilias. It’s pretty nice, too.

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? 😉

Target settles accessibility lawsuit for $6 million

Think accessibility isn’t a big deal, and is only one of those issues “the other guy” has to deal with?

So did Target. And now they’ve lost $6,000,000 because of it.

In case you hadn’t heard, Target was sued by the National Federation for the Blind because its website was inaccessible for visually-impaired web surfers. At issue in the suit was whether the same accessibility standards for brick-and-mortar stores applied in cyberspace. The verdict: yes, most definitely. The suit became a class-action lawsuit, and yesterday Target settled the case, agreeing to establish a $6 million fund to pay out settlements.

Any web developer worth their salt will tell you this situation was completely avoidable.  Roger Johansson, Derek Featherstone, and Jeremy Keith (among many, many others) have been advocating progressive enhancement principles that prevent this kind of inaccessibility for a few years now. It’s amazing to me that companies as big as Target have effectively said “so what?” to such a significant number of potential customers.

Accessibility in e-learning

As an e-learning developer, I spend a lot of time wondering how the various learning management systems (LMS) have managed to skate by accessibility requirements. In my experience, almost every LMS I’ve seen uses outdated coding techniques (or over-the-top ajax) that make their system partially, if not completely, inaccessible. I often go through great pains to make my courses as accessible as possible, only to be forced to load them into a completely inaccessible LMS.

If U.S. Federal law (Section 508) requires federally-funded websites to be accessible, doesn’t that include many educational websites and web services such as LMSs and online courseware? Section 508 is ten years old already… why are so many of our LMSs and courses as inaccessible now as they were in 1998?

Probably because developers who code with accessibility in mind are still considered specialists in a small niche, when we should really be at a point where they’re a dime a dozen. Accessibility best practices should be a no-brainer, taught in entry-level web development classes alongside standardized (x)HTML markup and valid CSS.

Accessibility is essentially a non-conversation in e-learning. LMSs rarely use accessibility as a selling point, and e-learning course development tools often completely ignore accessibility (especially the Flash-based tools). This has to change, but as we all know, until there’s strong pressure or some kind of impetus to change, nothing will happen.

  • There are very few technical standards in e-learning besides SCORM, and SCORM doesn’t address accessibility; thus there is no technical enforcement for accessibility standards.
  • The e-learning development industry hasn’t felt pressure in the marketplace, so there’s no financial incentive. (Quite the opposite, actually; the industry has been leaning more and more towards inaccessible Flash-based courseware, hoping that Adobe will save the day by making Flash more accessible.)
  • The Feds haven’t really been enforcing 508 (I bet very few Fed employees even understand accessibility well enough to know what to look for), so there’s not much government pressure.

Eventually a big player in the e-learning field is going to get slapped with a lawsuit just like Target did. If that’s what it takes to wake people up, I’m hoping it’s sooner rather than later!

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.

Choosing a specific technology for your e-learning courseware

This question came in via email. I figured I would post it (keeping the author anonymous) because these are very common questions, and maybe this post can help other people out. I also want to give others the opportunity to throw in their 2 cents! 🙂

The question(s):

I am trying to decide among three vendors for an e-learning project. Two of them are advocating using Flash/XML, Javascript, .swf files, etc. One is planning to use Toolbook for the development.

I am trying to decide the advantages of one method (rapid e-learning tool like Toolbook) over the other two (combinations of tools). I have a basic understanding of all of the technology, and I have been trying to research this (this is where I got your site), but I’d really like some non-vendor insight as to the pros and cons of one approach over the other.

This is a standalone e-learning course. It can be run through an LMS system, a web browser or if need be, we could distribute it on CD although we don’t forsee doing that. It needs to be SCORM, AICC, and 508 compliant.

Could you help me out? If you could advise on areas such as ease of translation and skills/tools needed to update later on as well, that would be great.

Choosing a tool/course file format

I don’t have enough time to get into the depths of the issue, but here are my gut reactions:

Toolbook.
Avoid Toolbook! It was a great program for its time, but it doesn’t work in a native Web format; anything created in Toolbook is Windows-only (no Mac compatibility). To create a course that works online — and with Macs — you’ll need to export the project to a Web-friendly format with reduced functionality. That’s a recipe for disaster these days. We bought a copy about a year ago — for ~$2000! — and have never used it because of these issues. Yuck.

Note: if anyone from SumTotal’s Toolbook team is reading this, I’d love to hear your thoughts; is the latest version any better? Is there new functionality I’m not aware of?

Flash/Flex with XML
This is a popular option, especially if you’re concerned about localization (XML files containing one language can be swapped with XML files containing other languages), but Flash is not particularly accessible and could potentially hurt your 508 compliance. Adobe is working on this, but they’re not quite there yet. Flash also has limitations when it comes to handling (and styling) large amounts of text.

Most e-learning vendors’ tools output to Flash SWF format; I think it’s probably for two reasons: Flash gives you a lot of control over the course (including the ability to easily add rich media such as narration or animations) and Flash is an easy way to avoid cross-platform (Windows versus Mac) issues.

(X)HTML with JavaScript
Personally, I lean heavily towards (X)HTML-based courses. HTML courses are much more flexible, accessible, and easy to update than Flash/Flex courses. Thoughts on HTML courseware:

  1. Flexibility: An HTML-based course is basically a web site with some extra JavaScript that can keep tabs on a user’s progress. As with any website, you can import almost any kind of rich media, including Flash animations, Captivate simulations, videos, images, music, quizzes, etc. Localization is a breeze because it’s HTML; by nature it can handle just about any language you throw at it. Wikipedia is a great example (though Wikipedia uses a database and PHP to handle the localization).
  2. Accessibility: HTML is much more accessible than just about any other course format out there (including Flash and Silverlight). Of course, the level of accessibility depends how the course is built; it’s up to your developer to be responsible and avoid pitfalls that can make your course less accessible. Heavy use of mouse events or xmlhttprequest in JavaScript, heavy use of rich media without providing textual equivalents, and bad development practices such as using table-based layouts and deep framesets can render an HTML page pretty inaccessible. If you import Flash SWFs on every page then you’re really no better off than you were if you just went all-Flash to begin with.
  3. Cross-browser/cross-platform: This used to be a huge barrier for web developers. Thankfully, with the emergence of Web standards and JavaScript frameworks over the last few years, things are much easier and more compatible than they used to be. Most of us are just waiting for IE6 to go away! 🙂

Delivery options

A couple of things to understand:

  1. SCORM and AICC are competing standards for course tracking/LMS communication… you don’t usually have a course that conforms to both, it’s one or the other. You can think of it as a choosing a cell phone provider: AT&T and Verizon both do roughly the same job, but with a few different ‘plan’ options. After weighing the differences, you pick the one that suits your needs (and budget). SCORM is newer than AICC and is currently the more widely accepted standard, but AICC still has a loyal following and is a viable option.
  2. SCORM/AICC tracking requires an LMS that supports one of those standards. You can’t use SCORM or AICC tracking from a non-LMS website unless someone has built a ‘lite’ LMS for you that implements a database and the API for SCORM or AICC. Likewise, SCORM/AICC won’t work from a CD-Rom.

If you need the course to be able to work (without tracking) from a website or CD-Rom, be sure to discuss it with the vendor beforehand.

Thoughts?

These were just my gut reactions to the questions. I’m sure a bunch of you have pretty strong feelings on the subject. Care to share?

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.

Bollyboard?

Funny stuff. 🙂

The Adventures of Bollywood Blackboardwala
Here’s a small series of humorous episodes related to recent Blackboard and Open Source Learning Management Systems.

The mashups are made with snippets of classic Hindi Bollywood films, overlaid with user created subtitles, from a fun online tool called BombayTV from Grapheine.

The role of Blackboardwala is played by none other than Amitabh Bacchan, of course.

http://metamedia.typepad.com/metamedia/2008/04/the-adventures.html [link no longer available]

[from e-Literate]

cmi.core.exit & cmi.exit

Ok, I just had to write a quick blurb about this one: in about 3.5 years of using SCORM in my own course code, I had never used cmi.core.exit (SCORM 1.2) or cmi.exit (SCORM 2004). Seems incredibly daft of me now that I’ve taken a few minutes to review the documentation.

The what

What does cmi.exit do? It provides some context to the LMS regarding why the course was closed. For instance, if the course was closed because it was completed by the learner, the exit status should be set to "logout". Likewise, if the course was closed before it was completed (and the learner intends to resume where they left off), the exit status should be set to "suspend".

The why

So why is setting cmi.exit important? Well, as I learned tonight, the SCORM specification states that if cmi.exit is not set to "suspend", the LMS is not supposed to store the data used for resuming the course, and will even infer a state of completion! Even if you specify a lesson status of "incomplete", if you don’t set cmi.exit to "suspend", the LMS is free to interpret that lack of "suspend" as a completed course session — especially if you aren’t using a mastery score for the LMS to evaluate.

The SCORM 2004 docs state:

If the cmi.exit is set to “normal”, “logout”,”time-out” or “” (empty characterstring) then the SCOs learner attempt ends. The SCOs Run-Time Environment data model element values of the current learner session will NOT be available if the SCO is relaunched.

The how

If you’re using the pipwerks SCORM API wrapper (JavaScript), you could include something like this in your course code:

SCORM 1.2


//the status gets set by your course code
var courseStatus = "incomplete";

function quit(){

   if(courseStatus === "completed"){
      scorm.set("cmi.core.exit", "logout");
   } else {
      scorm.set("cmi.core.exit", "suspend");
   }
   
   scorm.quit();

}

SCORM 2004


//the status gets set by your course code
var courseStatus = "incomplete";

function quit(){

   if(courseStatus === "completed"){
      scorm.set("cmi.exit", "logout");
   } else {
      scorm.set("cmi.exit", "suspend");
   }
   
   scorm.quit();

}

The d’oh!

I never paid much attention to cmi.exit (or cmi.core.exit) because the LMS I have been using didn’t enforce that rule. If I set the lesson status to "incomplete" then closed the course, the LMS assumed the course was going to be resumed, and left the lesson status alone. Plus suspend_data was always available, regardless of whether the course was suspended or not.

Tonight while I was troubleshooting my new course interface, I noticed that no matter what SCORM code I used, the course’s lesson status was being set to "completed" every time I closed the course. I had ZERO instances of the word “completed” in my course code, so how on Earth could my course possibly get set as completed? It was driving me bananas! Eventually, I started looking at the bigger picture (manifest, LMS implementation) and discovered the cmi.exit issue.

(As mentioned in my update at the top of the page, I investigated my older courses and was relieved to discover that I had been using cmi.exit the whole time, I just forgot about it when creating my latest interface. *Sigh*)

It just goes to show that not all LMSs are equal, and even with a standard like SCORM, you can still run into implementation issues from system to system.

Oh, and it also shows that you should read the manual. I’m a guy, so I generally don’t like to look at a manual unless I absolutely have to. 😉

Update: I just double-checked my old code, and yes, I was using cmi.exit on my older projects… I just forgot about it somewhere along the way!