SCORM Engine
JavaScript Architecture

SCORM Engine

Get a 1-on-1 walkthrough
of SCORM Engine.

JavaScript Architecture

One of the fundamental architectural decisions that sets the SCORM Engine apart from all other SCORM delivery mechanisms is the use of a pure JavaScript architecture.  SCORM forces JavaScript on the content developer and the LMS to a point.  Specifically, the eight methods that allow for the communication between the content and the LMS are defined by the specification itself.  Every single LMS must use JavaScript to interact with the content.

From there, though, each LMS can decide how it wants to handle the data, sequencing the content and communicate with the server.

The Benefits We Reap
Avoiding Plugins/Compatibility
  • Plugins, Java Applets, and ActiveX controls have historically been among the common solutions to the SCORM problem.  At the same time, they have been partially responsible for the single biggest SCORM problem… incompatibility.
  • We avoid this source of incompatibility by using pure, vanilla, native browser functionality.  The JavaScript required to support SCORM is mainline… there’s  just a lot of it.  By mastering this large quantity of JavaScript, we’re able to produce something that works elegantly across browsers without plugins.
Debug Logs
  • When things break down, most LMSs provide no feedback, no useful way for a content author or administrator to understand why something didn’t work.  Most LMSs dump the SCORM data into an inaccessible black box.
  • The JavaScript architecture allows the SCORM Engine to share every bit of the state data in real time.  Authors and administrators can actually link the behavior of the LMS directly to the specification and confirm the behaviors of the LMS.
Look Ahead Sequencer
  • Since most LMSs maintain their sequencing and navigation logic on the server, they can’t properly render the state of the activity tree to a learner.  In some cases, this means that the LMS presents a link to a user as if it were clickable, and then returns a message like, “You’ve reached a blocked state,” when they do click it.  This is simply bad UI.
  • Because all of the logic and all of the data are available in the browser, the SCORM Engine uses a look ahead sequencer that predictively assesses potential clicks from the learner and reflects which options are actually available.
Scalability and Responsiveness
  • The SCORM 2004 sequencing algorithms require a significant amount of processing power. In most LMSs this processing happens on the server side resulting in costly round-trips and processing bottlenecks.
  • In the SCORM Engine, all of this processing happens in the browser which significantly reduces the load on the server. Furthermore, when users don’t have to wait for data to be transferred to and from the server the application is much more responsive.
Deployment Freedom
  • Using dynamic JavaScript generation and our CS2J tool, we are able to support more than one server side technology with a single code base.
How We Do It

Developing a broad application using JavaScript is not trivial.  Especially as the first versions of the SCORM Engine were developed, the tools for creating an application in JavaScript were few and far between.

Ultimately, we created a web application that dynamically generates all of the required objects to render a SCORM course and pushes that collection of objects to the browser.  In doing so, we’re able to handle all of the logic, including SCORM 2004’s Sequencing and Navigation, in the browser.  Logic about navigation, paths through the content, history, it all lives in the browser’s memory temporarily.

Persisting the data across sessions is obviously important as well, and this is done simply using AJAX, pushing the “dirty data” from the browser to the server on a periodic basis.  Having already overcome any issues related to data consistency, we reap the benefit of server side reporting and real time data in the browser.