Sequencing and Navigation

SCORM Sequencing and Navigation

Sequencing is what happens between SCOs and outside of SCOs. When a learner exits a SCO, sequencing is responsible for determining what happens next. Sequencing determines what navigational controls and options are available to the learner. Further, it orchestrates the flow and status of the course as a whole. Sequencing doesn’t affect how SCOs operate and navigate internally, that part is still completely up to the content developer.

For the most part, using Sequencing and Navigation is optional. If no sequencing rules are specified, the default settings will provide an adequate experience for the learner. However, it may be desirable to override a few of the default sequencing rules as they can lead to counter intuitive behavior.

The SCORM 2004 Sequencing and Navigation specification is derived from the IMS Simple Sequencing (IMS SS) specification. IMS Simple Sequencing is anything but simple. The “simple” refers to the scope of the sequencing that it enables. For instance, IMS SS enables the sequencing of asynchronous training delivered online from an LMS (precisely what SCORM enables), but it doesn’t include any concept of timed delivery, an instructor who can alter the learner’s path or many other concepts that could lead to “really complicated” sequencing. While its scope may be “simple”, the implementation and use of IMS SS requires a thorough understanding of its concepts.

The first step in understanding sequencing is to recognize that IMS SS was written as a generic sequencing specification that can apply to things other than SCORM. The sequencing and navigation specification used by SCORM was not written specifically for SCORM, it was adopted for use in SCORM. Remember this fact as you read on and think “That seems overly complicated, why did they do it that way?”.

Activities

In sequencing, aggregations and SCOs are referred to by the generic term “activity”. Everything in sequencing is an activity. A sequencing activity corresponds to an item in the course’s manifest. Activities are nested in parent-child relationships (just like items) that form them into a “activity tree”. Activities that have children (called “aggregations” in content packaging) are called “clusters” in sequencing. An organization in the course’s manifest corresponds to the complete sequencing activity tree.

Every activity has two sets of data associated with it, “tracking data” and a “sequencing definition”. The tracking data represents the current state of the activity (its status, score, etc). It is largely populated by the SCORM run-time data. The sequencing definition is a set of rules that define how this activity should be sequenced and is specified in the course’s manifest.

Tracking Model

The activity tracking model contains data representing the current state of the activity. The data that is tracked closely parallels a subset of CMI data exchanged at run-time, however the terminology used and format of the data is different. Conceptually, sequencing’s tracking model captures data corresponding to completion status, satisfaction status, progress measure and score. It also tracks some data specifically related to sequencing such as the number of attempts on the activity and some data relevant only to the innards of the sequencer.

In contrast to the SCORM run-time data, every activity, even activities that correspond to aggregations, has a set of tracking data associated with. Activities that correspond to SCOs, largely have their tracking data populated from the CMI run-time data. Activities that correspond to aggregations (and thus don’t have a corresponding SCO and run-time data), have their tracking data populated based on the tracking data of their child objects in a process called “roll up”.

Activity tracking data is stored in “data model pairs”. These are best explained with an example. In the run-time data model, completion status is represented by a vocabulary with three possible values, “unknown”, “incomplete” and “completed”. In sequencing, the same set of possible values are stored in two related data model elements, both of which are binary. The first binary value indicates whether the data in the second binary value is valid. In other words, the first value distinguishes between a known and an unknown status. The second data model element indicates the actual value of the of the status, but is only meaningful if the first value is set to true. Let’s get back to the example of completion status. In the sequencing tracking model, completion status is represented by “attempt progress status” (the controlling binary element, known vs unknown) and “attempt completions status” (the element that holds the value, incomplete vs completed):

Attempt Progress Status	Attempt Completion Status	cmi.completion_status
False	False	Unknown
False	True	Unknown
True	False	Incomplete
True	True	Completed

