Persistent API Connection

The last lesson in the SCORM for Developers series covered SCORM wrappers.

All of the code we've examine so far has been for single-page 'courses' (I use that term loosely). We’ve added our SCORM initialization code, and the course launches as expected. But what do we do if we’d like to add a second page? What happens if we add a ‘next’ button for the learner that automatically navigates from the first page to the second page? 

Believe it or not, navigating away from the first page would cause the course to stop dead in its tracks and cease reporting progress to the LMS. The SCORM API connection would be severed before the browser loads the second page into the browser window. The course session would be terminated, and any action taken on the second page would not be reported to the SCORM API.

Why?

Navigating away from the first page will cause the browser to unload all of the HTML, JavaScript, and other assets belonging to the first page. The browser will clear the table, metaphorically speaking, before serving the second page. Any assets that the two pages may have shared, such as scripts, stylesheets, or images, would have to be re-loaded.

Any JavaScript belonging to the first page, including the SCORM API connection, will stop running when the page unloads.The second page has no knowledge of the existence of the first page. 

Furthermore, the LMS likely monitors whether the first HTML file has unloaded, and will terminate the SCORM session because it knows the SCORM API connection has been severed.

You may be thinking “OK, so I just run LMSInitialize again. What’s the big deal?” Unfortunately, it’s not that simple — SCORM only allows LMSInitialize to run once per course launch, so you will not be able to re-initialize the session without closing the course window and relaunching via the LMS interface. 

The trick for SCORM courses is to never unload the HTML page that performs the initial handshake. This page will maintain the SCORM connection throughout the course session. You’d then use this single HTML page as a ‘parent’ for your course, and have all subsequent content load into this file dynamically. As you navigate the content in the course, the parent HTML remains intact, never breaking the SCORM API connection. 

There are several techniques for dynamically displaying content including toggling elements in a single monolithic HTML page, dynamically loading external content via AJAX, and using HTML framesets.

Monolithic HTML Pages

The simplest way to ensure your API connection remains active is to only use a single HTML page. For example, a slideshow system like Reveal.js places all content into <section> elements, then dynamically toggles their visibility as the visitor navigates the presentation. The page itself is never reloaded, which means the SCORM connection is never broken.

I will demonstrate how to use Reveal.js to build a course in an upcoming lesson.

Frames

The original technique recommended by the authors of SCORM is the traditional frameset, where an HTML file serves as a parent and loads HTML files as-needed into a child frames. In this scenario, the learner can navigate between child frames without unloading the parent frame. The child frames use JavaScript to send data to the parent frame, which keeps track of all course progress, and, in turn, reports the progress to the LMS via the SCORM API.

In my opinion, frames are still the best solution, though the HTML5 specification deprecates <frameset> in favor of <iframe>. 

AJAX and Reactive Frameworks

AJAX is a JavaScript technique utilizing a JavaScript’s xmlhttprequest (XHR) to load remote content. xmlhttprequest was created by Microsoft. It first appeared in Internet Explorer, and by 2005 had been adopted by other browsers. It would not be an overstatement to say AJAX completely transformed the World Wide Web and how we build websites today.

Prior to AJAX, if you wanted to change what is displayed on a page, such as a confirmation that a purchase was successful, you’d use server-side code to modify the HTML file, then completely reload the webpage to display the updated content. The AJAX technique uses JavaScript to fetch remote content (via XHR) then insert the content into the current HTML without requiring a page reload. 

The ability to alter page content without a page reload is why AJAX is a compelling option for building e-learning courses. If the page is never reloaded, the SCORM API connection remains intact.

A very famous example of an AJAX-based system is Google’s Gmail; the inbox you see when you open Gmail is one big HTML file. When you click a message in your inbox, xmlhttprequest is used to fetch the message’s content from the mail server, then JavaScript is used to merge the content into Gmail’s HTML and display the message on screen. All without requiring a page reload. 

When you close the message, JavaScript is used to hide the message and reveal your inbox again, without navigating away from the original HTML. You can view hundreds of messages without ever unloading the inbox you first saw when you opened Gmail.

AJAX is incredibly powerful, and is implemented in just about every major website you can think of. AJAX is best suited for systems that have clearly defined templates, such as Gmail’s inbox and message screens. 

Reactive Frameworks

Modern implementations of AJAX are reactive frameworks such as React, Angular, and Vue. These frameworks are AJAX on steroids, providing incredibly powerful features like reactive variables, reusable components, and the ability to quickly apply visual themes across the project.

As powerful as these systems are, they require a lot of time and careful planning to build a course framework and templates. Once you’ve built your templates, you're fairly locked in. In my experience, I found these kinds of templates less flexible over time, adding more technical debt and becoming less flexible as a result. For example, if I found or created a new JavaScript-powered interaction, I couldn't just plop it in the course – I would have to build an accompanying template, including sorting out the data fields and how to pass them to the interaction.

Having said that, a templated system utilizing reactive frameworks or traditional AJAX might be the perfect fit if your course will only need a handful of layouts or interactions!

These templatized systems can be very practical for large organizations who need to enforce specific standards across their courses. For example, templates allow a visual design team to lock the look and feel, branding, and any other visual style guidelines into place, ensuring a consistent, professional presentation regardless of who authors the course. Templates can enforce specific instructional pedagogies, which might be good if you have a very large team of instructional designers dispersed across the globe.

Templates are also clearly beneficial for e-learning development tool vendors, because a template can be throughly tested before release and easy supported afterward. 

For better or for worse, a template-based system essentially boils down to this: No flexibility means no surprises. You know ahead of time how it will look, you know ahead of time how it will behave, and you probably even know how long it will take to build a course because you’re basically just filling out forms. 

But this also underscores the price you pay when locking yourself into templates — a tremendous loss of agility when creating new layouts and interactions, and a ton of up-front work if you design your own template-based system.

If you've used a commercial e-learning development tool like Articulate Rise, you should be familiar with the limitations: What they give you is what you get, end of story. You are agreeing to be locked in to their system and their templates. 

Ultimately, this lack of flexibility is why I recommend using iframes instead of AJAX or reactive frameworks.

In iframe-based systems, your course is simply a collection of HTML pages. Each page is a blank canvas for whatever inspiration strikes you on a given day. Anything you can do with an HTML page can be done in your course. You are not locked in to a strict template system (though you can certainly make some templates to save yourself time in the future), and you can quickly try new ideas and iterate on them without having to worry about a complicated backend.

If you’ve set up your course’s tracking code to be reusable, such as what we’ve done in our prior examples, you can adapt almost any HTML-based interaction or content to work within your courses. And you can do it within minutes, not days or months.