Tony Karrer's eLearning Blog on e-Learning Trends eLearning 2.0 Personal Learning Informal Learning eLearning Design Authoring Tools Rapid e-Learning Tools Blended e-Learning e-Learning Tools Learning Management Systems (LMS) e-Learning ROI and Metrics

Tuesday, September 05, 2006

Q&A - eLearning Standards Especially SCORM

Now that I posted about Better Questions for Learning Professionals, I've been receiving questions via email from a variety of people. That's great! I like getting interesting questions. Some of them I just respond with an email. But, I'm going to try to make a practice of creating blog posts around some of the questions.

Here's a recent one to get me started:

  • Is it mandatory to use SCORM while developing an E-learning Software?

    SCORM is as close as you get to Mandatory in the world of eLearning. You want to implement your courseware to the SCORM standard if you plan to have it launched and/or tracked under an LMS. SCORM is a fairly easy standard to deal with especially since most people are fine with a single SCO that does only single score/completion reporting. More than that is most often not expected and can cause you integration problems.

    There are a couple of situations where SCORM gets dropped. One case is building a one-off course that needs simple tracking/reporting and will never run under an LMS. If you won't ever need to run it under an LMS, then SCORM is overhead you don't need (see Tracking Without an LMS).

    The other situation is if you are building something that is not a course, e.g., it's reference material. In these cases, I'm not tracking and likely it's not under the LMS. Most LMS systems have ways to launch these kinds of reference systems (they are just a web page after all).

  • What about other Standards?

    AICC goes after the same thing as what I've described above for SCORM (tracking under an LMS). However, it is less common now than SCORM and it is harder to implement (which is why it's less common). Once in a while, you will still run into this. Most of the time, it's to handle cross-domain issues, i.e., learning content is on different server than learning management. I've also seen it in an environment that had certain restrictions on JavaScript.

    There are a bunch of other standards by ADL (who is responsible for SCORM), IMS, IEEE LTSC including CORDRA™, LOM, Meta-data, etc. in the eLearning world. However, as Pierre pointed out in the comments (and I've edited the text here based on his comments - thanks Pierre) - ADL's SCORM really incorporates what we need from these other standards and thus we've not needed to spend effort going into these standards separately. (Note: ARIADNE, AICC, IEEE LTSC, and IMS all participate in ADL's work on SCORM).

    There are also standards such as WebDAV that are going to be important for authoring tool implementations in the next few years. So, when I've been consulting with vendors who are working on any kind of authoring system, that was a particularly interesting standard.

  • Can we develop the same project using : Java, JSP, J2EE, XML, Oracle, Flash combination?

    This certainly can be used. Flash may make it a litttrickierker to implement SCORM, but there are lots of resources on how to do that. SCORM uses JavaScript to communicate so you will need to embed a bit of JavaScript code on the pages your application generates.

Couple of quick updates to this post on Sept. 6, 2006:

Judy Brown has left her long time position, but the good news is that she is writing a blog - SCORM Watch. Love the name, love the blog, and we all love Judy. In her blog she pointed to a bunch of great SCORM related resources:
  • Jennifer Brooks of the ADL Co-Lab shares experiences and lessons learned through facing these issues.

  • David J McClelland shares his experiences and a standard troubleshooting method for SCORM content in his blog. (Great post on issues that many of us have faced!)

  • This does not appear to be a new posting, but one that I recently found for the ToolBook community, but it is relevant for all. Included are: the business case for SCORM; overview of SCORM including kinds of SCORM learning objects, online or offline learning objects, and organizing and sequencing learning objects; organizing learning objects and SCOs; implementing SCORM-compliant learning objects and SCOs; and packaging SCORM-compliant content. The chart on cost of content integration before SCORM and with SCORM is very interesting.

  • And - Suresh Susarla, the Business Analyst in the Workforce ADL Co-Lab at the University of Memphis in Memphis, Tennessee, asks important questions to determine whether you need SCORM:

    • Do you need to control learner access to courseware, track learner progress, or monitor the effectiveness of your e-learning content?
    • Do you want to be able to control the learner’s path through the content in some way?
    • Do you plan to develop content in house and also purchase content from one or more third-party content vendors?
    • Do you plan to use the content for multiple new audiences in the future?
    • Do you plan to reuse parts of the content in future courses?
    • Are you planning to redistribute or sell the content to another


Pierre said...

Interesting post, but it helps if you don't compare apples and pears and give credit where credit is due.
There are a bunch of other standards (ADL, IMS, IEEE LOM, etc.) in the eLearning world, but most of them come up infrequently. But, most of the time these have turned out to not be relevant to our projects.
ADL = the organisation that created and further develops SCORM.
IMS = also not a standard, but a consortium that develops numerous specifications, some of which form the foundations SCORM is developed on.
IEEE = a standards body, not a standard
LOM = the metadata standard used by ADL for SCORM 2004 / 1.3
Same goes for AICC. It is not a standard, but an organisation that provided one of the components that enable SCORM to come into existence.

