• Download PDF (110KB)

Introduction

When I started researching SCORM in preparation for developing content and implementing an LMS, what I remember most was my frustration at the lack of any concise, hands-on information that was available about SCORM. Advanced Distributed Learning (ADL) has the complete specification (all 400+ pages of it) readily available on their site, but I was looking for a quick, “get your hands dirty” explanation that skipped all the mumbo-jumbo and would let me dive in and start trying things out. Hopefully, you’ve found this whitepaper early in your search and avoided that frustration. My purpose is to give you a “real world” explanation of SCORM that you can actually use to begin understanding the details of what you’ll find in the specification itself. I’ll skip the e-learning history, theory and other vague ramblings as I’m sure you can find an abundance of it elsewhere with relative ease.

Overview

The SCORM specification, developed by Advanced Distributed Learning (ADL – http://www.adlnet.org), is a set of rules that learning management systems (LMS) and learning content follow in order to be compatible with each other. This theoretically allows the content to be loaded into, launched and tracked by any learning management system using a common rule set. Imagine your typical kitchen toaster and its electric plug that you plug-in to your wall socket. That same wall socket can have a blender, electric can opener or coffee maker plugged into it because all those appliances, along with the socket itself, comply with a set of rules dictating plugs and sockets. Things such as the number of prongs, shape and dimensions of the prongs, polarity and voltage have been published as a standard that manufacturers follow to insure that their plugs and sockets all work together. The SCORM specification is no different. Your learning management system is the wall socket. Your content is the toaster, blender, coffee maker or whatever else you plug into that socket.

Introducing the SCO…

E-Learning content is delivered as a single unit called a Sharable Content Object or SCO. SCOs are independent, self-contained, transportable packages that represent the lowest level of granularity that is tracked by a learning management system. In other words, SCOs are mini-applications that when launched from an LMS report, among other things, one score and pass/fail status. Your SCOs should contain all the necessary files required to function, have or require no knowledge of any other SCO or external information, and as a matter of design, should remain relatively small such that they can be easily reused.

And since the spec indicates that SCOs shall be transportable, you could infer that they should also be platform independent, although this is not explicitly stated. Server dependencies such as Coldfusion, Perl, ASP or server-based databases are problematic as a particular LMS might be running on a server that does not have those services available. So unless you are working in a tightly controlled internal environment, your SCOs should only be using client-side technologies such as HTML, Flash and Javascript.

…and the Content Package

Now before we get into the details of the SCO, realize that we must to be able to transport it – even if that only means getting it from our desktop computer where we created it to the server where our LMS is hosted. To do so, we use a Content Package. Going back to our wall socket analogy, imagine that the content package is the box in which the toaster is packed and transported. In reality, it is simply a single compressed file containing all the files (html, images, flash swf, etc) necessary for the SCO to function. The content package may contain more than one SCO (a toaster and coffee-maker perhaps) and a single manifest file which describes the contents of the package. The LMS will use the manifest file to properly find and import each of the SCOs.

Web-Based and Script Enabled

While there is no specific requirement that learning management systems be web-based, SCOs must be. This requirement gives developers a common platform (the web browser) to design and develop their content to function within, thereby removing unnecessary barriers to compatibility and transportability. Of course, even with the current maturity of web-browsers, they are not all created equal and SCORM makes no mention of a specification to be followed to ensure web-browser compatibility. Compliance with the latest W3C standards however, is a safe course of action to ensure compatibility with a wide range of current web-browsers. And in order for a SCO to communicate data to and from the LMS as well as potentially provide interactivity and quizzing functionality, it’s going to require more than just client-side HTML. SCORM specifies that SCOs use an ECMA Standards compliant scripting language to communicate with the LMS. The most notable ECMA compliant language is one you’ve probably heard of – JavaScript.

SCO and Content Package Summary

So what we’ve covered regarding Sharable Content Objects can be summarized as follows: SCOs are mini-applications containing the content itself. SCOs are self-contained and transportable – all required files are included and compressed into a single content package. Content packages contain a single manifest file and may contain more than one SCO. SCOs are web-based and script-enabled – consisting of HTML, Javascript and any other client-side technology (images, Macromedia Flash, etc). SCOs are the smallest level of granularity tracked by an LMS – they report, among other things, only one score and status.

The Details

Now that you understand some of the high-level layout, we’ll explore the fundamental details to understanding SCORM. Realize that this is by no means an exhaustive exploration, but it should provide a good foundation of knowledge. Be sure to download and read the complete SCORM specification as there are many details that will not be mentioned here.

The Content Package and Manifest File

As I have mentioned, for a SCO to be uploaded to the LMS, it must be contained in a Content Package – a single compressed file conforming to the Process Interchange Format (PIF) specification. In most cases, this is simply a .ZIP file and may contain multiple SCOs.

The Content Package must also contain a Manifest File – an XML file containing information about the included SCOs and their organization. By reading the manifest file, the LMS can gather information about the SCOs that are contained in the package and will be able to launch them when appropriate.

Here’s an example of a very basic, yet fully compliant “hello world” manifest file. Note that a fair amount of optional information not covered here is usually included in a typical manifest file. For complete details be sure to refer to Section 3, Content Package Conformance Requirements of the SCORM 2004 (1.3) Conformance Requirements (CR).

Notice that the basic structure is a manifest node containing a metadata node, an organizations node and a resources node.

The Metadata Node

The required elements of this node that we have included specify the schema and schema version. Our example indicates that this content package uses the ADL SCORM schema and is compliant to the Content Aggregation Model of the SCORM 2004 (1.3) specification. Optionally, this node may also contain metadata containing extensive information about the content package including keywords, copyright information and more. This optional metadata may be included using a lom node or in an external XML file whose location would be referenced by an adlcp:location node. In either case, the lom or adlcp:location node would be located within the metadata node.

The Organizations Node

The primary layout and relationship of the contents of our package is contained in the organizations node. Notice however, that information about the assets themselves such as file location are not included here.

You’ll notice a single organization in this node, although any number is allowed. Each organization that is listed in this node can be thought of as a course once it’s uploaded into the LMS.

Each organization listed must contain a title node to indicate the title of the organization or course.

We have titled our sample course “Hello World Course.” Once imported, the LMS will use this as the display title of the course.

Each organization may contain any number of item nodes which, in turn, may also contain any number of item nodes. There is no limit to the nesting of these nodes. The lowest level of item nodes represents the SCOs or assets contained in the content package and will each include an attribute identifierref.

Our sample’s identifierref value is “sco_hello_ref” which references a resource node that we will discuss shortly. An individual resource node may be referenced by more than one item node throughout the organizations node, even from within different organizations. When this occurs, the identifierref attribute for all instances should be the same.

When present, upper layers of the item node nesting represent groupings or modules within the organization as shown by this example not contained in our sample:

Most manifest files that you see coming from authoring programs such as Macromedia Captivate and Articulate Presenter will not nest the item nodes into modules, but rather contain only one item node (representing the SCO) within the organization.

Each item node representing our SCOs and assets must contain a title node to indicate the title of the resource itself.

We have titled our SCO “Hello World Lesson” and the LMS will use this as the displayed title of the lesson once imported.

The Resources Node

Whereas the organizations node defined the layout and relationship of the content, the resources node is where the actual content information is located. Each SCO or Asset that is contained within the content package will have a corresponding resource node within this node.

The identifier attribute of our resource contains the value “sco_hello_ref”, which will correspond to the identifierref’s value in our item node that is in the organizations node above.

The href attribute lets the LMS know where the launch file for this resource is located and the adlcp:scormtype attribute indicates that this resource is a SCO rather than simply an Asset. So in our sample, the index.htm file located in the root of the content package as indicated here, is the launch file for the SCO that is titled “Hello World Lesson” as listed in the organizations node and referenced using the “sco_hello_ref” identifier.

The result of all of this is that when an LMS imports a content package containing our sample manifest it will, at a minimum, create a new lesson, title it “Hello World Lesson” and upon launch execute the file “index.htm” that is located in the root of the content package. Optionally, the LMS may also create a new course, title it “Hello World Course” and include our “Hello World Lesson” in it. In either case, our LMS has successfully imported our SCO and has the capability to launch it.

A Communications Channel – The API

Once it’s been launched, a SCO and the LMS need a communication channel through which to pass data. This is done through an object known as an API (Application Programming Interface) that is the conduit for all of the SCO to LMS and LMS to SCO communication.

The technology that the LMS vendor chooses to implement the API is completely up to them – no recommendations are made within the SCORM specification as long as the API is exposed to the SCO correctly and implements the methods and data structure required. We have seen APIs developed using Java applets, ActiveX controls and even pure JavaScript.

The SCO will be opened by the LMS in either a new browser window or framed within a page in the LMS browser window. Before communication can occur, the SCO must find the API and make contact.

The SCORM specification indicates locations where the SCO should look for the API, requires that the LMS expose the API in one of those locations and that it be a Document Object Model (DOM) object named “API_1484_11″ or “API” depending on the SCORM version you are following. Since the SCO is launched in either a new browser window or a frame within the LMS window, it will use a very simple process such as: look in my parent window (if framed) or in the window that opened me (if a new window) and see if there is an object named “API_1484_11″ (or “API”). If the API is not found, the SCO can expand its search by looking in the parent of the window that opened it, the parent of its parent, and so on according to the spec.

Once the SCO finds the API, it can invoke methods of the API to send data to and receive data from the LMS. If the API is not found, the SCO should alert the user that the connection to the LMS failed and no communication will occur.

Data Transfer

Once the SCO has found the API, they must both speak the same language if any communication is to occur. The SCORM specification has defined a small set of methods that must exist in the API and be available for the SCO to use. The methods are accessed by the SCO via JavaScript code with the syntax of objectname.methodname(argument(s)) where objectname references the API itself, methodname is the method being used (the API methods are explained below) and argument(s) are the data passed to the method. In all cases, the SCO initiates interactions and data transfer by invoking these methods.

SCORM 2004 (1.3) API Methods:

Initialize - Initializes communication with the LMS. No other API methods should be called by the SCO until Initialize has been successfully called.

When completed, the resulting returnValue will contain “true” if the method was successful, “false” if it was not.

Terminate - Terminates communication with the LMS. No other API methods should be called by the SCO after Terminate has been successfully called.

When completed, the resulting returnValue will contain “true” if the method was successful, “false” if it was not.

Commit - Saves the data that has been sent to the LMS via SetValue calls. If a SCO exits without invoking Commit, none of the learner’s data is saved to the LMS. Commit is implicitly invoked by the API when Terminate is called.

When completed, the resulting returnValue will contain “true” if the method was successful, “false” if it was not.

GetValue - Retrieves data from the LMS for use in the SCO. The SCO must pass the data element that it is requesting as an argument.

When completed, the resulting returnValue will contain the score that is retrieved from the LMS.

SetValue - Passes data from the SCO to the LMS. The data is retained and may be retrieved during the user session, but is not saved to the LMS until Commit is invoked. The SCO must indicate the data element and its value that is to be saved as arguments.

When completed, the resulting returnValue will contain “true” if the method was successful, “false” if it was not.

GetLastError - Retrieves the last numeric error code that occurred in the API as a result of invoking these methods.

When completed, the resulting returnValue will contain the code corresponding to the last error that occurred. GetErrorString – Retrieves the text description corresponding to the error code priveded.

When completed in either case, the resulting returnValue will contain a text description of the error corresponding to the errorCode that was provided.

GetDiagnostic - Exists for LMS specific use. Returns a diagnostic text description based on the parameter that is passed as an argument.

When completed, the resulting returnValue will contain the text of the diagnostic information.

Using the GetValue and SetValue methods, the SCO is able to send and retrieve all the necessary data for effective tracking to and from the LMS. Some commonly used data elements include learner_id, learner_name, score, completion_status and suspend data. The example that follows will demonstrate proper usage of a few of these elements.

An Example

So what you will find when looking at the code of a SCO is some process that is executed at launch, usually found in the onLoad event of the body tag, that finds and initializes the API. In some cases the SCO will then request and load basic information using GetValue, such as the learner’s name and id. Additionally, the SCO may attempt to load previous session data such as score, progress status or learner responses that may be necessary to continue the learner’s interaction with the SCO. From that point, SCO interactivity and functionality such as navigation and quizzing will likely operate independently of any SCORM-related functions. At certain points though, result data is passed to the LMS (using SetValue and possibly Commit) and upon completion of the SCO, perhaps within the functionality of an Exit button, the Terminate method is called.

Let’s take a look at the following HTML and Javascript code as an example. Note that the getAPI function used in the doLMSInitialize function would be included in the apiwrapper.js script file that is referenced by the script tag in the header. This function would follow the process discussed earlier to search for and return the API from the opener window or parent frames. While this process is too detailed to completely explain here, the api wrapper that is available from the ADL contains this functionality so it is not necessary to develop your own from scratch.

Let’s briefly step through this code to see what is actually happening. On page load, the doLMSInitialize function is called which uses the getAPI function to search for and return the API. The API is initialized, the learner’s name is retrieved and a welcome message is displayed in the div element whose id is “welcome.”

The question is displayed using a standard HTML form. Upon clicking the Submit button, the learner’s response is passed to the postAnswer function.

The postAnswer function evaluates the response, alerts the learner and sets the appropriate SCORM values using the API’s SetValue method.

Finally, the learner clicks the Exit button which invokes the API’s Terminate method.

What this example should illustrate for you is that a SCO is coded very much like any other interactive lesson with the occasional addition of method calls to the API when data is required or ready to be posted.

You can download this SCO and content package including the example manifest file at http://www.icslearninggroup.com/resources/helloworld.zip. This package is a functional SCORM 1.3 (2004) package that can be imported into a SCORM compliant learning management system.

Conclusion

So we’ve examined the SCO and its general operation, the API and how it provides the communications portal between the LMS and the SCO and the manifest file and how it facilitates the importation of the SCO into the LMS. In other words, we’ve only scratched the surface. To fully understand SCORM and its functionality, you should download the full specification from the ADL’s website and get familiar with it. Begin working with our sample content package and study as many other SCORM compliant SCOs as you can. The code is all client-side, so you will be able to open it with a basic text editor such as Notepad.

For more information on SCORM, learning management systems, SCORM compliant authoring tools, or to sign up for a free trial of Inquisiq Learning Management System where you can upload and test your SCORM compliant SCOs, visit us on the web at http://www.icslearninggroup.com.

• Download PDF (87KB)

Overview

Until recently, anyone who wanted to author SCORM-compliant content had few choices. Not many authoring programs existed and the technical knowledge to create compliant content was and, in fact, still is beyond the reach of most training developers. Now there are many affordable, easy to use content authoring programs to create SCORM-compliant content that can be deployed to learning management systems (LMS). Adobe, a leader in the multimedia authoring and programming industry, has recently thrown their hat into the ring and released Adobe Captivate – a SCORM-compliant authoring tool that includes screen capture, simulation, automated testing and more.

ICS Learning Group was a beta-test facility for Adobe Captivate and has an ongoing dialogue with Adobe representatives discussing how to improve Captivate and its LMS integration with relation to SCORM-compliance. Our Inquisiq R3 Learning Management System is also featured in Essentials of Adobe Captivate from IconLogic and underwent extensive testing with Captivate lessons in preparation for the book’s release.

Adobe Captivate and LMS Integration

When exporting content from Adobe Captivate, you have the option of making your package SCORM 1.2 Compliant. Specifics of the SCORM specification could fill an entire book (in fact, it does!), so let’s just say that SCORM defines what must be included in a content package (certain files which contain certain information in a certain format) and the methods that the content package must use to communicate information (student name, score, etc.) to and from the LMS. The idea is that content authoring programs and learning management systems would all be programmed to comply with the spec and therefore be compatible with each other. Unfortunately, reality has not lived up to the vision.

The SCORM 1.2 specification is long, open to some interpretation and not always logical. Developers have had to make some assumptions and, at the same time, had to predict and hope that other developers made the same assumptions! Our experience with the workings of Adobe Captivate and the development or our own SCORM-compliant LMS has given us some insight to help you get the most out of Adobe Captivate and your LMS – even if it’s not our LMS! Note that we are only focusing on SCORM 1.2. The SCORM 1.3 specification was recently released, however most learning management systems and authoring tools, even those recently released, still support SCORM 1.2 and rightfully so.

Making Sure Your Captivate Lesson is Compliant

Problem #1:

I’ll get right into it here. If you export a Captivate package that does not have any graded questions in it, it will not be SCORM-compliant. I don’t mean that it just won’t track because it has no grade to send; I mean it is not compliant. In tracing method calls from Captivate lessons, we’ve found that a lesson with no questions will not make the required call to the LMS to initialize itself upon startup. It will make the finalize call upon exit, however any compliant LMS will throw back an error when this happens. The spec dictates that a content package must initialize itself before it can finalize itself. Makes sense, right?

A tangential problem to this is that a lesson with no questions (even if the correct initialize and finalize calls are made) has no way to tell when it’s been completed, so it does not send that information to the LMS either. This secondary problem is not an issue of compliance as the SCORM specification does not require this information to be sent, but more an issue of usability. What’s the point of making a SCORM-compliant lesson and loading it into an LMS if you never find out when your users have completed it?

The Solution:

The resolution to both these problems is easy – just make sure that you have a graded interaction in your lesson. It can be an interaction that is actually presented as such or even a button or hot spot that you are sure your users will click while viewing the lesson. The possibilities here are endless, so be sure to test your solution, but the bottom line is that there needs to at least one graded interaction in your lesson.

Passing the Proper Lesson Status Value

Problem #2:

Adobe Captivate lets you choose whether to report ‘pass/fail’ or ‘complete/incomplete’ values for lesson status, but this is not an arbitrary choice. The spec dictates that this shall be determined by the lesson after querying the LMS and deciding based upon the response it receives.

When publishing with Captivate, if you select complete/incomplete, and the user fails or fails to finish the lesson, the value of ‘incomplete’ will be reported to the LMS. In the event that the user completes or passes the lesson, the value of ‘complete’ will be reported to the LMS. Likewise, if you select pass/fail, then the value of ‘pass’ will be used instead of ‘complete’ and the value of ‘fail’ will be used instead of ‘incomplete’.

Additionally, Captivate lessons never query the LMS for the value of ‘credit’, which is the element that the lesson should be using to determine whether to use ‘complete/incomplete’ or ‘pass/fail’.

The Solution:

Solving this problem may or may not even be necessary – it’s a rather minor issue. The best thing to do is make sure that you coordinate the credit setting you use in the LMS with the lesson status value you select here. Lessons that are for credit should use ‘pass/fail’ and lessons that are not for credit should use ‘complete/incomplete’. However, one thing to note, and this takes us indirectly to Problem #3 and beyond, is that the spec dictates that the LMS reevaluate the score and change this value if you have set a mastery score. We’ll come back to this when we get to Problem #4.

Passing Score In The Proper Format

Problem #3

The ‘Publish’ interface in Adobe Captivate lets you choose whether to report score as a raw value or as a percentage while the spec dictates that this value must be ‘normalized between 0 and 100′ (meaning it must be a percentage score). When you choose to report this value as a raw score, your lesson is not compliant.

Adobe tells us that they put this option for a very specific reason. The spec defines 3 values relating to score and all shall be normalized between 0 and 100 – minimum score, maximum score and what they call raw score (oddly enough, the spec calls it ‘raw score’ and at the same time dictates that it be normalized – no wonder everyone is confused!). Logically, since they are required to be normalized between 0 and 100, minimum score would always be 0 and maximum score would always be 100 so why even use them? Because of this confusion, Adobe decided to allow the content author to decide whether to report score as raw or normalized.

The problem occurs when you choose to report score as raw and then load your content into an LMS that has been implemented according to the SCORM spec because it will expect to receive score normalized. Confusion ensues!

Scenario:

You create a Captivate lesson and choose to report score as a raw value. Your lesson has 5 questions and your user gets them all correct. Your lesson is going to report ’5′ as the score and a compliant LMS is going to interpret this as 5%. Of course, your lesson should also report a lesson status of ‘complete’ or ‘passed’ (see problem #2) which will truly confuse your user when they look at their stats and see that they passed/completed a lesson with a score of only 5%!

The Solution:

This is an easy one. Unless you are certain that your LMS implements score as a raw value, always select ‘percentage’ to ensure that your lesson is compliant.

Tying It All Together

Problem #4

Take a deep breath, because problem #4 might get a little confusing. The SCORM specification instructs the LMS to change the lesson status (the same value discussed in problem #2) when certain conditions apply. When this happens, the LMS shall use the score to decide how to change the lesson status value. If you remember though, from problem #3, you may be reporting score as a non-compliant raw value, so the LMS may change the lesson status based on bad information.

To get a better understanding of this, let’s introduce mastery score. You set the mastery score by clicking the ‘Manifest’ button on the Publish Interface. mastery score is value stored in the manifest file that is included in the content package you load into the LMS. The LMS reads this value and stores it with the lesson. If you notice, Captivate instructs that this value should be between 0 and 100, or normalized.

Now the SCORM specification instructs the LMS that if mastery score is set, the lesson is being taken for credit and the lesson status is not ‘incomplete’, the LMS shall change the lesson status to the appropriate value (complete, incomplete, pass or fail) by comparing the score reported from the lesson and the mastery score that is defined in the manifest. This occurs even if the lesson has already passed a value for lesson status.

The first thing to notice is that you probably should set the mastery score to the same value that you set passing score. That way, if the LMS re-evaluates the lesson status, it will use the same value as the passing score that the lesson itself does.

Now let’s refer back to Problem #3. You had the option of reporting score as a raw value. If you chose that option, when the LMS performs this re-evaluation of lesson status, it is going to compare a raw score to the normalized mastery score. Since one value is normalized and the other is not, it should be clear that you will have some unexpected results from this.

Scenario:

You create a Captivate lesson with 20 questions. You choose to report score as a raw value (non-complaint per Problem #3, but Captivate lets you do it), choose to use ‘pass/fail’ for lesson status, enter a mastery score of 80% and enter a passing score of 80%. Your user gets 17 questions correct.

When the lesson finalizes, the lesson reports ‘pass’ to the LMS for lesson status and ’17′ for score. Everything looks good until the LMS sees that there is a mastery score and therefore it must re-evaluate the lesson status. The LMS looks at score (’17′) and sees that it is less than mastery score (’80′), so it changes lesson status to ‘fail’. In fact, a lesson created with these settings will always have its lesson status re-evaluated to ‘fail’ by the LMS because even a perfect raw score (’20′) will always be less than the mastery score (’80′).

The root of the problem is that Captivate prompts you to enter mastery score normalized, but gives you the option to report score as a raw value. They need to be on the same scale for the re-evaluation by the LMS to work properly.

The Solutions:

#1: Don’t enter a mastery score. By doing this, the LMS will not re-evaluate the lesson status and you avoid the problem altogether. But don’t forget about Problem #3 and its solution.

#2: Make sure that mastery score and score are both normalized by choosing to report score as a ‘percentage.’ You’ll notice that this is also the solution to Problem #3. If you have confirmed that your LMS expects to receive score as raw, then use Solution #3.

#3: If you must report score as a raw value, then be sure to enter a raw value for mastery score. In our scenario, instead of entering ’80′ for mastery score, you would enter ’17′. That way, when the LMS re-evaluates lesson status, both score and mastery score are on the same scale and the calculation is done correctly. While technically incorrect since the spec dictates that mastery score be normalized, we won’t worry about it because you’d only use this solution in the case that your LMS is also non-compliant because it’s expecting raw values for score. It’s a workaround.

Summary

We’ve seen that Adobe Captivate provides a robust solution for quickly developing online training solutions. But let’s not forget that we need to be mindful of the implementation of the SCORM specification by the LMS and how it’s going to react to our Captivate lessons.

Review the problems and their solutions and you can be sure that your Captivate lessons are going to comply with SCORM 1.2 and function properly when loaded into a SCORM 1.2-compliant learning management system.

For more information on ICS Learning Group or how we can help you develop and integrate your online training program, visit us on the web at www.icslearninggroup.com or call toll-free 877-427-4770.