Business Rules, Best Practices and Examples for Army SCORM v1.2 Compliant Courseware

 

Version 1.0.2

16 November 2005

 

 

757-878-3508

DSN 826-3508

SCORM@atsc.army.mil

 

 

 

 

   

Business Rules, Best Practices and Examples for

Army SCORM v1.2 Compliant Courseware

 

For revision history see section 13

 

Quick Reference to all Business Rules.. 5

1         Executive Summary.. 8

2      Terms and Definitions.. 10

3      Content Design.. 15

3.1          All about SCOs. 15

3.1.1     Definition of a SCO.. 15

3.1.2     Army Classification of SCOs. 16

3.1.3     SCO Golden Rules. 18

3.1.4     "SCO" Acronym.. 18

3.1.5     Size of SCOs. 19

3.1.6     SCO Titles. 20

3.1.7     Location of SCO Files. 23

3.2        Aggregations. 24

3.3            Definition of a Course as used in SCORM... 27

3.4        Course Title. 28

3.5        File Naming Conventions. 29

3.6        Navigation.. 32

3.6.1     Navigation Help Feature. 32

3.6.2     SCO Navigation. 32

3.6.3     Closing or Navigating Out of a SCO.. 33

3.6.4     Previous button on first page of the SCO.. 34

3.6.5     Next button on the last page of the SCO.. 34

3.7        Table of Contents. 35

3.8        Folder Structure Example. 37

3.9        Checks on Learning.. 38

3.10       Course Map. 38

3.11       Launchable Assets. 39

3.12       Designing for Reusability.. 40

3.13       External References. 41

3.14       Prerequisites. 42

3.15       Testing Strategy.. 43

3.15.1        Considerations. 43

3.15.2        Testing Strategies. 48

4      Communication with the LMS (Run-Time Environment) 50

4.1        LMSInitialize. 51

4.2        LMSFinish.. 52

4.3        Data Transfer.. 55

4.3.1     LMSGetValue. 55

4.3.2     LMSSetValue. 56

4.3.3     LMSCommit 56

4.4        State Management.. 56

4.4.1     LMSGetLastError. 57

4.5        Macromedia Flash Specific Run-Time. 57

4.6        SCORM Data Model. 58

4.6.1     cmi.core.lesson_location (Bookmarking). 58

4.6.2     cmi.core.entry. 60

4.6.3     cmi.core.lesson_status. 60

4.6.4     cmi.core.score.raw.. 64

4.6.5     cmi.student_data.mastery_score. 65

4.6.6     cmi.core.exit 68

4.6.7     cmi.core.session_time. 69

4.6.8     cmi.core.total_time. 71

4.6.9     cmi.student_data.max_time_allowed. 71

4.6.10        cmi.student_data.time_limit_action. 72

4.6.11        cmi.suspend_data. 74

4.6.12        cmi.interactions.n.type. 75

4.6.13        cmi.interactions.n.correct_responses.n.pattern. 75

4.6.14        cmi.interactions.n.student_response. 76

4.6.15        cmi.interactions.n.result 76

4.6.16        cmi.interactions.n.weighting. 78

4.6.17        cmi.interactions.n.latency. 79

4.6.18        cmi.interactions.n.time. 79

4.6.19        cmi.comments. 80

5      Student Performance Tests (Pretests and Post Tests) 81

5.1        Pretests. 81

5.2        Post tests. 81

5.3        Test Item Data.. 82

5.4        Testing Examples. 82

5.4.1     Non-Resumable Student Performance Test 83

5.4.2     Timed Non-Resumable Student Performance Test 84

5.4.3     Resumed Student Performance Test 86

6      Meta-Data.. 87

6.1        Army Meta-data Requirements. 88

6.2        Context Specific and Context Independent Meta-data.. 88

6.3        XML Binding for Separate Meta-Data Files. 88

6.4        Recognizing the 4 Different Types of Meta-data.. 89

6.4.1     Package Level Meta-data File. 89

6.4.2     Content Aggregation Meta-data Files. 90

6.4.3     SCO Meta-data Files. 90

6.4.4     Asset Meta-data Files. 91

6.5        Developing SCORM Meta-Data.. 92

6.5.1     general.title. 93

6.5.2     general.catalogentry. 93

6.5.3     general.description. 94

6.5.4     general.keyword. 94

6.5.5     general.aggregationlevel 95

6.5.6     lifecycle.version. 96

6.5.7     lifecycle.status. 96

6.5.8     lifecycle.contribute.role. 97

6.5.9     lifecycle.contribute.centity.vcard. 97

6.5.10        lifecycle.contribute.date. 98

6.5.11        metametadata.metadatascheme. 98

6.5.12        technical.format 98

6.5.13        technical.location. 99

6.5.14        rights.cost 99

6.5.15        rights.copyrightandotherrestrictions. 100

6.5.16        classification. 100

6.5.17        Policy on Tagging SCORM Objects with Foreign Disclosure Restrictions. 104

7         Packaging.. 107

7.1        Packaging for the ILMS. 108

7.2        Packaging for the ALMS. 108

7.3        Packaging Instructions for Testing/Instructional Strategies. 108

7.3.1     Content Completion Required/Student Performance Tests with Lock-out 110

7.3.2     Content Completion Not Required/Student Performance Tests with Lock-Out 112

7.3.3     Content Completion Required/Student Performance Tests with Internal Testing Logic. 114

7.3.4     Read-Ahead Packages (No Student Performance Tests) Content Completion Not Required. 116

7.3.5     Read-Ahead Packages (No Student Performance Tests) Content Completion Required. 118