While you might have a point when you say that SCORM combines all these things into a defacto standard, adding a bunch of acronyms to a stack of "irrelevant standards" is not the way to make that point I think.

Tony Karrer said...

Pierre, your post is correct and I've not done a good job in differentiating the standards bodies / technical committees / etc. from the relevant standards. I'll try to clean it up a bit.

On the other hand, I wouldn't want to confuse the issue that there's a fairly small part of SCORM that's relevant to most people. So for the kind of question being presented to me, I think that reviewing the basic SCORM specs is sufficient.

I would be curious if you disagree with that?

Also, maybe it's me, but AICC seems to both be used as the name of the committee and as the name of the standard. Do you commonly refer to AICC's CMI Guidelines for Interoperability (which I had to look up to remember the name) separately from the name AICC?

Jesse Ezell said...

Reviewing the basic SCORM specs is sort of sufficient, but the specification blows chunks... so your mileage may vary. We really need some better eLearning standards that weren't made by a bunch of government IT putzes...

Tony Karrer said...

Jesse - I've always thought of the SCORM spec (the basic LMS-course interop aspects, to be fairly simple stuff. Issues with it were significantly smaller than a lot of other specs. Obviously, you've dealt with some problems and so you have a different opinion. Any specific "chunk blowing" that you'd want to mention?

Jesse Ezell said...

I work on Articulate's upcoming product "Articulate Online." I actually have a longer writeup on this I'll be posting (I'll try to remember to send you the link when I get my blog up and running).

Basically, the main issues with SCORM as I see it fall into two categories:

1) The spec is functional rather than declarative:

It is a Javascript API... immediately that limits support of any content that doesn't use Javascript (ie. making a standard windows application support SCORM instead of traditional HTML or HTML/Flash content would be a nightmare). Additionally, it requires the burden of writing a lot of Javascript code and adds a lot of debugging headaches. A standard that was based on simple, standard HTTP request/response patterns like SOAP would be lightyears ahead of the SCORM spec, even if it gave your server exactly the same data.

2) Lack of supported standards on relating scorm info back to source information.

LMS companies and companies in charge of creating tools that ouput SCORM compliant content spend a lot of time tweaking their content or their servers to deal with all sorts of problems that SCORM brings to the table. Look at the reports that LMS's generally offer. They are pretty sorry. For instance, look a the answer report inside Moodle: It is basically just a dump of the SCORM information, because it is extremely hard to do much more than that in a manner that will work across everyone's content.

With Articulate Online, we've been able to take reporting to the next level, but it would not be possible for us to do this in a manner that would work across content from every tool vendor out there. Fortunately, we just have to focus on our own tools since we aren't building an LMS, but I do feel very sorry for people that have to support the entire ecosystem, because the standards are very poor.

Tony Karrer said...

Jesse - both are good points. Couple of quick thoughts in response.

1. But JavaScript is so simple... When SCORM first emerged, I was SO HAPPY that it was that simple. Struggling with the more complex implementation of AICC made it great. That said, it would be nice to have a JavaScript layer that would be one implementation of the standard allowing for programmatic connections as you suggested as well. If it was only SOAP (or REST or ???), that would be more painful.

2. You are right again about the complexity of the more detailed data. I'm actually not sure why that is myself and have always been curious ... but, I've always recommended going with just the basic score/completion tracking so that you avoid this. Plus, how many times have we heard someone wanting more detailed and spent a ton of time getting it to work (and report) only to have it not ever get used.

Thanks again for you thoughts!

Jesse Ezell said...

Javascript is a fairly sophisticated language with a lot of nice features and the SCORM API doesn't really take advantage of that fact, so there is no good reason to require it. Yeah, it is simple to some people, but everyone would probably agree that coding HTML is far easier for most people than dynamically generating an HTML page with Javascript. You can generate the same page both ways, but the declarative way is a lot easier because there is a lot less room for error. This may seem minor, but it has a huge impact. For example, imagine that you are building a tool to validate HTML. The case of a static HTML file is very easy to build a tool to validate against (I could point you to a bunch of online HTML validators that do just this). However, try building a tool that statically analyzes the javascript code and validates it and you will go crazy trying to think of all the little nuances and combinations that a person might use, following function calls here and there, etc.

Even for a Javascript API it is pretty bad. If there was value in having one (which I obviously think is debatable). What ADL should have done first is created a standard communication layer (SOAP/REST/Whatever). Then, they could have distributed an object library with the Javascript code to abstract everything from authors instead of a test suite. That way, instead of doing something like:

LMSSetValue("cmi.interactions.0.student_response", "a");
LMSSetValue("cmi.interactions.0.result", "correct");
LMSSetValue("cmi.interactions.0.latency", "00:00:10");

I could do something like:

interactions.add(new Interaction("a", correct, "00:00:10"));

