What is SCORM?

SCORM is a set of technical standards for e-learning software products. SCORM tells programmers how to write their code so that it can “play well” with other e-learning software. Specifically, SCORM governs how online learning content and Learning Management Systems (LMSs) communicate with each other. SCORM does not speak to instructional design or any other pedagogical concern, it is purely a technical standard.

SCORM is produced by ADL, a research group sponsored by the United States Department of Defense (DoD). Rustici Software is an independent company that specializes in helping other companies become SCORM conformant. Just as the DoD created technologies like the Internet and GPS and then spun them off to industry, ADL is currently in the process of handing over stewardship of SCORM to a new organization called LETSI.

What does SCORM stand for?

SCORM stands for “Sharable Content Object Reference Model”.

“Sharable Content Object” indicates that SCORM is all about creating units of online training material that can be shared across systems. SCORM defines how to create “sharable content objects” or “SCOs” that can be reused in different systems and contexts.

“Reference Model” reflects the fact that SCORM isn’t actually a standard. ADL didn’t write SCORM from the ground up. Instead, they noticed that the industry already had many standards that solved part of the problem. SCORM simply references these existing standards and tells developers how to properly use them together.

Accessibility: The ability to locate and access instructional components from one remote location and deliver them to many other locations.

Adaptability: The ability to tailor instruction to individual and organizational needs.

Affordability: The ability to increase efficiency and productivity by reducing the time and costs involved in delivering instruction.

Durability: The ability to withstand technology evolution and changes without costly redesign, reconfiguration or recoding.

Interoperability: The ability to take instructional components developed in one location with one set of tools or platform and use them in another location with a different set of tools or platform.

Reusability: The flexibility to incorporate instructional components in multiple applications and contexts

As a developer, what pieces do I really need to know about SCORM?

A. Here are some unsorted tips to follow when creating content:

1. Avoid using FSCommand() to communicate with JavaScript (in Flash) : Most of the tools already available to Flash for SCORM development rely heavily on FSCommand(). FSCommand() only will work effectively in a Windows environment. So, in the future, if your content is viewed on anything other than Windows, the communication will probably fail. Instead, move your reliance to getURL() to call on your JavaScript functions. Well, this are still personal preferences, you are free to experiment on your own. It is preferable to develop once, and at the same time develop for everything. Switching to getURL() means that your content will interact appropriately in Windows, Linux, Mac – on Internet Explorer, Netscape, Mozilla, Opera – whatever browser is being utilized by the LMS.
2. Abstract your API wrapper to course-specific functions : If you call on the functions in the API wrapper specifically in all your development, you’re setting yourself up for disaster. The naming conventions have changed in every version of SCORM and it’s likely that it’s going to continue to evolve. Create a separate javascript file that has function names that simply call on the functions in the API wrapper. Call on THOSE functions instead of directly calling on the functions in the API wrapper. That way, even if the function names change in later versions of SCORM, you’re changing only one file instead of digging into every single HTML page and Flash file, copying and pasting all the way through. Save myself the hassle of doing that by abstracting as much as possible.
3. Utilize XHTML and CSS2 to maximize accessibility and skin-ability : If you’re using XHTML in combination with CSS2, you’re going to make it easy to deploy your content to multiple platforms. Not just different OS’s, either – cell phones, PDA’s – just about any web-enabled device will benefit from the organization you adhere to if you’re conforming to W3C standards. If you use CSS2 style sheets, you can set multiple layout files with the same class names to “skin” your content. In this manner, you can meta-data the CSS style sheet. By abstracting style from the content, you’ll also be able to apply different styles for different deployments. When you author XHTML with <div> tags, you’re dividing up your content in a logical manner. In the absence of the CSS (like on a web-enabled device or a phone), the content still lays out logically. You can’t do that if you’re using <table> tags. The obvious advantage to using these technologies is that your 95% of the way to being 508-compliant in doing so (the other 5% being testing – because a good developer wants to be “sure” that a screen reader can actually read/interact with content appropriately).
4. Get in on the planning stages for content development early : You have to be really proactive at the
   planning stages of Instructional Development. Don’t wait until the ID’s have a curriculum in-place that they want to develop, telling you what technologies they want available. Determine their real priorities – is it
   the user experience they want or the curriculum plan? Is the SCORM conformance a priority for content object re-use, or is it so it will be compatible with any LMS? These decisions all have impact on how your SCO’s
   will be defined, which will have a huge impact on how you’re going to develop a project.
   For example, if you’re building one large Flash piece that’s going to set objectives and display tons of content – sort of acting as its own LMS, then re-use of individual pieces of content can’t be a priority. You can still tag all those pieces of content as assets, but not SCOs (a SCO can’t launch a SCO). In this example, the large Flash “player” would be the one SCO in this package, with each piece of “content” that it would display being simply an asset. You can launch assets as part of an aggregation – even on their own, and thus re-use assets, but they’re not SCOs.
5. The ease of SCORM development is in the front-end : Remember that all you need to make a SCO a SCO is an Initialize() and a Terminate(). Everything else is gravy. In total, there are only 7 calls (there is a getValue() and a setValue() and then about 3 diagnostic calls) to the LMS. That’s it. So developing for SCORM is pretty easy when you think about it, because each SCO is dumb. By that it simply means that each SCO is independent of any other SCO, so you don’t have to know what’s going on with other SCOs in order to build one. The LMS handles all that information.
6. The pain of SCORM development is in the organization of the entire course, and by definition, the manifest : The manifest controls the sequencing, the interactions, the listing of assets – all the magic happens in the manifest.
   A reiteration of what we doubtlessly know : it’s all XML. Which means if you can outline or map your course, even at a high level that just outlines the page titles, you can design your course how you want and assume that you’ll be able to find help by the way of direct help (through some means of support) or indirect help (by assuming tools will come to assist you in sequencing).