7.4        How to Create a Content Package per the SCORM Implementation Guide (http://www.adlnet.org): 119

7.5        Creating the Manifest File. 120

7.5.1     Two Types of Manifest Files. 120

7.5.2     Table of Contents contained within the Manifest File. 121

7.5.3     ADL Extensions to the Manifest File. 122

7.5.4     Manifest in Detail 124

8      Army's SCORM Testing of Courseware. 127

8.1        Developer's Responsibility.. 127

8.2        Resource Validator Test.. 127

8.3        Content Package Conformance Test.. 127

8.4        Run-Time Conformance Test.. 127

8.5        Validate Army Mandatory Meta-data and Run-time communication.. 127

8.6        Playability Test.. 127

9      Courseware Delivery.. 127

9.1        PIF (Package Interchange File) 127

10     SCORM References.. 130

11     SCORM Tools.. 131

12     SCORM Tutorials.. 132

13     Revision History.. 133

 

Quick Reference to all Business Rules:

Rule titles are hyperlinked to the rule text in this document.  Word users note that the web toolbar icons (available from the View menubar item above) contain a “back button” that supports returning to this page.

The  icon denotes rules and topics that have associated animations.  To test that your browser has the necessary software to view the animations, please click here.  Clicking on the  icon will hyperlink to an animation. 

 

Section Title	Sub-Section Title	Business Rule #	Business Rules
Executive Summary	Target Audience		Introduction to this document
Content Design	All About SCOs
		3.1.1-1	Definition of a SCO
		3.1.2-1	Independent SCO
		3.1.2-2	Dependent SCO
		3.1.2-3	Independent SCO Restrictions
		3.1.3-1	SCO Golden Rules
		3.1.4-1	Use of SCO Acronym
		3.1.5-1	Size of SCOs
		3.1.6-1	SCO Title Location/Display
		3.1.6-2	SCO Title Consistency
		3.1.6-3	SCO Title Restrictions
		3.1.7-1	Location of SCO Files
	Aggregations	3.2-1	XML Tagging of an Aggregation
	Definition of a Course
	Course Title	3.4-1	XML Tagging of the Course Title
		3.4-2	Course Title Restrictions
	File Naming Conventions	3.5-1	File and Folder Naming Conventions
		3.5-2	Prohibited Special Characters
		3.5-3	File Naming Convention for Internal GFI Files
		3.5-4	File Naming Convention for External GFI Files
	Navigation	3.6.1-1	Navigation Help
		3.6.2-1	Intra SCO Navigation Requirements
		3.6.3-1	Closing a SCO
	Table of Contents	3.7-1	XML Tagging of  Table of Contents
	Course Map	3.10-1	Course Map and Independent SCOs
		3.10-2	Course Map Hyperlink Restrictions
	Launchable Assets	3.11-1	Launchable Asset Restrictions
	Designing for Reusability	3.12-1	Reusability of Independent SCOs
		3.12-2	Exclusion of Transitional Statements in Independent SCOs
Communication with the LMS	Introduction	4-1	SCO Adherence to SCORM Run-Time Environment
	LMSInitialize	4.1-1	Initial Communication with LMS
	LMSFinish	4.2-1	Terminal Communication with LMS
		4.2-2	Closing the Browser Window
	Data Transfer	4.3.1-1	Retrieving Data from the LMS
		4.3.2-1	Writing Data to the LMS
		4.3.3-1	Persisting Data to the LMS
	State Management	4.4.1-1	LMS Communication Errors
	SCORM Data Model	4.6.1-1	SCO Bookmarking
		4.6.3-1	Setting Lesson Status
		4.6.3-2	Student Performance Test (Failure)
		4.6.3-3	Re-entry of a Completed SCO
		4.6.3-4	Student Performance Test (Success)
		4.6.4-1	Storing of Student Score
		4.6.5-1	Location of Mastery Score
		4.6.5-2	Programming Restriction of Mastery Score
		4.6.6-1	Exiting a SCO
		4.6.7-1	SCO Session Time
		4.6.8-1	Calculation for a Timed SCO
		4.6.9-1	XML Tagging for Maximum Time Allowed in a SCO
		4.6.12-1	Test Item Data for Question Type
		4.6.13-1	Test Item Data for Student Response Patterns
		4.6.14-1	Test Item Data for Student's Response to Individual Test Items
		4.6.15-1	Test Item Data for Evaluation of Student's Response
		4.6.16-1	Test Item Data for Weighted Test Items
		4.6.17-1	Test Item Data for Timed Test Items
		4.6.18-1	Timestamp for “Timed” Test Items
Meta-Data	Army Meta-Data Requirements	6-1	Meta-Data Requirements for Courseware
	XML Binding for Separate Meta-Data Files	6.3-1	XML Binding for Separate Meta-Data Files
Meta-Data (cont)	Recognizing the 4 Different types of Meta-Data	6.4.2-1	Content Aggregation Meta-Data Requirement
		6.4.3-1	SCO Meta-Data Requirement
	Developing SCORM Meta-Data	6.5.1-1	Meta-Data Requirement for Title
		6.5.2-1	Meta-Data Requirement for Catalog Entry
		6.5.3-1	Meta-Data Requirement for Description
		6.5.4-1	Meta-Data Requirement for Keywords
		6.5.5-1	Meta-Data Requirement for Aggregation Level
		6.5.6-1	Meta-Data Requirement for Version Number
		6.5.7-1	Meta-Data Requirement for Submittal Status
		6.5.8-1	Meta-Data Requirement for Contributor Role
		6.5.9-1	Meta-Data Requirement for vcard of Contributor
		6.5.10-1	Meta-Data Requirement for Submittal Date
		6.5.11-1	Meta-Data Requirement for Meta-Data Specification
		6.5.12-1	Meta-Data Requirement for MIME Types
		6.5.13-1	Meta-Data Requirement for Resource Location
		6.5.14-1	Meta-Data Requirement for Resource Cost
		6.5.15-1	Meta-Data Requirement for Copyrights
		6.5.16-1	Meta-Data Requirement for Classification System
Packaging	Introduction	7-1	SCORM Package Requirements
		7.4	How to create a Content Package
	Creating the Manifest File	7.5-1	Mandatory Manifest File Requirement
		7.5.1-1	Content Aggregation Manifest File
Courseware Delivery	PIF (Package Interchange File)	9.1-1	PIF Manifest File Location
		9.1-2	Delivery Format for SCORM Compliant Courseware
		9.1-3	Files Excluded from PIF

 

 

 

1            Executive Summary

Target Audience:  This document is intended for use by personnel (both government and contractor) involved in the design, development, and programming of all Sharable Content Object Reference Model (SCORM) v1.2 compliant Army Distributed Learning (ADL) Courseware. The Business Rules and Best Practices contained in this document are based on lessons learned from the testing of SCORM compliant courseware since September 2002.  At the Proponent agency, Instructional Systems Specialists (ISS) preparing Statements of Work (SOW) and/or overseeing contract development of Distributed Learning (DL) courseware must be familiar with this document.  Instructional Designers and programmers from contractors and/or proponent agencies designing and developing DL courseware must thoroughly understand this document. 

These Business Rules and Best Practices apply to any Army courseware that will be served on the Interim Learning Management System (ILMS) or the Army Learning Management System (ALMS).  All Business Rules must be adhered to when developing above referenced courseware.

SCORM Version:  All references to SCORM will be for version "1.2" issued in October, 2001 and specifications obtained from ADL (http://www.adlnet.org/).  Specification documents referenced are the following: 1) SCORM v1.2 Content Aggregation Model (CAM) document dated October 1, 2001; 2) SCORM v1.2 Run-Time Environment (RTE) document dated October 1, 2001.  

Notations Used:  The following notations are used throughout the document and explained below: 

·           Reel icon: Graphic link to a vignette that explains an Army or SCORM business rule.

·         BUSINESS RULE (SCORM):  A mandatory requirement to meet minimal SCORM conformance.  Comments concerning these rules must be submitted to ADL.

·         BUSINESS RULE (ARMY):  An Army mandatory requirement for implementing the SCORM specification.

·         Best Practice:  Recommended SCORM practice for what works best based on lessons learned.  Alternative approaches are acceptable as long as they comply with SCORM and Army SCORM requirements and can be implemented in the Learning Management System (LMS) appropriate for the course.

·        For the ILMS:  When implementation is different for the Army’s Interim LMS (ILMS) than for the ALMS.

·        For the ALMS:  When implementation is different for the ALMS than for the ILMS.

·        CAM:  References the SCORM Content Aggregation Model document dated October 1, 2001

·        RTE:  References the SCORM Run-Time Environment document dated October 1, 2001

This document provides Business Rules, Best Practices, definitions, explanations and sample code for developing SCORM v1.2 conformant courseware produced under the ADL Program.  The Business Rules (whether designated SCORM or Army) are mandatory requirements for Army SCORM courseware.  To promote interoperability and courseware consistency, the Best Practices defined in this document should be used to the maximum extent possible.

The SCORM has been adopted as the standard for DL courseware and introduces a paradigm shift regarding courseware design.  A SCORM course could be mapped to an Army course, phase, or module.  A "course" is no longer an interrelated set of context specific learning instruction.  Its meaning, as previously understood, has changed.  Within SCORM, a course contains reusable, independent learning objects that are described by searchable meta-data.  Careful design work still has to be done in accordance with (IAW) Training and Doctrine Command (TRADOC) Regulation (TR) 350-70 requirements.  See Student Performance Tests Section.

This document is not intended as a primer on SCORM, and the reader needs a basic understanding of the SCORM specification (http://www.adlnet.org).  For SCORM training, see the Tutorials Section.

In order to effectively use this document, one must consider the following during the front end analysis:

·        Determine which LMS (ILMS or ALMS) your course will be fielded under

·        Determine Testing Strategy

·        Determine Size of Sharable Content Objects (SCO)s

·        Determine Packaging

The latest Distributed Learning XXI (DLXXI) SOW Template (http://www.atsc.army.mil/itsd/imi/DLXXIContractDocs.asp) must be used for DL contracts, because it incorporates specific rules for SCORM in the development of Army courseware.  Compliance with the standards and specifications in this template are required for all The Army Distributed Learning Program (TADLP) courseware and are highly recommended for all other Army DL courseware designed to play on the Army's ILMS or the ALMS.  According to this template, contract deliverables will be developed according to SCORM specifications and, in addition, contain certain SCORM run-time (Communication with the LMS Section) and meta-data elements (Meta-data Section) that are SCORM optional but required by the Army.

Changes to this document are anticipated to coincide with updates to the SCORM specification as well as through identification of additional lessons learned. Document updates are scheduled annually to coincide with the U.S. Army Training Support Center (ATSC) Technical Change Control Board normally conducted in May of each year.

For SCORM technical support or to submit comments or suggestions for this document, send an e-mail to SCORM@atsc.army.mil or call 757-878-3508 (DSN 826-3508).  For accessing courseware on the Army's developmental Aspen server, send email to DevCrsWare@atsc.army.mil.

2         Terms and Definitions

Here is a list of Terms and Definitions you should know before reading this document:

 

3         Content Design

The SCORM impacts content design of courseware.  This section describes the recommended way to incorporate the design aspect of the SCORM specification for Army courseware into existing courseware design principles.  It does not replace the instructional designer.

Thorough analysis and design of courseware brings about cost savings in development.  Reusability brings about the benefit of not spending development dollars for courseware that already exists.  The time spent in analysis and design phases will reap rewards during the implementation phase.

Please note that the Manifest file, which is part of the Content Package, is referred to many times in this section for understanding concepts.  The Manifest, however, is usually not prepared until the course is fully developed and ready to be packaged. Instructions for creating a Manifest file in XML are contained in the Packaging Section.

3.1          All about SCOs

A SCO is the basic building block for SCORM conformant courseware.  It is very important and necessary to understand its meaning and usage as described as follows:

3.1.1       Definition of a SCO

3.1.1-1  BUSINESS RULE (SCORM):  A SCO represents a collection of one or more Assets that include a specific launchable Asset that utilizes the SCORM Run-Time Environment to communicate with LMSs.  (CAM 2.1.1.2)  The SCO must be specified within the Manifest with the attribute of scormtype="sco" on the <resource> element.

A SCO contains programming code that enables the SCO to communicate with the LMS via the SCORM API.  This communication enables the LMS to track the SCO and read and write Student information to the LMS.

The following is an example of the XML tagging for a SCO within the Manifest with a SCO defined by the "scormtype" attribute of the parent "resource".  The "scormtype" must have the value of "sco".

Figure 3.1.1a

 

3.1.2       Army Classification of SCOs

The Army forecasts that there may be different classifications or purposes of SCOs.

·        Independent SCOs

There are SCOs that are "independent", meaning those SCOs that are context-neutral and contain learning content and/or graded assessments.  Context-neutral implies the absence of the MOS and removal of the course and module titles.  Army structure terms of course, phase, module, lesson, etc. also would not be context-neutral.  Independent SCOs are considered "sharable" and could be stored in a SCO repository to be available to other Schoolhouses.

The content files of an independent SCO will be local files contained in the Package.  Content that the Student will be tested on must not be referenced outside the Package using a URL.  However, if there is reference material that has a URL, the independent SCO may include these references according to the External References Section.

·        Dependent SCOs

Another classification of a SCO would be a dependent SCO.  Dependent SCOs would be developed to establish the context of an otherwise context-neutral group of SCOs such as a Course Introduction, Course Overview, or Course Map SCO.  Also included would be SCOs that would transition the Student between content. For example, a dependent SCO could be developed to transition 1) from an Introduction SCO to an independent SCO, or 2) between two independent SCOs.  Dependent SCOs would probably not be reusable, because they would be dependent on the course context and be limited as a "single use" SCO.  Dependent SCO files will be local files contained in the content package.  Dependent SCOs can contain external references accessed by URLs.  See "External References" Section.

Hence, certain rules may apply to one type of SCO and not another.

3.1.2-1     BUSINESS RULE (ARMY):  An independent SCO cannot contain instructional content that is dependent on another independent SCO.  If learning content is dependent on other learning content and cannot stand-alone, then it must be combined together into one SCO.  Independent SCOs, within its instructional content, should not refer to another SCO or aggregation.

3.1.2-2     BUSINESS RULE (ARMY):  Dependent SCOs such as introduction SCOs or transitional SCOs, which have non-instructional content, may reference learning objectives, course content, etc., for the Student to understand what is to be taught.  This is acceptable to the Army.  The Army considers these transitional SCOs as "single use" objects and not reusable.

Below is an example of a course demonstrating the Course title and SCO titles along with an assumed indication of the Army classification:

Table of Contents	Army Classification
Basic Non-Commissioned Officer's Course	Course Title
Introduction to the BNCOC	Dependent SCO
Course Map	Launchable Asset
Pretest for Basic Non-Commissioned Officer's Course	Independent SCO
Strategies/Decisions	Lesson Aggregation (block)
Introduction to Strategies/Decisions	Dependent SCO
Using Field Level Strategies	Independent SCO
Using Squad Level Strategies	Independent SCO
Determine Front-Line Decisions	Independent SCO
Post test for Basic Non-Commissioned Officer's Course	Independent SCO

                                                            Figure 3.1.2a

 

3.1.2-3  BUSINESS RULE (ARMY):  Independent SCOs, within its instructional content, should not refer to another SCO or aggregation.  See the "Designing for Reusability" Section for more detail.

 

3.1.3       SCO Golden Rules

3.1.3-1     BUSINESS RULE (SCORM):  SCORM requires the following:

(1)     A SCO cannot link to another SCO.  (CAM 2.1.1.3)

(2)     A SCO must be launched by an LMS.  (RTE 3.2.1.2, CAM 2.1.1.2)

(3)     One SCO cannot access another SCO's data elements.  (RTE 3.4.1.2)

(4)     A SCO must be independent and not tied to a particular aggregation.  (CAM 2.1.1.3)

In the past, courseware has been developed using stand-alone CBT authoring tools.  These tools typically embedded all of the navigation and sequencing information within the learning content.  Reuse was difficult and sharing learning content between authoring systems was impossible.  SCORM has redefined this process.

Essentially, SCORM has brought about a new learning paradigm for developing learning resources.  Navigation, sequencing, mastery score, etc., are moved externally to bring about learning content that is reusable.  The reusability of a SCO depends on it being independent and not linked to or requiring data from another SCO.  However, reuse cannot happen if SCO-to-SCO navigation exists.  For example, if SCO-1 contains a hyperlink to SCO-2, then SCO-1 could not be extracted and reused in another course because of the link.

Major problems exist when a SCO contains links to other SCOs.  The API provided by the LMS is always given in the context of the SCO which the Student just launched.  For example, if the Student launches SCO "A", the API will only get values for SCO "A" and any values that are stored for SCO "A".  If the Student jumps to "B", "C", and "D" and then returns to the LMS, the LMS shows "A" with "D" score and status and "B", "C", and "D" as "Not Attempted".  This will confuse the students. The only way to complete "B" is to launch it from the LMS, complete it, and then exit.  It is the same with "C" and "D".  This alone makes SCO-to-SCO navigation impossible and is prohibited in SCORM.

SCOs must not rely on data from other SCOs.  SCO-B should not be relying on SCO-A having been completed, because another developer may have replaced SCO-A with their own content.  If SCOs are so tightly coupled that they cannot be repackaged or considered for reuse, then putting them into one big SCO and handling the navigation yourself sounds like the best solution.

3.1.4       "SCO" Acronym

3.1.4-1  BUSINESS RULE (ARMY):  The acronym "SCO" if referring to a Sharable Content Object must not be included in any learning content or navigation link that is displayed to the Student anywhere in the courseware.

 Best Practice:  Use the word "item" or the word "activity" to replace the acronym "SCO".  For example, "Select an activity from the Table of Contents".

"SCO" is a SCORM term, and Students are neither familiar nor expected to understand this terminology.  Displaying this acronym to the Student will confuse the student possibly causing more delay in completing the learning material or more requests for help from support personnel.

Here is an example of what NOT to do.  Below is shown a page in the right frame that is displaying the acronym "SCO" to the Student:

 

Figure 3.1.4a

3.1.5       Size of SCOs

3.1.5-1  BUSINESS RULE (SCORM):  A SCO represents the lowest level of granularity of learning resources that can be tracked by an LMS using the SCORM Run-Time Environment.  During content design and authoring activities, when determining the size of the SCO, thought should be given to the smallest logical size of content that one might desire to have tracked by a LMS.  SCOs are intended to be subjectively small units, such that potential reuse across multiple learning objectives is feasible.  SCORM does not impose any particular constraints on the exact size of a SCO.  (CAM 2.1.1.2)

Below is a diagram of different sized SCOs:

Figure 3.1.5a

 

One SCO will be developed for each ELO, or in the absence of ELOs, one SCO will be developed for each TLO.  SCOs may be developed at the sub-ELO/TLO level (e.g., learning step/activity), as necessary, to meet the course's desired educational strategy.  The instructional design and testing strategy of the training will drive the size of SCOs.  A SCO, by definition, is independent of context and is able to stand alone.  SCORM prohibits separating dependent content into separate SCOs because one SCO would be dependent upon another SCO and would not stand alone.

Consideration should be given to the "time-out" problem existing for web-based LMSs.  When there is no action performed by the Student, which triggers communication with the LMS during the learning experience, the LMS may lose connectivity with the SCO.  Some suggestions or workarounds have been frequent bookmarking, smaller SCOs or reconfiguring system settings in the LMS.  See the "cmi.core.lesson_location" section for more information about bookmarking.

The Army does not foresee "one page SCOs".  SCOs that are too small will require excessive Student interaction launching SCOs from the TOC and closing SCOs in addition to the wait time while processing.  The exception would be single HTML page SCOs containing a Flash movie, an applet, VRML, SVG, etc.

3.1.6       SCO Titles

3.1.6-1  BUSINESS RULE (SCORM):  The SCO titles must be within the imsmanifest.xml file and displayed on the Table of Contents by a SCORM compliant LMS.  (CAM 2.3.5.1.2, CAM 2.3.5.3.1.2.1)

3.1.6-2  BUSINESS RULE (ARMY):  The SCO title contained within the SCO displayed to the Student must be exactly the same as the SCO title that is displayed on the LMS Table of Contents.

SCO titles should come from the POI or TSP if the course structure is the same.  Titles could vary from the POI or TSP if redesigned to accommodate the context-neutral specifications of SCORM.

When selecting a SCO from the Table of Contents in the LMS, the Student is totally focused on the SCO title and determining from the title the content that the Student will receive.  The Student expects to see that same title displayed within the learning content.  Confusion will arise for the Student when the titles are different.  The content designer should make sure that the programmer codes the same SCO titles into the TOC within the Manifest file.

3.1.6-3     BUSINESS RULE (ARMY):  Hierarchical higher level instruction titles or words (course, phase, module, lesson, etc.,) must not be displayed within independent SCO titles.  If an independent SCO contains an ELO, it must not reference its TLO within the content or title of the SCO.  Independent SCO titles must not include the MOS, Skill Level, SQI, or ASI contained within the actual SCO pages or within the Manifest.  Independent SCO titles must not include sequencing numbers.

One title exactly describing the learning content within the SCO is best and promotes reusability.  SCOs that contain the course title, module title, and SCO title along with the topic title are confusing to the Student and unnecessary.  A SCO title of "Course Post Test" or "Module Introduction" using the hierarchical Army terms is not allowed.

When a SCO that is scoped to an ELO references its TLO within the content or title of the SCO, the SCO becomes non-sharable since it is now identified with its TLO.  Sharability is augmented when the SCO title only reflects the action statement of the learning objective. This SCO could be reused in another course at the TLO level or at the learning step level.

The SCO title is usually displayed on every page of the SCO.  It is necessary for the Student to be aware of which SCO is displayed, because there is no other indication to the Student.

Extracting a SCO with numerical sequencing in the SCO title from one course to another course would mislead and confuse the Student.  Examples of sequencing numbers are "Chapter 1" or "Topic 1".  It is acceptable that school name, school graphics, or MOS, be contained within dependent SCOs such as introduction SCOs, course map SCOs, etc.

Suppose, a new module entitled "Executive Overview of all Safety Implementations" will have 5 lessons obtained by extracting SCOs from 5 other courses.  A good example of SCO titles without sequencing numbers would be similar to the following (Please note these are dependent SCOs so there are no action statements):

Figure 3.1.6a

 

The above example of SCO titles precisely identifies the content contained in each SCO.  There are no references to the course names or module names from which the SCOs were extracted.  They do not contain any sequencing numbers to confuse the Student.

If the SCO titles contained numbering or sequencing or an unclear title, the Student could possibly see a confusing Table of Contents like the following:

Figure 3.1.6b

 

Common practice has been to include the MOS, Skill Level, SQI, and ASI in the titles of lessons.  Neither of these designations should be contained within the SCO titles of independent SCOs.

 Best Practice:  Independent SCO titles are significant to the learning resource and should display the "Action" statement of the learning objective contained within the independent SCO.

Independent SCO titles with the action statements are more appropriate and more explanatory of the instruction that is being taught. The following are examples of independent SCO titles:

Figure 3.1.6c

 

Below is a TOC example in the ILMS displaying fourteen SCO titles:  (Please note that long titles are shortened.)

Figure 3.1.6d

The MOS, SQI ASI, hierarchical Army terms  and sequencing numbers can be included in the course title, aggregation titles and dependent SCO titles but not in independent SCO titles.     The course title is not contained in independent SCO titles.     Independent SCO titles begin with action verbs and do not contain sequencing numbers or the Army hierarchical terms of "course", "phase", "module"," lesson", etc. .

 

Regarding XML tagging of SCOs, SCO titles are contained within the Manifest file in the <title> tag of parent element <item>. The <item> tag for a SCO must have an "identifierref" attribute.  The following is an example of placement of SCO titles within the <organization> section of the Manifest:

Figure 3.1.6e

 

3.1.7       Location of SCO Files

3.1.7-1     BUSINESS RULE (ARMY):  Instructional content files for all SCOs must be physically located within its SCORM content package (within the root folder or subfolder) and not referenced by a URL.

All files containing instructional learning content must be physically located within the content package.  Instructional learning content is germane to the instruction and on which the Student will be tested.  Being physically located in the package would indicate that instructional content files would not use the HTTP protocol to access the files.  URLs are permitted when hyperlinking to references provided to the Student for further study.  These hyperlinked references can be located outside of the package. The information in these “external” references would not be evaluated as part of an assessment in order to complete the instruction.  See the External References Section for how to include URLs in courseware.

 

3.2        Aggregations

Aggregations define how lower-level learning resources are gathered together, or aggregated, into a cohesive unit of instruction.  A Content Aggregation hierarchically groups SCOs and other subordinate aggregations within the Manifest, and the LMS displays the aggregation titles on the Table of Contents.  Aggregations are recommended for the hierarchical organizational grouping of learning resources in an instructionally, logical and ordered way to be presented to the Student.

3.2-1     BUSINESS RULE (SCORM): Define an Aggregation within the Manifest file by using the <item> tag without the "identifierref" attribute because an aggregation does not contain resources.  (CAM 2.3.4-#3.2.4.2)

 Best Practice: Aggregation titles should be representative of the learning objectives contained but different from the SCO, Module or Course title.  Every hierarchical level should have a different title.

Aggregations associated with a logical order:  Aggregations can support the "building block approach" to Student learning. Grouping SCOs of the same topic to form an aggregation enables the Student have some context of the learning.  The Table of Contents, shown below, displays three aggregations of lessons with sequencing numbers and Army hierarchical terms contained in the aggregation titles. 

The TOC as shown below is displayed in the ILMS.  There are three aggregations circled in red.

Figure 3.2a

 

Notice how aggregations are not hyperlinked because there is no instructional content associated with aggregations.  Aggregations are only titles that function as a grouping mechanism.  The titles of the SCOs contained in each aggregation grouping are indented to form a hierarchical Table of Contents.

Aggregations mapped to TLOs:  Aggregations that are mapped to TLOs could group one or more SCOs each containing an ELO.  An additional SCO in this group should contain an "Introduction to the TLO" (dependent) SCO.   If a TLO does not contain ELOs, then the TLO could be mapped to a SCO and be developed according to the rules for an independent SCO.

If SCOs are mapped to the ELO level, all of the ELO SCOs could be aggregated together.  Using this concept, an aggregation would map to a TLO.  The design strategy is to introduce that TLO and establish a relationship.  An aggregation only has a title (label) for this grouping of SCOs.  The "Action" statement of the TLO would be the title of the aggregation and should be different than any of its contained ELOs, but representative of the entire aggregation.  The title of a lesson without supporting ELOs would be the "Action" statement of the TLO, and itself would be a SCO.

Since an aggregation cannot link to any pages and since the TLO has an Action, Conditions, and Standards and seemingly no place to present to the Student, a dependent SCO could be created to contain the Action, Conditions and Standards of the TLO.  This SCO would be titled "Introduction to [Action Statement of the TLO]".  This dependent SCO will transition the Student to the upcoming ELOs.

If a TLO is mapped to an aggregation and the TLO has 3 ELOs, then the content structure should be as follows:

Figure 3.2b

 

Using the above scenario, example titles from the POI or TSP have been shown as follows:

Figure 3.2c

 

The XML coding used to define an aggregation within the Manifest file is the <item> tag, but the identifierref attribute is required to be absent since it must not contain actual content (per SCORM specification), and, therefore, does not need to reference resources (pages).  This <item> tag is just a container for other <item> elements.

Shown below is the XML coding in the Manifest for one aggregation with three SCOs:

 Figure 3.2d

 

NOTE:  The SCORM v1.2 term of "aggregation" has replaced the SCORM v1.1 term of "Block".

3.3            Definition of a Course as used in SCORM

The term "course" as used in this document refers to the top level of aggregation and is contained in a SCORM package.  This package can be mapped to a level of instruction as determined by the organization.  The term "course" is used because there is a Table of Contents within the Manifest, which is contained in each package.  "Course" title describes the title of the top level aggregation contained in a SCORM package.

Details are shown in the diagram below:

 Figure 3.3a

 

3.4        Course Title

3.4-1     BUSINESS RULE (SCORM):  The Course title is obtained from within the Manifest file in the <title> tag of the parent <organization>.

3.4-2     BUSINESS RULE (ARMY):  The Course title must not be contained within or referenced from the title or content of independent SCOs.

A course title is only the name of a particular collection of SCOs.  It is for reusability reasons that this title be excluded in its propagation to independent SCOs.  The course title must not be contained anywhere in the content inside independent SCOs because the SCO could not be reused "as-is" but would require modification before use in a different course.

In a SCORM-compliant LMS, the course titled is displayed according to its SCORM implementation usually once and is located above the Table of Contents.

The graphic below shows the placement of the course title as shown on the TOC in the ILMS:

 Figure 3.4a

 

An MOS, course name, school name, etc. are allowed in the course title on the Table of Contents.

For an XML example, the course title is listed in the <title> tag of the parent element <organization> within the Manifest as shown below:

 Figure 3.4b

 

3.5        File Naming Conventions

During testing of courseware on the Interim and the Army Learning Management System (ILMS/ALMS), some courseware would not load/play properly on the ALMS. Cause of the problem was due to inconsistent use of file/folder names within the courseware and imsmanifest.

 

It is imperative that courseware be portable from the ILMS to the ALMS.  All courseware file names, folder and URL names must operate in Windows and Unix environments.

 

Since Unix file naming is case sensitive and Windows file naming is not, consistent naming of files must consider capitalization.  The files “File.txt” and “file.txt” are not the same file in Unix but are the same file in Windows.

 

Unique file naming and identification is essential for sharing courseware across operating systems, Web Servers and Workstation Browsers. While it is technically possible to assign unique file names to all files, unique names are not always practical or desirable. It is common practice to use “index.html” as the launch file name for launching Sharable Content Objects (SCOs). By placing SCOs in different folders, the “index.html” file is uniquely named because the folder name is included in identifying Web and Workstation resources.  The file identification “http://folder1/index.html” is not the same file identification “http://folder2/index.html” but is the same as “http://folder1/index.html

 

 Best Practice:  The Army recommends the following naming convention for all URLs, file names and folder names within the SCORM content package:

·        A-Z, a-z, 0-9, hyphen (-) and underscore (_).

·        A single period shall be used to separate the file name from its extension.   Periods shall not be used in a folder name.

·        File names with its extension must be uniquely named (no duplicate file/extension names for different file contents).

 

Figure 3.5a

 

3.5-1  BUSINESS RULE (ARMY):  Mandatory URL, file and folder format and size:

 

• File extensions shall be limited to five characters or less.   A three character extension is recommended.   A single period shall be used to separate the file name from its extension.   Folder names shall not contain a period.

 

• The path separator shall be either “/” or “\” depending upon the operating system (Windows, Unix) because the Browser will resolve the correct path using the appropriate separator.

 

• Long file names are allowed but must conform to ISO 9660 with Microsoft’s Joliet extension and the Army’s file naming scheme. Joliet allows filenames up to 64 characters in length. While Joliet allows “spaces”, the Army’s naming scheme does not.

 

 Best Practice: Use of reserved and unsafe characters in Distributed Learning (DL) courseware:  There are a number of characters that should not be used in a Uniform Resource Locator (URL) because they cause a conflict in the interpretation of URLs or they are reserved by URL schemes.  The reserved and unsafe characters listed below shall not be used in DL file/folder/URL names for files/folders/URLs contained within a SCORM content package.  However, these characters may be used for courseware URLs external to the SCORM content package as long as they are “escaped” using their  equivalent  hexadecimal notation (e.g., %HH).   See “GFI Example: External Files to the SCORM Content Package”.

 

Reserve and Unsafe Characters With Their “Escape” Code:

 

Space	%20
"	%22
#	%23
%	%25
&	%26
/	%2F
:	%3A
;	%3B
<	%3C
=	%3D
>	%3E
?	%3F
@	%40
[	%5B
\	%5C
]	%5D
^	%5E
'	%60
{	%7B
|	%7C
}	%7D
~	%7E

 

3.5-2  BUSINESS RULE (ARMY):  Additional characters that shall not be used in DL courseware for naming files/URLs:   The following characters cause problems in a Unix Operating System environment:

 

| ; , ! @ # $ ( ) < > / \ " ' ` ~ { } [ ] = + & ^ <space> <tab>

 

 

 Best Practice:  An industry practice and an Army recommendation is to limit the alphabetic characters to all lower case and the hyphen (-) characters.  This reduces many of the human errors associated with consistently naming of URLs, file and folders names.

 

Figure 3.5b

 

3.5-3  BUSINESS RULE (ARMY):  The Army’s file naming scheme is extended to Government Furnished Information (GFI) for all files internal to the SCORM content package.

 

GFI Example for files within the SCORM content package:

 

Contractor receives, as GFI, a file named "AR 5-23 Unit Safety.pdf". This file mixes use of upper and lower case characters and uses the restricted “space” character. Before using the file in the courseware it is renamed as "AR_5-23_Unit_Safety.pdf" using all upper case characters and eliminates the restricted “space” character.

 

3.5-4  BUSINESS RULE (ARMY):  Government Furnished Information (GFI) external to the SCORM content package:  For GFI files external to the SCORM content package the reserved and unsafe characters used in Uniform Resource Locator (URL) shall be escaped (replaced with their hexadecimal equivalent).

 

GFI Example:   External Files to the SCORM Content Package:

 

Contractor receives file "http://hostname/AR 5-23 Unit Safety.pdf" as external GFI.  The file is referenced in the courseware as “http://hostname/AR%205-23%20Unit%20Safety.pdf” where “space” = %20 (hexadecimal).

 

3.6        Navigation

3.6.1       Navigation Help Feature

3.6.1-1  BUSINESS RULE (ARMY):  A Navigation Help feature must be available in each SCO.  It must explain the function of all navigation buttons because the behavior of each button and button label is not determined by SCORM. 

 Best Practice:  The Navigation Help feature can be implemented by one of several options, depending upon the complexity of the navigation:  1) a tutorial; 2) a hyperlink; or 3) a mouse-over.

