ADL SCORM Sequencing and Navigation - Overview
The Sharable Content Object Reference Model (SCORM), developed by the ADL Initiative, includes the SCORM Sequencing and Navigation (SCORM-SN) specification. This specification describes how SCORM-compliant content may be delivered to learners through a set of learner -or system- initiated navigation events. The branching and flow of that content may be described by a predefined set of activities.
Several key concepts are introduced in the SCORM-SN specification. It covers the essential learning management system (LMS) responsibilities for sequencing content objects (Sharable Content Objects [SCOs] or assets) during run-time and allowing those SCOs to indicate navigation requests. The SN specification also offers guidance for providing navigation controls to learners.
Communication between content and LMSs facilitates the use of SCORM Sequencing and Navigation to present content to learners based on learners’ choices and performance at run-time. This communication also enables LMSs to track learner completion and progress while content is being presented to the learner. This specification describes in detail how sequencing behaviors are applied to track learner progress.
ADL Sharable Content Object Reference Model
- Currently, the ADL SCORM-SN specification is endorsed by the "International Organization for Standardization" under the Technical Report ISO/IEC TR 29163-4:2009.
The SCORM Sequencing and Navigation specification is derived from the IMS Simple Sequencing (IMS SS) specification, which defines a method for representing the intended behavior of an
authored learning experience such that any LMS will sequence discrete learning activities
consistently. IMS SS is labeled as simple because it defines a limited number of widely used sequencing behaviors, not because the specification itself is simple. IMS SS is not all-inclusive. In particular, IMS SS does not address, but does not necessarily preclude, artificial intelligence-based sequencing, schedule-based sequencing, sequencing requiring data from closed external systems and services (e.g., sequencing of embedded simulations), collaborative learning, customized learning or synchronization between multiple parallel learning activities.
The SCORM-SN specification defines how IMS SS is applied and extended in a SCORM environment. It defines the required behaviors and functionality that SCORM-compliant LMSs must implement to process sequencing information at run-time. More specifically, it describes the branching and flow of learning activities in terms of an activity tree, based on the results of a learner’s interactions with launched content objects and an authored sequencing strategy.
SCORM-SN is based on the following concepts:
- An Activity Tree representation of learning activities
- The Sequencing Definition Model
- The Sequencing Behaviors
IMS SS relies on the concept of learning activities. A learning activity may be loosely described as a meaningful unit of instruction; it is conceptually something the learner does while progressing through instruction. A learning activity may provide a learning resource to the learner or it may be composed of several sub-activities.
A content structure diagram is a common tool used by the instructional design community to describe the hierarchical relationship of a learning experience. IMS SS defines and utilizes a similar concept called an Activity Tree to describe a structure of learning activities. The activity tree allows the SCORM SN model to describe informational and processing requirements such as sequencing algorithms and behaviors in an implementation independent manner. The following figure represents an example of an activity tree. The root of the activity tree is activity A – the root of an activity tree is also a learning activity as defined above and more specifically a cluster (in most cases).
An Example of an Activity Tree
|Sequencing Definition Model
The SCORM Sequencing Definition Model defines a set of elements that may be used by content developers to define intended sequencing behavior. The definition model elements are applied to learning activities within the context of an activity tree. Each element has a default value that is to be assumed by any sequencing implementation in the absence of an explicitly defined value. The effects of the SCORM Sequencing Definition Model elements only apply during the application of SCORM Sequencing Behaviors (see below). A SCORM compliant LMS must support the behaviors that result from the values associated with all of the defined Sequencing Definition Model elements, including both explicitly declared and default values.
The sequencing definition model elements can be grouped into the following categories:
- Sequencing Control Modes – Elements under this category allow the content developer to affect how navigation requests are applied to an activity and how the cluster’s activities are considered while processing sequencing requests.
- Constrain Choice Controls – By default, IMS SS allows all activities anywhere in the activity tree whose parents have Sequencing Control Choice defined as True to be valid targets of a Choice navigation request. While this flexibility is useful in some sequencing strategies, it is a significant problem in others. ADL has defined a set of Constrained Choice Controls that place further conditions and behaviors on how Choice sequencing requests are processed.
- Sequencing Rules – Allow to specify sequencing rules. A sequencing rule consists of a set of conditions and a corresponding action that determine which activities are available for delivery and which activity should be delivered next.
- Limit Conditions – A content developer can define limit conditions that describe conditions under which an activity is not allowed to be delivered. Limit conditions can be associated with activities and are conditional based on an activity’s tracking status information.
- Auxiliary Resources - An activity may have auxiliary resources associated with it that provide the learner with additional services or resources. IMS SS does not define any semantics or meanings for these auxiliary resources. IMS SS does not define which resource may be made available or how the resources are used. The only thing that IMS SS provides is a means for the auxiliary resources to be associated with an activity. SCORM does not require LMSs to support auxiliary resources. If an LMS chooses to implement or provide auxiliary resources, there is no guarantee of interoperability.
- Rollup Rule Description – Cluster activities are not associated with content objects, therefore there is no direct way for learner progress information to be applied to a cluster activity. IMS SS provides a way to define how learner progress for cluster activities is to be evaluated. A set of zero or more Rollup Rules may be applied to a cluster activity and the rules are evaluated during the Overall Rollup Process. Each Rollup Rule consists of a set of child activities to consider, a set of conditions evaluated against the tracking information of the included child activities, and a corresponding action that sets the cluster’s tracking status information if the set of conditions evaluates to True.
- Rollup Control – IMS SS enables a content developer to conditionally restrict, at a broad level, if an activity contributes to its parent’s rollupProvide more precise control over status rollup than do the rollup controls.
- Rollup Consideration Controls – If an activity is included in the rollup evaluation but it’s tracking status information being evaluated (Rollup Condition) is “unknown”, then, in most cases, the rollup evaluation will result in an “unknown” value. Through implementation and community feedback, ADL discovered this behavior was too strict for many common rollup scenarios. ADL has defined a set of Rollup Consideration Controls that further refine the conditions under which an activity contributes to the rollup of its parent.
- Objective Description - With the introduction of IMS SS into SCORM, there is a mechanism now in place to associate learning objective(s) with an activity. An activity may have one or many learning objectives associated with it.
- Selection Controls – Content developers have the ability to define sequencing information that indicates when to select certain activities and limit the number of activities to be chosen. This enables a rule that can be written to state to an LMS’s sequencing implementation, e.g., “pick 4 of the 6 activities on the first attempt of an activity.”.
- Randomization Controls - Randomization Controls describe when and what actions the LMS will take to reorder the available children of encountered cluster activities, while performing the various sequencing behaviors (see below). Content developers may apply Randomization Controls to any cluster in the activity tree.
SCORM sequencing processes are derived from those described in IMS SS. IMS SS includes two data models that apply to each activity in the activity tree – a data model that maintains the state of an activity, and a data model that describes the content developer’s sequencing intentions when an activity is processed. In addition, a state model is defined that maintains the state for each individual activity and the activity tree as a whole. The sequencing processes utilize information from all three models as defined by the Sequencing Behaviors Pseudo Code. The data models and their relation to the activities can be summarized:
- Tracking Model: Captures information gathered from a learner’s interaction with the content objects associated with activities. This is a dynamic run-time (while the learner is interacting with a content object and the LMS) data model.
- Activity State Model: Manages sequencing state of each activity in the Activity Tree and the global state of the activity tree. This is a dynamic run-time data model utilized by the LMS’s sequencing implementation to manage the state of the activity tree during a sequencing session.
- Sequencing Definition Model: Describes how the various sequencing processes utilize and interpret tracking model information to sequence activities to provide the defined sequencing behaviors. Typically, this is a static data model (defined in a SCORM Content Package) describing authored sequencing intentions for a given content organization.
Version: 2004 4th Edition Version 1.1
Editor: ADL Technical Team
Release Date: 14 August 2009
Electronic Version available here
ADL Releases the Unity-SCORM Integration Toolkit Version 1.0 Beta
( 16/01/2012 )
ADL is pleased to announce the release of the Unity-SCORM Integration Toolkit. The toolkit is the result of an ADL Technical Team research and development project that focused on using games and simulations as part of an e-learning curriculum. After an assessment of the most common questions submitted to the ADL Help Desk and after gathering additional requirements from 3rd party outreach efforts, we began a project to make creating SCORM-Conformant games and simulations efficient and cost effective. Unity was selected as the game development tool for our prototype due to its ability to create web-based content.
The Unity-SCORM Integration Toolkit allows Unity developers to use simple methods, provided by a “ScormManager” object, to set the SCORM Run-Time Data Model elements without having prior experience with SCORM. For example, developers are able to make simple calls like ScormManager.GetLearnerName() to get the user’s name from the LMS. In addition, the ScormManager can be used to set values including scores, objectives and interactions. For advanced users, the entire SCORM data model is available for use.The Unity-SCORM Integration Toolkit Version 1.0 Beta
The Unity-SCORM Integration Toolkit also contains a packaging tool that can be used to create a simple SCORM Content Aggregation Package. The ScormManager and packaging tool support both SCORM Version 1.2 and SCORM 2004 4th Edition. With minor tweaks to the resulting package, SCORM 2004 2nd and 3rd Editions can also be supported.
The Unity-SCORM Integration Toolkit is a demonstration of how content developers can use a game engine to create SCORM-Conformant content. The source code is provided with the download and can be used by a 3rd party in their content and systems. In the future, ADL may release a version for open source development if a community need is identified.
ADL Next Generation Architecture Proof-of-Concepts
( 16/01/2012 )
|ADL Next Generation Architecture Proof-of-Concepts from iFest 2011
The ADL Next Generation Architecture Proof-of-Concepts from iFest 2011 (hereafter referred to as “iFest Prototypes”) are demonstrations of the potential of a new learning architecture beyond SCORM. Several prototypes were created to illustrate different requirements of the next generation architecture:
Next Generation SCORM
- Learning Record Store (LRS)
The LRS is a prototype system that stores learning records and allows for the subsequent retrieval of those records. In addition to storing a learner’s interactions while actively viewing content, an LRS can store and retrieve information without an active learner-content session. An LRS is a component found in many of today’s LMSs. The LRS concept grew out of the vision that future learning systems will be split into several separate sub-systems that communicate through predefined interfaces. The LRS is a mandatory component for all other iFest Prototypes. Each prototype will use the LRS as its tracking system.
- Content as a Service (CaaS) Course
The CaaS Course prototype comes installed with the LRS. The CaaS prototype illustrates how content can be hosted anywhere, not just in an LMS. There is no “import” process and there is no requirement that content be on the same server or domain as the LMS. The CaaS prototype illustrates:
- tracking learning experiences hosted outside of an LMS
- moving away from a content package and import process
- a solution to the SCORM cross-domain issue
- and using existing standards such as SOAP, REST and JSON for run-time communications
- Android Tablet Native Application
The Android Tablet Native Application illustrates several requirements of the next generation learning architecture. This includes:
- support for out-of-browser content such as mobile applications
- content for roles other than the learner, in this case an instructor
- and tracking of content not launched by an LMS
- Game Engine Integration
The Game Engine Integration prototype illustrates how a serious game or simulation may track data with a future learning system. This prototype integrated a Unity game, deployed as an executable, with the LRS. Requirements include:
In addition, the prototype enables multiple-learner tracking, although it was not included in the ADL demonstration.
- tracking “long-running” content,
- support for out-of-browser content,
- and tracking of content not launched by an LMS
- Legacy Content Wrapper
Let’s face it… there is a LOT of SCORM-Conformant content out there. In the past, when new versions of SCORM were released, they were not backward compatible, causing complicated and costly upgrade projects. What would a new learning architecture mean for existing SCORM-Conformant content?