The activity tracking model can store many sets of satisfaction and scoring data. This data is always stored on “activity objectives”. An activity objective loosely corresponds to an objective in the run-time data model. Unlike the run-time data model, where the SCO itself has a satisfaction status and score and each objective has its own satisfaction metrics, in the activity tracking model, activities only store completion metrics and satisfaction metrics are always stored in activity objectives. Because of this discrepancy, every activity contains one special objective called the “primary objective” that stores the satisfaction metrics for the activity as a whole. Each activity can have zero or more other objectives that each contain their own data set.

The tracking model also allows for data to be stored that is not associated with any particular activity. “Global objectives” are activity objectives that are shared across one or more activities. Each global objective contains the same data as local activity objective, but the data can be read and written by any activity with a “map” to the global objective. Global objectives can even be shared across courses.

Just like the run-time data, a given set of tracking model values is linked to an attempt on an activity. If the activity is re-attempted, then the data can be reset to the default values at the start of the new attempt.

Complete SCORM 2004 Sequencing Tracking Model Reference

Sequencing Definition Model

Content authors are able to specify sequencing rules via XML in the the course’s manifest. Every activity has a complete sequencing definition associated with it. Every sequencing definition element also has a default value that provides for the expected behavior, in most cases, so only values that should be overwritten need to be supplied.

The sequencing definition model rules can be broken down into the following categories:

• Sequencing Control Modes – Determine what type of navigation is allowed by the user. Usually whether free navigation via a table of contents is used or whether linear navigation via previous/next buttons is used.
• Constrain Choice Controls – Restrict the activities that the user may select from the table of contents.
• Sequencing Rules – Specify if-then conditions that determine which activities are available for delivery and which activity should be delivered next.
• Limit Conditions – Provide limits on the number of times activities can be attempted.
• Rollup Rules – Specify if-then conditions that determine how status is rolled up to clusters throughout the activity tree.
• Rollup Controls – Determine which activities participate in status rollup and how their status is weighted in relation to other activities.
• Rollup Consideration Controls – Provide more precise control over status rollup than do the rollup controls.
• Objectives – Provide a way to track the status of individual learning objectives and share this status across activities. Objectives are often overloaded and used as variables to control sequencing actions.
• Selection Controls – Provide a way to specify that only a random subset of the available activities should be delivered.
• Randomization Controls – Shuffle the order of the activities to be delivered.
• Delivery Controls – Allow for non-communicative content to be delivered and sequenced.
• Completion Threshold Controls – Allow the tracking of completion percentage. [Introduced in 4th Edition]
• Navigation Controls – Control which navigational UI elements should be presented by the LMS.

Complete SCORM 2004 Sequencing Definition Reference

Sequencing Process

The actual process of sequencing occurs whenever a course is launched, whenever a SCO exits or whenever the learner makes a navigation request through the LMS’s user interface. When the sequencer is invoked the current SCO exists and the run-time data for the current SCO is transferred over to the activity tracking data. The LMS then starts the “sequencing loop”.

The sequencing loop is a set of defined algorithms that apply the sequencing rules to the current set of tracking data to determine which activity should be delivered next. These algorithms are well-defined in the sequencing specification by a set of pseudocode that the LMS’s behavior must mimic. The sequencing loop may result in an activity to be delivered, it may result in the course exiting, it may result in a message prompt being delivered to the learner or it may result in an error condition.

Conceptually, the algorithm for the sequencing loop:

• Ensures that the incoming navigation request is properly formed
• Ends the current activity
  • Transfers the run-time data to the activity tree
  • Rolls up state data to all clusters in the activity tree
• Determines which activity should be delivered next
• Checks that the sequencing rules permit the activity to be delivered
• Delivers the identified activity to the learner

Detailed SCORM 2004 Pseudo Code Reference

Sequencing References

• Overriding the Default Sequencing Rules
• Complete SCORM 2004 Sequencing Tracking Model Reference
• Complete SCORM 2004 Sequencing Definition Reference
• Detailed SCORM 2004 Pseudo Code Reference

Sequencing Examples

• Golf Examples
  • Forced Sequential Order (Prerequisites)
  • Post Test Rollup
  • Pretest or Post Test Rollup (Testing out)
  • Randomized Testing (Test/Question Banking)
  • Simple Remediation