3.6.2       SCO Navigation

3.6.2-1  BUSINESS RULE (ARMY):  Each active navigation button will have identifying text displayed when the mouse is hovered over the button.

 Best Practice:  The same navigation button behavior and name label should be implemented across all SCOs with a consistent look and feel.

Courseware buttons could have the same button label but different functionality.  This non-standard approach creates confusion for the Students clicking on a button and being taken to a different location than assumed.  This is frustrating not only to the Student, but also to the Tester when validating courseware as conformant or non-conformant.

With a standard navigation, aggregating SCOs from a SCO repository will produce a more professional product.  Since navigation within the SCO is not dictated by SCORM and is up to the Instructional Designer, a navigation standard is highly recommended.

3.6.3       Closing or Navigating Out of a SCO

3.6.3-1     BUSINESS RULE (ARMY):  A button must be on every page of a SCO that will close the SCO and return the Student to the LMS-generated Table of Contents.  There must not be any behavior within a SCO that closes the LMS-generated TOC.

 Best Practice:  The Document Object Model (DOM) naming convention of "top" should not be used to specify the location of the upper-most frame in a SCO.  Using this code could refer to the LMS frame and may close the LMS TOC.

 Best Practice:  With a large amount of SCO-to-LMS data transfer when closing the SCO, it is recommended to delay the closing of the SCO by displaying another final closing page in the SCO to ensure all data is transferred and that the Student obtains credit for completing the SCO.