Why create an API in a functional, object oriented language if you aren't going to have a functional or object oriented API? It makes zero sense. I can't think of a single Javascript API I've ever encountered that works the silly way the SCORM API does.

Now as far as the detailed results are concerned, our agreement here that it is so hard to get anything useful that most people just don't do it speaks volumes about how poorly written and designed the spec is. If we only needed the simple information that most people take advantage of, then 90% of the spec could be thrown out to begin with, and we wouldn't need all the hassle.

What we need is the RSS of the eLearning world. A drop dead simple XML format that gets the basics down and is really hard to screw up. Since XML allows extensions, you could then standardize simple extensions for different applications (like Dublin Core metadata or RSS enclosures from the weblog world).

Mark said...

Jesse - As I just posted over on Brent Schlenker's blog ( actually think we agree on a lot of things - the one piece I do have to jump in on is your characterization of the folks behind ADL and SCORM as "a bunch of government IT putzes". If I wasn't feeling so good this morning, I might fire back with "if the bloodsucker vendors hadn't started the e-learning industry with such Berlin Wall-like locked down proprietary systems that it required the freaking federal government to bring them all to the table so that we could even start having discussions about interoperability" - but I won't say that.

What I will say is that I have personally worked alongside the folks at ADL and SCORM for about 7 years now and your characterization of them is as wrong as my characterization of vendors above is. These people are smart, dedicated, and have worked long hours to push forward the idea of interoperability and reuseability and will probably be the first to admit that they could do things better and/or that they are clearly not there yet. "Putzes" is just not fair.

Jesse Ezell said...

Yeah, you're right about that. I'm sure they are smart people, and they do have the credit for at least forming some kind of standard. There is a lot of value in that.

Pierre said...

After reading the first reply by Jesse, I kind of lost the desire to contribute to the discussion. After reading some of his other replies I understand better where his reply is coming from. It is quite common for experts (or anyone) working for a vendor to quickly dismiss any standard as either premature, lacking functionality, being too feature rich to implement, using the wrong technology etc. And right after that they explain why they had to build their own stuff and why that is light years ahead of the rest so we all better use that.

I do not work for ADL (never have) but am and have been involved in specification development within the IMS Global Learning consortium. And yes, in the end my salary is paid for by the government. IMS, contrary to ADL, is a membership organisation that anyone can become a member of. And the specifications it develops are only as good as the sum of the people involved in the project groups.

But back to SCORM: it doesn't claim to take care of the complete life cycle of a learning object. For example, the reference model doesn't tell an LMS what to do with the data that is being send back by a SCO and how to handle that. Because a lot of content vendors choose the easy way out and stuff all the information they want to keep between sessions in a single custom delimited string in the "suspend_data" it isn't easy for an LMS to create meaningful reports based on that without having knowledge about the way each vendor does that.

Another thing SCORM doesn't involve itself with is the content creation and maintenance. If you want to use Articulate Presenter to create all your SCORM material than that is fine. But if you create tests using Articulate Presenter, you wont be able to use that test material anywhere else than within Articulate Presenter. So if you decide to switch to Adobe Breeze Presenter, then you've got a problem. Whether that is a big or small problem depends on the amount and quality of material that you already have created.

Another example: if you want to design a curriculum based on competency based learning with different levels of course material or want to design online course material where students collaborate in groups while working on assignments, you also get into uncharted waters as far as SCORM goes. Not (just) because it would be something that you couldn't do if you use SCORM, but because managing your resources / learning object etc. in that case quickly becomes a bit more complex than just requiring SCORM compliancy.
In most cases where people had a real need for what SCORM offers, it involved more than just taking care of the technical interoperability.

But I do agree with you on that part. The technical interoperability of SCORM for basic use is good / the best we've got at the moment. If Jesse creates a SCORM package using Articulate Presenter chances are very good that I will be able to import and run that content (without any or major changes) in my LMS / VLE which has support for SCORM and x number of other systems.

Jesse Ezell said...

Pierre, Presenter is pretty easy to run anywhere. At a basic level it is just passed/failed or complete/incomplete. You touch like 1% of the SCORM spec. Now, place a Quizmaker quiz inside your Presentation and the issues with the other 99% of the spec quickly come to light. My point is certainly not that everyone should use our product because we have solved this in a better way. My point is that we shouldn't have had to do something so complex and custom just to write a few useful reports. If we were going to try to support all SCORM compliant content, we would quickly go from spending time improving our product to spending time writing custom handlers for everyone's content. That is rediculous and shows how flawed the spec is. Honestly, even as flawed as the current standards are, they would be lightyears ahead if we simply had something like: "cmi.core.contentType" which told us exactly what type of results we were looking at, and then some basic information like, when contentType is "quiz," a description of the questions should be included with the package in QTI format and then some basic instructions on mapping SCORM ID/response data back to the QTI source. As it is now, when you move past the basic complete/incomplete/passed/failed information, the data SCORM gives you back means very little if you aren't going invest tons of money in writing custom code for everyone's content.