This entry is part 5 of 9 in the series SCORM for Developers

Let’s roll up our sleeves and create a minimalist SCORM 1.2 course! This will be a fast and loose example, containing only the bare minimum of SCORM code and not much else. I will be moving quickly, but don’t worry if you don’t grasp all of the details right away — we will go through more realistic examples line-by-line later in this series.

The HTML

First, create a vanilla HTML page.

<!DOCTYPE html>
<html>
<head>
   <meta charset="UTF-8">
   <title>SCORM Course</title>
</head>
<body>
</body>
</html>
Code language: HTML, XML (xml)

This is a barebones HTML5 document. Nothing special.

Next, we’ll add a wee bit of JavaScript. SCORM courses use JavaScript to push and pull data from the LMS, such as the learner’s name, course status, and a bookmark for learner’s current location within the course. This is done by connecting to the SCORM application programming interface (API), which the LMS makes available in the browser’s window object. (More on this later.)

Let’s add a JavaScript <script> element to our HTML file. In the old days, this would have been placed in the <head>, but modern convention is to place it inside <body>, right before the </body> tag.

(For you old-timers, I’m using the HTML5 convention of <script> without type=“text/javascript” or lang=“javascript” — HTML5 assumes every <script> block is JavaScript, so you no longer need to specify type=“text/javascript” or lang=“javascript”.)

<!DOCTYPE html>
<html>
<head>
   <meta charset="UTF-8">
   <title>SCORM Course</title>
</head>
<body>
<script>
</script>
</body>
</html>
Code language: HTML, XML (xml)

The JavaScript

As I mentioned above, the LMS makes the SCORM API available in the window JavaScript object. Since this is a contrived SCORM 1.2 example, we can pretend the SCORM 1.2 API is already available at window.API. In the real world, the API is typically in a parent frame or different browser window; you would never actually find the API in window.API. We will discuss the API in a later lesson, for now let’s just pretend it’s at window.API.

<!DOCTYPE html>
<html>
<head>
   <meta charset="UTF-8">
   <title>SCORM Course</title>
</head>
<body> 
<script>
var API = window.API;
</script>
</body>
</html>
Code language: HTML, XML (xml)

Here’s where the fun starts. We will need to invoke the SCORM API to perform specific tasks. By spec, a SCORM course is only required to start (LMSInitialize) and stop (LMSFinish) a SCORM session. No other actions are required.

<!DOCTYPE html>
<html>
<head>
   <meta charset="UTF-8">
   <title>SCORM Course</title>
</head>
<body>
<script>
var API = window.API;

//begin the SCORM session
API.LMSInitialize("");

//end the SCORM session
API.LMSFinish("");
</script>
</body>
</html>
Code language: HTML, XML (xml)

Believe it or not, this is it — a course that meets the minimum requirements for SCORM conformance!

Explicitly Setting the Completion Status

Despite there being no attempt to set a course status or score, this minimalist code will normally result in a completion immediately upon launching the course. Why? By spec [SCORM Version 1.2 3-25], if the course does not manually specify a completion status value (via cmi.core.lesson_status) before the course session is terminated, the LMS is required to set the status to “completed”.

This brings us to a key premise of this tutorial series: LMSs don’t always adhere to the SCORM spec. Working off of assumptions can be dangerous. In this example, we should play it safe and explicitly indicate the completion status, not trusting the LMS to set it for us.

<!DOCTYPE html>
<html>
<head>
   <meta charset="UTF-8">
   <title>SCORM Course</title>
</head>
<body>
<script>
var API = window.API;

//begin the SCORM session
API.LMSInitialize("");

//Explicitly set course status to “completed”
API.LMSSetValue("cmi.core.lesson_status", "completed");

//Don’t forget to commit!
API.LMSCommit("");

//end the SCORM session
API.LMSFinish("");
</script>
</body>
</html>
Code language: HTML, XML (xml)

LMSSetValue enables the course to set the value of a specific data field in the LMS. In this example, we’re setting the value of the data field cmi.core.lesson_status to “completed”. LMSCommit specifically instructs the LMS to write the data into the LMS’s database. Think of it as clicking the save button.

And this, in all its glory, is a bare-minimum HTML-based SCORM course.

Just remember, this is a contrived example and doesn’t take any real-world concerns into account, such as what happens if window.API can’t be found, or if LMSInitialize(“”) fails. This example is not ready for testing in an LMS yet. We’ll get there, I promise!

In the next lesson, we’ll modify this example to include lesson status, error-handling, and some personalization.

Notes

  1. A course can only invoke LMSInitialize and LMSFinish once each; if the session is closed, it cannot be re-initialized. You would need to close the course and relaunch it from the LMS. Also note that due to the SCORM spec, an empty string must be passed for both LMSInitialize(“”) and LMSFinish(“”). Just one of those crazy SCORM quirks.
  2. A word about LMSCommit: Whenever you set a value using LMSSetValue, you are sending the value to a JavaScript object in the web browser, not to the LMS itself. The data in the JavaScript object is not pushed to the server (the LMS’s database) until you invoke API.LMSCommit(“”). Failure to invoke LMSCommit(“”) is a common blunder, causing an otherwise perfectly-crafted course to fail spectacularly.

    The flip side, however, is that if you invoke LMSCommit too often, it may “clog the pipes” and lead to performance issues with your course and/or LMS. This has been the case with some older off-the-shelf e-learning development tools. The best practice is to avoid invoking LMSCommit after every SetValue, and to strategically invoke it after a series of related SetValue calls. We will dive deeper in a future lesson.
Series Navigation<< SCORM: The Safe PartsFleshing Out the SCORM Example >>

Similar Posts