CD-ROM based courseware is widely used by the Government.  Exiting out of the course usually means clicking on the "Exit" button, which functions as a means to close the entire course.  Since SCORM has been adopted by the U.S. Army, courseware developed to SCORM standards is required to run on a LMS giving new importance to the behavior of navigation buttons. 

A button that closes the entire course would not only close out of the SCO but also close out of the course improperly.  Therefore, any button that functions as closing or navigating away from the SCO must take the Student back to the LMS-generated TOC.

A Student may want to prematurely stop the lesson that is presently being taken.  A button must be available to close the SCO on every page.  With the exception of the first and last pages, however, this button should also initiate and store a bookmark so upon relaunch of the SCO, the Student is placed at the same page where the Student left off.

A Student may click on the X at the top right of the browser window and not using the courseware navigation buttons.  See "LMSFinish" in the "Communication with the LMS" Section.

For the ILMS:

 Best Practice:  When closing a SCO in the ILMS, the last page of the SCO may remain visible even though the SCO was closed.  In this case, a terminating page is displayed in the right frame.  The terminating page shown below in the right frame also contains a brief instruction to the Student. This best practice may or may not work in other LMSs.

This is an example of a Terminating Page in right frame

Figure 3.6.3a

 

3.6.4       Previous button on first page of the SCO

 Best Practice:  A "previous" or "back" button should be either disabled or not visible on the first page of the SCO because SCORM specifications prohibit SCO navigating to or linking to other SCOs. 