METADATA – but be smart about it : Developing MetaData is important. Really important. Forget that SCORM doesn’t require it. The fact of the matter is that you’ll want to reuse the stuff you build, eventually. It’s a heck of a lot easier to build MetaData as you’re developing than it is to go back in years from now to try and tag a SCO.

A. Here are some unsorted tips to follow when creating content:

1. Avoid using FSCommand() to communicate with JavaScript (in Flash) : Most of the tools already available to Flash for SCORM development rely heavily on FSCommand(). FSCommand() only will work effectively in a Windows environment. So, in the future, if your content is viewed on anything other than Windows, the communication will probably fail. Instead, move your reliance to getURL() to call on your JavaScript functions. Well, this are still personal preferences, you are free to experiment on your own. It is preferable to develop once, and at the same time develop for everything. Switching to getURL() means that your content will interact appropriately in Windows, Linux, Mac – on Internet Explorer, Netscape, Mozilla, Opera – whatever browser is being utilized by the LMS.

2. Abstract your API wrapper to course-specific functions : If you call on the functions in the API wrapper specifically in all your development, you’re setting yourself up for disaster. The naming conventions have changed in every version of SCORM and it’s likely that it’s going to continue to evolve. Create a separate javascript file that has function names that simply call on the functions in the API wrapper. Call on THOSE functions instead of directly calling on the functions in the API wrapper. That way, even if the function names change in later versions of SCORM, you’re changing only one file instead of digging into every single HTML page and Flash file, copying and pasting all the way through. Save myself the hassle of doing that by abstracting as much as possible.

3. Utilize XHTML and CSS2 to maximize accessibility and skin-ability : If you’re using XHTML in combination with CSS2, you’re going to make it easy to deploy your content to multiple platforms. Not just different OS’s, either – cell phones, PDA’s – just about any web-enabled device will benefit from the organization you adhere to if you’re conforming to W3C standards. If you use CSS2 style sheets, you can set multiple layout files with the same class names to “skin” your content. In this manner, you can meta-data the CSS style sheet. By abstracting style from the content, you’ll also be able to apply different styles for different deployments. When you author XHTML with <div> tags, you’re dividing up your content in a logical manner. In the absence of the CSS (like on a web-enabled device or a phone), the content still lays out logically. You can’t do that if you’re using <table> tags. The obvious advantage to using these technologies is that your 95% of the way to being 508-compliant in doing so (the other 5% being testing – because a good developer wants to be “sure” that a screen reader can actually read/interact with content appropriately).

4. Get in on the planning stages for content development early : You have to be really proactive at the
planning stages of Instructional Development. Don’t wait until the ID’s have a curriculum in-place that they want to develop, telling you what technologies they want available. Determine their real priorities – is it
the user experience they want or the curriculum plan? Is the SCORM conformance a priority for content object re-use, or is it so it will be compatible with any LMS? These decisions all have impact on how your SCO’s
will be defined, which will have a huge impact on how you’re going to develop a project.
For example, if you’re building one large Flash piece that’s going to set objectives and display tons of content – sort of acting as its own LMS, then re-use of individual pieces of content can’t be a priority. You can still tag all those pieces of content as assets, but not SCOs (a SCO can’t launch a SCO). In this example, the large Flash “player” would be the one SCO in this package, with each piece of “content” that it would display being simply an asset. You can launch assets as part of an aggregation – even on their own, and thus re-use assets, but they’re not SCOs.

5. The ease of SCORM development is in the front-end : Remember that all you need to make a SCO a SCO is an Initialize() and a Terminate(). Everything else is gravy. In total, there are only 7 calls (there is a getValue() and a setValue() and then about 3 diagnostic calls) to the LMS. That’s it. So developing for SCORM is pretty easy when you think about it, because each SCO is dumb. By that it simply means that each SCO is independent of any other SCO, so you don’t have to know what’s going on with other SCOs in order to build one. The LMS handles all that information.

6. The pain of SCORM development is in the organization of the entire course, and by definition, the manifest : The manifest controls the sequencing, the interactions, the listing of assets – all the magic happens in the manifest.
A reiteration of what we doubtlessly know : it’s all XML. Which means if you can outline or map your course, even at a high level that just outlines the page titles, you can design your course how you want and assume that you’ll be able to find help by the way of direct help (through some means of support) or indirect help (by assuming tools will come to assist you in sequencing).

METADATA – but be smart about it : Developing MetaData is important. Really important. Forget that SCORM doesn’t require it. The fact of the matter is that you’ll want to reuse the stuff you build, eventually. It’s a heck of a lot easier to build MetaData as you’re developing than it is to go back in years from now to try and tag a SCO.

Tags: Abha Anjan, Accessibility, Adaptability, ADL, Affordability, API wrapper, Content, Content Object Reference Model, contexts, course-specific functions, CSS style sheet, CSS2, dremsus, Durability, e-learning, efficiency, FSCommand, getURL(), Initialize(), instructional components, Interoperability, Learning management System, LMS, LMSs, manifest, METADATA, Model, multiple applications, Object, organizational needs, platform, productivity, reconfiguration, redesign, Reference, remote location, Reusability, scorm, SCOs, set of tools, Sharable, tailor instruction, Terminate(), United States Department of Defense (DoD), W3C standards, XHTML