The Sharable Content Object Reference Model (SCORM ®) Shareable Content Object (SCO) Presentation Engine (S2PE) is a SCORM content presentation application prototype, which allows content to be abstracted from the playback mechanism. The engine removes the burden of programming Learning Management System (LMS) communication from the content author by automatically handling all communication for them. Rather th an programming content, the author describes content through Extensible Markup Language (XML) files, which the engine interprets to render the content. The engine is robust in its support for graphics, text, video, audio, 3D, Shockwave, and Flash content. The engine also supports quizzes, interactivity, and synchronization of events.

Preface
After the September 11 attack against the United States, the U.S. Department of Defense initiated a pilot university program for first responders. The initial classroom course, created as a collaboration between the U.S. National Guard, Indiana University of Pennsylvania, and Concurrent Technologies Corporation, was a three week paperwork-intensive program covering topics related to chemical, biological, radiological, nuclear and high-yield explosive attacks. Post review of the pilot program indicated the need to bring the students least familiar with the topics to a higher understanding prior to entering the classroom for advanced work.

As part of the Department of Defense (DoD), the National Guard delivers learning material through a distributed LMS learning network based on the SCORM standard. These initial lessons potentially would cover thousands of pages of material. Traditional methods of SCORM content creation would require hand building each lesson with HTML, Director, Flash, and so forth. As a proof of concept, the SCORM SCO Presentation Engine (S2PE) was created using Macromedia Director from Adobe. The purpose of the concept was to demonstrate that individuals could create engaging, voluminous SCORM 1.3 content quickly with little to no programming skills.

Introduction
This article presumes the reader has a basic understanding of SCORM. For specific information about SCORM visit www.adlnet.org.

The introduction of SCORM as a delivery mechanism for learning content has created many new challenges for developers and instructional designers. Developing and implementing even straightforward content has become difficult for many individuals and groups who are otherwise competent at their craft. The ability to understand and merge the necessary multiple technologies is a requirement that not all are able to match. These factors slow the implementation and acceptance of SCORM outside of those groups who are mandated to use it.

There are limited existing applications that can be of assistance in addressing areas of authoring content for SCORM. In the commercial software arena, most companies have only stuck a toe in the SCORM waters to test it out. Presently there is no complete development tool for the creation of SCORM content. No product addresses LMS communication and content authoring.

To facilitate the growth of SCORM and the spread of the LMS to the point of being as common as the web browser, users need simplified way to create content. Thus, the S2PE was created, using Director, as a proof of concept to meet that need.

The S2PE engine allows content authors to describe SCO content through associated XML files. Interpretation of those files, content layout, and all LMS communication is automatically handled by the presentation engine. The content is described external to the application, creating a natural separation from the learner interface.

As the application stands alone, anyone with nominal XML skills can create SCORM content successfully. Instructional Designers can now implement their vision without relying on a programmer. Additional benefits are rapid creation times for content, simple content updates, and reduced downloads for the learner.

Presentation Engine
The Presentation Engine (PE) is lightweight at about 100 Kbytes. This includes varying levels of support for graphics, 3D, text, audio, video, Flash, and Shockwave. The additional custom JavaScript libraries, necessitated by SCORM, add an additional one time download of another 100 Kbytes.

The PE is divided into two parts. The Player Module (PM) is responsible for determining the order of play and intra-SCO branching. The Content Module (CM) is responsible for LMS communications and displaying content to the learner.

During initial loading of a SCO, the PM is loaded into an empty HTML shell page. This shell page contains a placeholder where the Shockwave file is eventually loaded. The scr tag for the HTML shell page is initially set to an empty string value (Listing 1).

<param name="src" value="">
<embed src="" ... >

When the shell page is loaded, the manifest item's parameter tag is used to point to the Shockwave PM dcr file for loading into the scr placeholder tag. In this example, the filename of the PM is player.dcr (Listing 2).

<item identifier="ITEM-9298b6c0-a695-11d9-9" identifierref="intro" parameters="?dcr=player.dcr&xml=:::pl_intro.xml">
...
...
</item>

The learner initiates the above sequence of events by making a SCO selection from the LMS Table of Contents (TOC) (Figure 1).

In much existing SCORM content, it is not unusual to find a unique HTML file for each page within a SCO. The approach presented here allows all screens for every SCO to share this single HTML page. This can eliminate hundreds or even thousands of HTML files from needing to be authored and downloaded for a SCO. The result is simplified development. Since the PM is a dedicated playback file common to all SCOs, it is reasonable to ask why its path would need to be specified for each manifest item's parameters. While it is true that the playback file remains the same for each SCO, there may in fact be a situation where a unique PM file will need to be written that has capabilities beyond or completely unrelated to the generic PM. Although including an identical path to the PM dcr may seem redundant, it leaves the door open to accommodate alternative scenarios should they arise.

Once the PM is loaded into the shell it reads in the second manifest item's parameter, an XML file path. This XML file is referred to as the Intra Content Navigation Model (ICNM) (Listing 3).

<item identifier="ITEM-9298b6c0-a695-11d9-9" identifierref="intro" parameters="?dcr=player.dcr&xml=:::pl_intro.xml">
...
...
</item>

This ICNM contains the sequence of screens that comprise the selected SCO. The sequence of screens to be delivered is called a playlist. For example, the simplest of all SCOs has but a single entry in its playlist. This equates to a SCO having only one screen (Listing 4). Once the PM has successfully loaded the playlist, an internal navigation structure is built and used for intra-SCO navigation. When that navigation structure is completed, the PM automatically loads the content of the first item in the playlist for presentation. For the moment, the important point is that for each item in the playlist, there is one corresponding screen presented to the user. I explore how that happens later.

<playlist type="linear">

      <item dcr=":::content.dcr" xml=":::intro_01.xml"/>

</playlist>

A more complicated SCO might have several screens to present to the user (Listing 5). In this case, each time the learner selects the SCO's internal Next button, the next item in the list is loaded. The playlist would present the user with four successive screens for this SCO.

<playlist type="linear">
      <item dcr=":::content.dcr" xml=":::intro_01.xml"/>
      <item dcr=":::content.dcr" xml=":::intro_02.xml"/>
      <item dcr=":::content.dcr" xml=":::intro_03.xml"/>
      <item dcr=":::content.dcr" xml=":::intro_04.xml"/>
</playlist>

While this is a straightforward concept for linear presentations, a complete solution needs to include SCO screens, which contain buttons allowing branching within the SCO. In fact, the implementation of the playlist allows the embedding of playlists within playlists to n levels (Listing 6).

In the code sample below, the learner views the content of XML file 01.xml, then proceeds to 02.xml. At that screen there are two navigation buttons, each taking the user down a different path. See the button identifier in the the playlist tag as button="A", and so forth. When the button attribute is included in a playlist tag, the parent screen automatically renders the necessary navigation controls. You do this through the CM, which I discuss later.

<playlist type="linear">
   <item dcr=":::content.dcr" xml=":::01.xml"/>
   <item dcr=":::content.dcr" xml=":::02.xml">

     <playlist type="linear" button="A">
       <item dcr=":::content.dcr" xml=":::03.xml"/>
       <item dcr=":::content.dcr" xml=":::04.xml"/>
     </playlist>

     <playlist type="linear" button="B">
       <item dcr=":::content.dcr" xml=":::09.xml"/>
       <item dcr=":::content.dcr" xml=":::10.xml"/>
       <item dcr=":::content.dcr" xml=":::11.xml"/>
     </playlist>

       </item>

       <item dcr=":::content.dcr" xml=":::05.xml"/>
   <item dcr=":::content.dcr" xml=":::06.xml"/>

</playlist>

Regardless of the playlist structure, the PM automatically loads the first item in its playlist. It does so by passing control of playback to the CM. The PM is released and the CM is in control for the duration of the SCO's life. It's important to the content author that he or she can add content screens to a SCO without rewriting or recompiling any code. With just an XML editor or a simple text editor, all the desired changes can be made and instantly reviewed within the LMS environment.