This functionality is misleading to the Student who may think that the "previous" button on the first page may launch another lesson, which would violate a SCO Golden Rule.

3.6.5       Next button on the last page of the SCO

 Best Practice:  A "next" or "forward" button must be either disabled or not visible on the last page of the SCO. 

This functionality is misleading to the Student who may think that the "next" button on the last page may launch another lesson, which would violate a SCO Golden Rule.

3.7        Table of Contents

3.7-1     BUSINESS RULE (SCORM):  The Table of Contents must be XML tagged within the Manifest file.  The LMS is responsible for reading the Manifest and displaying the Table of Contents to the Student according to the LMS implementation.  (RTE 3.2.1)

The usual TOC or Main Menu usually associated with CD-ROM and web-based courseware becomes obsolete with SCORM.  With the SCORM specifications, the Table of Contents for the course is XML tagged and contained within the Manifest file.  The LMS reads the Manifest file and displays the TOC according to the LMS implementation. 

A sample TOC launched by the ILMS is displayed below:

 Figure 3.7a

 

The above Table of Contents is shown below, XML tagged, in the "organization" section of the Manifest file.  All the titles are in bold.

<organizations default="B0">     <organization identifier="B0">         <title>88H10 Cargo Specialist</title>         <item identifier="S000" identifierref="R_S000">                 <title>Introduction to 88H10 Cargo Specialist</title>          </item>          <item identifier="S100">              <title>Lesson 1 - Sling Load Operations</title>              <item identifier="S1001" identifierref="R_S1001" isvisible="true">                  <title>Introduction to Sling Load Operations</title>              </item>              <item identifier="S1002" identifierref="R_S1002" isvisible="true">                  <title>Perform Hookup Team Duties</title>              </item>              <item identifier="S1003" identifierref="R_S1003" isvisible="true">                 <title>Rig a Cargo Net (Helicopter)</title>              </item>           </item>           <item identifier="S200">               <title>Lesson 2 - Pallet Training</title>               <item identifier="S2001" identifierref="R_S2001" isvisible="true">                   <title>Introduction to Pallet Training</title>               </item>               <item identifier="S2002" identifierref="R_S2002">                  <title>Load a 463L Pallet</title>               </item>               <item identifier="S2003" identifierref="R_S2003">                   <title>Place 463L Pallets into Storage</title>                </item>                <item identifier="S2004" identifierref="R_S2004">                   <title>Place 463L Top and Side Nets into Storage</title>                </item>                <item identifier="S2005" identifierref="R_S2005" isvisible="true">                   <title>Cover and Net a 463L Pallet</title>                </item>                <item identifier="S2006" identifierref="R_S2006" isvisible="true">                    <title>Marry and Load Two 463L Pallets</title>                </item>            </item>           <item identifier="S300">              <title>Lesson 3 - Cargo Administration</title>              <item identifier="S3001" identifierref="R_S3001">                  <title>Introduction to Cargo Administration</title>              </item>              <item identifier="S3002" identifierref="R_S3002">                  <title>Tally Cargo</title>              </item>              <item identifier="S3003" identifierref="R_S3003">                  <title>Check Cargo into In-Transit Storage Area</title>              </item>              <item identifier="S3004" identifierref="R_S3004">                 <title>Record Onward Movement of Cargo on DD Form 1384</title>              </item>            </item>       </organization> </organizations>

