Director Article

Director and SCORM 1.3 SCORM SCO Presentation Engine (S2PE)

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 (Figure 1). 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.

Figure 1. Player Module and Content Module

During initial loading of a SCO, the PM is loaded into an empty HTML shell page (Figure 2). 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).

Figure 2. Common HTML shell page reduces file count and downloads

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

Listing 1. Shockwave scr value is empty

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>

Listing 2. Item parameter includes a path to the PM file

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

Figure 3. Sequence of events after a user selects SCO from LMS TOC

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 (Figure 4). 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.

Figure 4. Elimination of HTML files simplifies development and reduces downloads

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>

Listing 3. Item parameter includes a path to the ICNM XML file

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>

Listing 4. The simplest possible ICNM file. It contains a single item entry.

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>

Listing 5. An ICNM file for a linear presentation that contains four screens

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>

Listing 6. An ICNM file for a presentation containing branching

Regardless of the playlist structure, the PM automatically loads the first item in its playlist (Figure 5). 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.

Figure 5. The PM automatically loads the content manager

The CM is responsible for presenting the content to the learner and handling any intra-SCO navigation. Each screen the user sees is a new instance of the CM. The CM renders everything that the learner sees on the screen. The CM loads its layout and content information from an external, XML-based Content Presentation Model (CPM) file (Figure 6). The CPM file specifies content layout information for a single screen. The CPM contains information about text, graphics, video, positioning, fonts, and so forth. See Figure 7 for the complete playback process.

Figure 6. CM loads Content Presentation Model

An entry in the CPM file might specify an image to load and the location on the screen to render the image. Or, for text, a CPM entry could specify the text string, its font, leading, color, and so forth. During playback, the CM is responsible for communicating with the LMS. If a designer had placed an image at a horizontal location of 300 pixels but later decides it should be at 290 pixels, there is no need to open Director. Just edit the appropriate XML source file and the change is automatic.

Sharing the playback engine across all SCOs ensures repeatability and control. Updates to the PE are universal and immediately reflected in all SCOs upon re-import into the LMS. The process removes typical SCORM authoring methods of unique code for every SCO and HTML page.

Figure 7. Complete playback process

© 2006 Concurrent Technologies Corporation

Page 2 of 3

Previous Page

Next Page