Figure 3-7b

 

 

Consideration should be given to aggregations regarding how the learning objects should be grouped together in the Table of Contents (see Aggregations Section.)   Also, consider how the TOC will be viewed by the Student because an organized Table of Contents can enhance the learning experience by the Student.

 

Menus inside of SCOs are acceptable as needed for intra-SCO navigation and branching to the topics contained within the SCO.

 

For further instructions for XML tagging of the Table of Contents, see "Table of Contents contained within the Manifest File" within the Packaging Section. 

 

For each Table of Contents (organization section in the Manifest), Content Aggregation meta-data is required by the Army.  See the Meta-data Section.

 

3.8        Folder Structure Example

The directory structure should be logical and intuitive and created early in the design process.  It is the developer's responsibility to define the folder structure; it is not mandated by SCORM. 

A recommended file structure consists of the following folders in the right frame below:

 Figure 3.8a

 Best Practice:  A great way to store all the metadata files in one place would be to create a metadata folder, as shown above.

3.9        Checks on Learning

 Best Practice:  Test item data (cmi.interactions) is not required for COLs.  

 Best Practice:  Scores from the COLs should not be sent to the LMS, which would indicate to the Student that a grade was collected and cause confusion.

The COL and PEs will be contained throughout the lesson as instructionally necessary and/or as agreed upon with the Proponent.  These informal assessments can be developed according to different testing strategies, the most common of which will give the Student two tries to select the correct answer and then provide review/feedback for the correct answer.  Determining whether the Student answered these assessments correctly is implemented within the lesson and should not impact the Student's ability to complete the SCO.  Credit for the course is dependent upon the completion of each SCO.

However, if test item analysis is desired to be collected, then these API function calls would be needed.  See the "Test Item Data" section for further information.

3.10    Course Map

3.10-1     BUSINESS RULE (ARMY):  A Course Map is context-specific and, if provided, must not be contained inside independent SCOs.  A Course Map inside independent SCOs negates this independence and potential reuse, and provides context specific information inside the SCO about the current course.

3.10-2  BUSINESS RULE (ARMY):  A Course Map must not contain hyperlinks to SCOs.

 Best Practice:  A Course Map page or graphic can be placed inside a dependent SCO or developed as a launchable asset.

There are several different design strategies for placement of the Course Map page in SCORM compliant courseware, listed as follows:

·        A Course Map may be included in the course as another separate, dependent SCO. Consideration must be given to the fact that this SCO requires the Student to launch the SCO and receive a "complete" lesson status.  Not opening this SCO would interfere with the Student completing the course because the lesson status would remain as "not attempted".  However, if it is mandatory that the Student access the Course Map and lesson status is needed to be tracked, then a separate dependent SCO would be reasonable.  If developed as a SCO, the course map cannot have any hyperlinks or it would violate a SCO golden rule.

·        The Course Map may be included in an existing dependent SCO such as an Introduction to the Course SCO containing a hyperlink to the course map or as actual pages within the dependent SCO.  Lesson status would be tracked in the context of the entire SCO and not specifically the Course Map.

·        As a launchable asset, the Course Map could be excluded from having any affect on the Student's completion of the course.  The Student may access the Course Map only if desired, and the Course Map would be available from the TOC.  The course map can be an html page with a graphic, but it still cannot link to SCOs.  A launchable asset does not communicate with the LMS. (RTE 3.2.1.1)  See the "Launchable Assets" Section for implementation information within the ILMS/ALMS.

3.11    Launchable Assets

3.11-1  BUSINESS RULE (ARMY):  Launchable assets will function properly only in the ALMS and must not be used in the ILMS.

For the ILMS:  Launchable assets do not function properly in the ILMS.  When loaded into the ILMS, launchable assets have an invalid associated lesson status.  Since the launchable asset does not have communication capabilities, it is impossible for the Student to obtain a completion status for this one activity in the course and the Student would not get credit for the course.

For the ALMS:  

 Best Practice:  For the ALMS, launchable assets can be used for the Student's convenience, which are available to be launched from the TOC when certain web pages are needed for viewing but Student completion progress does not need to be tracked.

An activity on the TOC can be developed as a launchable asset when Student tracking is unnecessary.  Instead of developing assets as a SCO, which requires communication and tracking within the LMS, a launchable asset may be the best recommendation.  (RTE 3.2.1.2)

A launchable asset is exactly the same as normal web pages containing text and/or graphics but launched from the TOC.  Within these assets, one file is the main entry point or launch file.  This entry point or launch file of the group of files has to be designated within a resource tag within the Manifest file.  The "scormtype" must be set to "asset".  Therefore, a launchable asset has a link from the TOC but links to launchable assets (assets with a launch point) and does not communicate with an LMS.

A use for a launchable asset, for example, is when an online calculator is needed by the Student during the learning experience.  The calculator could be a launchable asset from the Table of Contents and each SCO could have a hyperlink to the calculator web pages. Because the calculator web pages are not designed as a SCO with LMS communication, it is legal that they can also be used as "shared assets" within one or more SCOs.

Below is an example of XML code for a Launchable Asset contained within the Manifest:

 Figure 3.11a

The above launchable asset example shows the Course Map as an item in the <organization> (TOC) pointing to resources of type "asset" with an entry point or launch file into the group of assets (href).

3.12    Designing for Reusability

3.12-1     BUSINESS RULE (SCORM):  The reusability of a learning resource (SCO) depends on the SCO being independent and not tied to a particular aggregation.  A SCO must be able to stand-alone.  (CAM 2.1.1.3)

Reusability is one of the foundations for the SCORM specification.  Instructional designers and/or developers should keep this aspect in mind.  Each SCO should be able to be extracted from an existing course or selected from a SCO repository to be reused in another course structure.  There should be nothing within independent SCOs that is dependent on other SCOs or dependent on course context.

Eliminating context seems to cause confusion for the educational designers who are taught that each lesson must build on previous knowledge.   Therefore, the Army has developed the concept of independent and dependent SCOs as explained in the "Army Classification of SCOs" section.  Dependent SCOs would provide the transition for the Student to connect the context-free independent SCOs.

3.12-2  BUSINESS RULE (ARMY):  The Army requires the exclusion of transitional statements in independent SCOs such as "The next lesson will explain…"or” That topic will be discussed in the next lesson."  This type of verbiage does not fit into the context of SCORM reusability.

Be careful of actual verbiage within the learning content or audio of each lesson.  Refrain from including references to other lessons that follow or precede the current unit such as "Let us continue to the next lesson." or "In the next topic, you will learn…".

3.13    External References

 Best Practice:  External references should not link directly to the URL.

SCORM allows access to instructional content by URLs, although the Army has chosen not to recommend this method within Army courseware.  See the "Location of Independent SCO Files " section.  The Army allows external references that refer to non-instructional content.  This content is beyond what the course has control over.  External references could be used for ARs, Field Manuals, TRs, Pams, Regs, etc.

 Best Practice:  External references should link to a local redirect page.  This method would allow ease of maintenance and conversion.

For courses to be easily converted to CD-ROM stand alone courseware, all external references within the courseware should link to a local redirect page.  For the online web version, this redirect page will have the URL outside of the local domain.  For the courseware to be used from a CD-ROM, the external reference itself would be copied or downloaded and stored locally on the CD-ROM.  Programming code on this page will contain a statement directing the Student to either the URL for online or directing the Student to the local resources that are contained within the package.

The visual representation is as follows:

 Figure 3.13a

 

Editing the redirect page is less time intensive than editing the SCO within the authoring tool, which requires the original files.  Manual editing can easily occur on each redirect page by changing the URL to a local path.  The filename for the redirect page should easily identify that it is a URL redirect page for a specific web site, perhaps in a "redirect" folder.

A conditional programming statement can also be used.  Set an LMS variable as true in the top frame of the SCO for the LMS version.  Change the variable to false for the CD-ROM version.

An example of a conditional statement is as follows:

 Figure 3.13b

 

Building on this method could include one redirect page for all external references using a JavaScript function for multiple redirects.

Below is an example of multiple redirects using a single JavaScript function:

 Figure 3.13c

 

3.14    Prerequisites

The SCORM provides the ability to designate prerequisite SCOs within the Manifest that the Student must have completed prior to taking a certain SCO.  However, SCORM did not mandate that SCORM compliant LMSs support prerequisites.  See the "ADL Extensions to the Manifest" topic in the Packaging Section.

For the ILMS:

 Best Practice:  The SCORM method of designating prerequisite SCOs within the Manifest should not be used because it is not supported in the ILMS.

For the ALMS: 

 Best Practice: Prerequisites are not supported in the ALMS and should not be used.

3.15    Testing Strategy

Plan and develop your testing strategy early.  A well-defined testing strategy is imperative because of the impact on the playability of the SCORM courseware in the ILMS/ALMS.  Most importantly, one must consider that all SCOs (content and exam) in a package must rollup to a completion status in the LMS to get credit for a course.  How SCOs are designed will impact the Student obtaining completion.

Here are some items to consider which impact the playability of SCORM courseware in any LMS:

1. What is the level of testing?  Module level?  TLO level?
2. At what level do you plan to pretest?
3. Is the Student performance test for credit and will the Student's progress be tracked?
4. How many attempts does the Student have to pass the Student performance test?
5. After the Student performance testis passed, is the Student permitted re-entry to the test?
6. Can the Student go back to previous questions and skip questions?
7. Is the Student performance test "resumable" or "non-resumable" or have a time limit?
8. Can the Student retake the Student performance test immediately upon failure?
9. Is the Student performance test graded for GO/NO GO or is the actual numeric grade needed?
10. Does the Student need reach-back of the instructional content?  Unlimited or Restricted?
11. Will there be Student tracking for completion of the content or can the Student opt-out of the content?

Once the testing strategy has been developed, application can be made in the other areas of SCORM development.

3.15.1  Considerations

3.15.1.1   Pretests

There are two types of pretests:  Prerequisite pretests and Mastery pretests. 

·        Prerequisite pretest verifies the Student has the prerequisites, skills, knowledge, and competencies in which to continue the learning. Prerequisite pretests, if failed, would require the Student be denied access to the instructional content.

·        Mastery pretest is used to test the Student's prior mastery of the learning objectives for the purpose of "testing out" or reducing the objectives that must be mastered within the lesson/module/phase/course.

Prerequisite pretest functionality and mastery pretest functionality can be achieved but may be prohibited depending on design strategy and depending on the level at which pretests are presented to the Student.

It is assumed that the Student will only have one attempt to pass the pretest.  It will be accessible when the Student enters the SCO for the first time as determined by the entry status of "ab-initio".

For the ILMS:  Mastery Pretests developed as individual SCOs will not "test-out" the Student in the current version of the ILMS.  Therefore, there are several design options:

·        Combine pretest and content in one SCO.  If the Student has mastered this objective, then the Student has saved time by being able to test-out.  The Student proceeds with the other learning objectives and must take the post test.

·        Combine pretest, content and post test in one SCO with instructional logic inside the SCO.  For example, if the Pretest was "passed", the Student would be directed to exit the SCO and would receive credit for completion in the ILMS.  If the pretest was "failed", then the Student would automatically be directed to the instructional content and post test inside the SCO.  When the post test is "passed", the Student would receive credit.  Consideration would have to be given to length of instruction and would have to fit courseware guidelines.  This scenario would be viable for pretests occurring at the TLO level or lower.  Passing each SCO either with the pretest or post test will indicate that the Student has mastered the objective.

·        For pretests developed as a single SCO at the module or course level, the pretest would be set aside until implementation is supported.

·        Combine the pretest and post test(s) in one SCO with instructional logic using the entry status and/or lesson status in conditional programming statements coupled with storage of number of attempts in the ILMS.  This option would be viable at the module level or above.

Recommended SCO design applicable to pretests in the ILMS:

Figure 3.15.1.1a

For the ALMS: Mastery pretests developed as separate SCOs at the course or module level will test the Student out of content if contained in a single-SCO content package.  Other pretest design options as explained above are also supported.

Recommended SCO design applicable to pretests in the ALMS:

Figure 3.15.1.1b

*Content at TLO level or lower

 

3.15.1.2   Reach-Back

Reach-Back is a term used to indicate that the Student reaches back into or re-accesses the instructional content after the Student has completed a graded assessment.  Consideration must be given to Reach-Back in the design strategy.  Reach-Back would be determined by any Student performance test lock-out policies of an LMS, attempt limits through an LMS, SCO size or by the number of packages.  Restricting reach-back is also important for content that should not be readily available.  Understanding reach-back is important when packaging for the LMS.

For the ILMS:  If a graded assessment is embedded with the instructional content in the same SCO, then the Reach-Back may be prohibited depending on packaging strategy.  If the ILMS lock-out is applied, then reach-back is not available in the locked package.  If the ILMS lock-out is not applied, then instructional logic is needed to restrict access to each "passed" Student performance test within all SCOs in the package.

If Reach-Back capability and the actual Student performance test score are required, then the content and the Student performance test must be in separate SCOs (module level of testing) and in separate packages.  In this instance, the ILMS does support a mastery score where the Student score is compared with the mastery score and a GO/NO GO is determined. 

If Reach-Back and only pass/fail are required, then the content and the Student performance test could be in the same SCO (TLO/ELO level of testing) and contained in the same package.  Lesson status of "incomplete" when the Student fails the Student performance test is recommended to be sent to the ILMS.

At the module level of testing, the ILMS can support reach-back when pretest and content for a learning objective are developed as one SCO using instructional logic to provide access to the content and restrict access to the Student performance test.

Recommended SCO design applicable to reach-back in the ILMS:

Figure 3.15.1.2a

*Content at TLO level or lower

 

For the ALMS:  After completing a course, the course is retained in the Student's transcript (a linked history of all courses the Student has taken).  Use of the Transcript capability would allow the Student to review the course after completing the course Student performance test.  Tests can be excluded from the Transcript.

Recommended SCO design applicable to reach-back in the ALMS:

Figure 3.15.1.2b

*Content at TLO level or lower

 

 

3.15.1.3   Lock-Out Policies

Consideration should be given to the number of attempts for a post test and when the Student is denied re-entry.  If the Student has unlimited attempts until passed or the attempts are restricted, then this information is important for Packaging.  Also important is if the plan denies re-entry after successfully passing the Student performance test.  Testing at the TLO/ELO level can achieve lock-out within the SCO by using instructional logic to deny re-entry when passed.

For the ILMS:  A two-attempt lock-out can be automatically applied to any single-SCO package. A lock-out can be applied to any multi-SCO package at the point when all SCOs roll up complete in the ILMS. (A "failed" lesson status is considered completed to the ILMS. See the cmi.core.lesson_status section.)

A lock-out can be applied by the ILMS to a single-SCO package after the SCO is passed.  The ILMS reads the lesson status of "failed" as the first attempt and enables access for another attempt.  After the SCO is failed the second time, the lock-out is applied to the package. 

A lock-out can be automatically applied by the ILMS to any multi-SCO package once all SCOs are completed as determined by the lesson status data model.  The Army does not recommend using the lesson status of "failed" because the ILMS interprets it as "Student is done" and rolls it up as successfully completed. 

Recommended SCO design applicable to lock-out in the ILMS:

Figure 3.15.1.3a

 

For the ALMS:  Attempt limits can be applied when registering a package in the ALMS.

Recommended SCO design applicable to lock-out in the ALMS:

Figure 3.15.1.3b

 

3.15.1.4   Scores: Actual vs Averaged

The ILMS averages two or more scores within a content package and compares this "averaged" score with the minimum passing score.  If the Student is required to meet the minimum passing score on each Student performance test, then this method will not work.  The SCO itself can calculate pass/fail and not depend on the ILMS method.  Student performance tests requiring actual scores must be packaged separately as single-SCO packages.  Include this information in the testing strategy.

3.15.2  Testing Strategies

3.15.2.1   Content Completion Required / Student Performance Tests with Lock-out

This strategy insures the Student accesses and completes all content SCOs.  The Student has unlimited reach-back to content but is denied re-entry to the Student Performance test when passed.  By passing the pretest, the Student would "test-out".

For the ILMS:  The Student has two attempts to pass the module level Student Performance test.  The Student receives one or more versions of the test, which are randomly chosen from a maximum of five test packages.  Lock-out is automatic by the ILMS after Student has passed the Student performance test or two failed attempts.  Completion of all instructional content is required.  The mastery pretest SCO is not supported and would be excluded from the course.  It would be reintegrated when transferred to the ALMS.  See diagrams in Packaging section (7.3.1)

For the ALMS:  Lock-out is applied to the Student performance test SCO through the ALMS without additional SCO programming.  Completion of all instructional content is required.  Mastery Pretest is supported.

3.15.2.2   Content Completion Not Required / Student Performance Tests with Lock-out

This strategy gives the Student a choice to opt-out of the instructional content or to have the benefit of unrestricted access to the content.  The Student is denied re-entry to the Student performance test after passed.  By passing the pretest, the Student would "test-out".

For the ILMS:  The Student has two attempts to pass the Student performance test, which is randomly chosen from a maximum of five Student performance test packages.  Lock-out is automatic when Student has passed the Student performance test.  Mastery pretest via the post test is supported in this strategy.  The post test can function as a pretest for the Student since the Student is not required to complete the optional instructional content.  The pretest SCO would be set aside until supported.  See diagrams in Packaging section (7.3.2).

For the ALMS:  Pretest SCO is supported.  Student performance test SCO lock-out is applied by the ALMS without additional SCO programming. 

3.15.2.3   Content Completion Required / Student Performance Tests with Internal Testing Logic

This strategy insures that the Student accesses and completes all content SCOs.  Since the Student has unlimited attempts to pass the Student performance test, it could be compromised.  Student lock-out is required when the Student has passed the Student performance test.  If developed as an embedded test, then additional SCO programming is required to deny re-entry.  Lock-out by the LMS can be applied to a single-SCO Student performance test package.  Student has reach-back capability.

For the ILMS:  The Student has unlimited attempts to pass the Student performance test.  At the module level of testing, the Student receives one or more versions of the Student performance test, which is randomly chosen from a maximum of five Student performance test packages.  At the TLO/ELO level of testing, the test would send only two lesson status vocabulary values of "passed" and "incomplete".  If a mastery pretest SCO exists, it would not function properly for a Student to test-out of content.  This pretest SCO is excluded from the course but is included when transferred to the ALMS.  See diagrams in Packaging section (7.3.3)

For the ALMS:  The Student has unlimited attempts to pass the module level Student performance test.  Lock-out can be applied by the ALMS to restrict access when passed.  Mastery pretest is supported.

3.15.2.4    Read-Ahead Packages (No Student Performance Tests) Content Completion Not Required

This strategy consists of content for information only but there is no tracking of student progress.  The Student has unlimited access and there is no Student performance test.  See diagrams in Packaging section (7.3.4)

3.15.2.5   Read-Ahead Packages (No Student Performance Tests) Content Completion Required

This strategy consists of the tracking of student progress.  All SCOs must be accessed and completed by the Student.  The Student has unlimited access.  This strategy does not require a Student performance test.  See diagrams in Packaging section (7.3.5)

 

 

4         Communication with the LMS (Run-Time Environment)

A goal of the SCORM is that learning resources be reusable and interoperable across multiple LMS.  For this to be possible, there must be a common way to start learning resources, a common mechanism for learning resources to communicate with an LMS, and a predefined language or vocabulary forming the basis of the communication.  As illustrated below, these three aspects of the RTE are Launch, API and Data Model. (RTE 3.1)

Figure 4.0 a

 

This environment is called the "Run-Time Environment".  JavaScript is the programming language necessary for implementing RTE API function calls to the LMS.  The following examines SCORM Run-Time Execution State Commands, State Management, and Data Transfer Commands.

4-1     BUSINESS RULE (SCORM): Every SCO is required to adhere to the SCORM Run-Time Environment. This implies that it must have a means to locate an LMS's API Adapter and must contain the minimum API calls of LMSInitialize and LMSFinish.  (CAM 2.1.1.2)

 Best Practice:  The JavaScript file entitled "APIWrapper.js" provided by ADL is recommended to be used in the development of courseware.  This file incorporates state management diagnostic functions to handle errors.  Using this file would mean that adding error handling routines to the programming code would be unnecessary.  APIWrapper.js file can be obtained by emailing the contact email address and requesting the file. 

NOTE:  All of the programming code examples assume use of the API Wrapper file developed by ADL.  Programming subroutines may begin with a similar name but has different parameters.  It is the responsibility to make sure to use the APIWrapper function calls if using the APIWrapper.js file or, if not, use the exact SCORM API function calls as designated in the SCORM specification.  If not using the APIWrapper file, the developer would replace each function name listed below with the actual SCORM specification API function call.  For example, the APIWrapper function call is "LMSInitialize()" within this document, and the SCORM specification API function call is "LMSInitialize("")."  Please be aware there are several versions of the APIWrapper file.

 

Figure 4.0b

 

Also, due to the fact that the API Wrapper file already contains LMSGetLastError error handling routines with each function call, there is no further need to assess error conditions repeating the API function call of LMSGetLastError.  All of the examples assume use of the APIWrapper.js file.

4.1        LMSInitialize

4.1-1  BUSINESS RULE (SCORM):  LMSInitialize is a mandatory SCORM API function call for all SCOs.  LMSInitialize indicates that the SCO is ready to begin communication with the LMS.  (RTE 3.3.2.1)

Figure 4.1a

It is the responsibility of the SCO to initiate communication with the LMS by sending an LMSInitialize API function call, which means "I'm ready to talk".

 Best Practice:  LMSInitialize should not be called from the onLoad event on the first page of the SCO.  Errors will result when clicking the back button on the second page. 

To avoid this error, a "SCO Start" (redirect) page has been suggested that separately calls LMSInitialize.  This page is placed as the launch page of the SCO.  It will call LMS Initialize and then immediately will redirect the Student to the first "real" page of the SCO.  All that is required is changing the href of the anchor tag on the "SCO Start" page to the redirected real first page of SCO.  If this method is used, LMSInitialize should only be called on the "SCO Start" page.

Sample code for the sco start page is as follows:

 Figure 4.1b

4.2        LMSFinish

4.2-1  BUSINESS RULE (SCORM): LMSFinish is mandatory for all SCOs.  LMSFinish indicates that the SCO no longer needs to communicate with the LMS.  It must be called when the Student is leaving the SCO. (RTE 3.3.2.1)

 Figure 4.2a

 

LMSFinish should not be called on a page event (onUnload, etc.) on the last page.  An error will occur when the Student, while on the last page, goes back to the previous page.  A user event is required to call LMSFinish.

4.2-2  BUSINESS RULE (ARMY):  LMSFinish must be called when the Student closes the SCO by clicking on the X and closing the browser window instead of the appropriate navigation button to exit the SCO.

The Student may close the browser window by clicking on the "X" on the upper right side of the browser window.  When this happens, the SCO is closed incorrectly and LMSFinish is not called and any data still outstanding will not be saved.  Therefore, the SCO can be programmed to call LMSFinish should this occur. 

 Best Practice:  The following code will detect when the cursor is clicked outside of the page area and will execute right before the page unloads.  This code determines the position of the cursor when it was clicked and, if the cursor was clicked outside of the page area, then LMSFinish is called. 

There are two solutions presented below:  1) a "no-frames" solution, then, 2) a "frames" solution.

No-Frame Solution:

Below is an example of how clicking on the Exit button and clicking the X to close the browser will execute the exitSCO function and call LMSFinish.

Figure 4.2b

Below is the solution for a frameset, which places the exit code on the other frame instead of the frame containing the instructional content.  This means that only when the browser window is closed will the other unload events be executed.  When navigating through the courseware pages, the data storage page still remains active.  The data storage page is the best candidate for the location of the LMSFinish.  For example, a frameset contains two pages: the data storage page and the courseware content page.  Closing the browser window by clicking on the X will cause the unload event to execute for the entire frameset and LMSFinish would be called.  LMSFinish, which would normally be called when the Student clicks on the Exit button, can be replaced with a parent.close because LMSFinish will be called from the data storage page.  Clicking the Exit button or closing the browser window by clicking on the X would execute the unload event from the Data Storage Page.

Using the above frameset scenario, an example of a frameset page (frame.html) is shown below: