Introducing the Golf Examples
The Golf Examples are a set of simple SCORM courses that illustrate the technical principles of SCORM. The examples start with a set of basic HTML pages that contain instructional information about the game of golf. The instructional content is mediocre at best (it’s just text pulled from Wikipedia and Wikihow), but that’s not the point. These examples are about the technical guts of SCORM. The examples start simple and then build on each other to create a fully functional SCORM conformant course. Examples are provided in different versions of the standards as needed. For example, the simple content packaging examples are provided for all versions of SCORM so that they can be used as templates. However later examples, which build on the previous examples are only provided in limited versions because the differences between versions are negligible.
Content Packaging Examples
These first examples demonstrate the content packaging aspect of SCORM. They are not intended to be fully functional courses, rather they simply demonstrate the proper way to create an imsmanifest.xml file, add metadata and package the course.
Simple Single SCO
This example demonstrates the most basic content package. It simply considers all of the files within the course to be part of a single SCO that is listed in the manifest and packaged up. This example is provided for all versions of SCORM. They are useful as templates for creating more complicated manifests for each standard. Notice the differences in the SCORM manifests for each SCORM version:
- The XML name space information (xmlns) in the manifest tag is different for each SCORM version. These differences are related to the XML schema definition files that are included with each course.
- The schema and schema version elements in the manifest’s metadata tag have different values in each version of the standard. In SCORM 2004, these values are required to have specific values.
- The adlcp:scormType attribute on the resource element is slightly different between SCORM 1.2 and SCORM 2004. In SCORM 1.2, the attribute is named “adlcp:scormtype”, whereas in SCORM 2004, the attribute is named “adlcp:scormType” (note the case of the letter “T”).
- SCORM 1.1 uses a completely different content packaging format known as “content structure format” or “CSF”.
When more than one HTML page is part of a SCO, the SCO is responsible for providing the navigation interface for navigation within the SCO. This example is missing that navigation, it will be added later in the run-time examples.
The Metadata Example
The example builds upon the Simple Single SCO example by adding descriptive metadata to the manifest file. Every metadata element within LOM is used in an appropriate context. Metadata may be defined at many levels within the manifest. It can be attached to the manifest itself, an organization, an item, a resource or a file. This example demonstrates metadata in all locations. Metadata can also be included directly within the manifest (in-line) or in a separate external file referenced from within the manifest. Both methods of defining metadata are included in this example.
Multi-SCO Example (One Page Per SCO)
In this example, each HTML file is treated as a separate SCO. The SCOs are aggregated into four items that represent the different topics covered within the course. Some things to notice in this example:
- Use of aggregations to form a logical course hierarchy.
- Use of the parameters attribute to pass querystring parameters into the shared quiz resource.
- The use of resources typed as assets instead of SCOs because they do not communicate with the LMS.
- The use of a common shared asset containing files that are reused across many SCOs. This asset is referenced through dependencies on the other resources.
Since this example relies on the LMS for navigation, it is the first functional example that can be launched and run in an LMS. To be a complete and fully-functional course, it still needs some more work. That will come later. For now, try importing it into the SCORM Cloud to see how it looks.
These examples demonstrate the addition of SCORM run-time calls to the prior examples.
Minimum Run-Time Calls
This example builds on the Multi-SCO Example (One Page Per SCO) to demonstrate the minimal required SCORM API calls. In this example:
- All of the resources are marked as SCOs instead of Assets because they communicate with the LMS.
- Each SCO will locate the SCORM API using the ADL-provided API discovery algorithm.
- The SCOs simply call Initialize when they load and Terminate when they unload.
- The run-time calls demonstrate basic SCORM error handling.
Basic Run-Time Calls
This example builds on the Simple Single SCO to demonstrate the proper use of the basic SCORM run-time data model elements. In this example:
- The controller bookmarks the learner’s current location. (cmi.location)
- The controller reports completion as the user progresses through the content. (cmi.completion_status)
- The controller reports success status and score based on the learner’s quiz results (cmi.success_status, cmi.score.scaled, cmi.score.raw, cmi.score, max and cmi.score.min).
- The controller will record the total time the learner spent in the training (cmi.session_time).
- The controller demonstrates options for exiting the course (cmi.exit and adl.nav.request)
- The manifest includes some basic sequencing information to override some counter-intuitive default values.
Advanced Run-Time Calls
This example builds on the Basic Run-Time Calls example to show more in-depth use of the SCORM run-time data model elements. Specifically, this example:
- Defines four specific learning objectives for this course.
- Reports individual question results (cmi.interactions).
- Associates question results with learning objectives (cmi.interactions.n.objectives).
- Reports the learner’s progress towards completing each learning objective (cmi.objectives.n.progress_measure and cmi.objectives.n.completion_status).
- Breaks down the test results into results for each learning objective (cmi.objectives.score).
- Records the learner’s progress towards completion of the SCO (cmi.progress_measure).
- Defines the passing score in the manifest rather than hard coding it within the SCO.
- Demonstrates how to work with SCORM sequencing collections.
These examples demonstrate the use of sequencing and navigation to combine the golf content into sequenced courses. Several common and simple sequencing strategies are demonstrated. These examples demonstrate both the sequencing of the learner through the content as well as strategies for rollup of status information.
Forced Sequential Order (Prerequisites)
This example demonstrates a sequencing strategy that requires the learner to visit all SCOs in order. Once a SCO has been visited, the learner can jump backwards to review material, but the learner cannot jump ahead until the prerequisites are met.
- Completion: All activities must be completed for the course to be completed.
- Satisfaction: All activities must be satisfied for the course to be satisfied. Activities without an assessment are satisfied when they are completed. Activities with an assessment measure satisfaction based on the outcome of the assessment.
- Score: No score is rolled up, all activities have an objective measure weight of zero.
- The use of a sequencing collection to define sequencing rules that are common to every activity.
- The use of global objectives to track satisfaction of learning objectives (which are also the prerequisites).
- The sometimes counter-intuitive use of the “not” operator.
- The use of precondition sequencing rules to disable activities until their prerequisites are met.
Post Test Rollup
This example maintains the sequencing strategy from the Forced Sequential Order example. All SCOs must be visited in order initially, but once a SCO is completed, the learner may jump back to it at any time.
The course can only be completed and satisfied by completing and satisfying the post test. Because of the sequencing strategy that requires all other activities to be completed before the post test can be accessed, by implication, all activities must be completed for the course to be completed. The score for the course is entirely defendant on the score from the post test. This rollup strategy is implemented by setting every activity except for the post test to not contribute to any rollup. When there is only one activity that contributes to rollup in a cluster, then cluster will receive that activity’s status by default during rollup.
SCORM 2004 4th Edition Features
This example demonstrates some of the powerful new features available in SCORM 2004 4th Edition:
This example maintains the sequencing strategy from the Forced Sequential Order and Post Test Rollup examples. All SCOs must be visited in order initially, but once a SCO is completed, the learner may jump back to it at any time.
- To demonstrate the new 4th Edition “jump” navigation request, the learner can now skip straight to the test at anytime from within a SCO, bypassing all sequencing rules. If the learner is taking the content though, it still must be taken in order.
- To demonstrate the additional data that can be stored on global objectives, this example uses completion status as the driver for prerequisites. In prior editions of SCORM 2004, only success status was available on global objectives. In this case, we simply need the learner to complete the SCO not necessarily satisfy it.
- This example maintains the rollup strategy from the Forced Sequential Order and Post Test Rollup examples. It still works even though the sequencing strategy now allows for jump request because the rollup is entirely dependent on the post test.
- To demonstrate the new rollup of progress measure, this example now includes weights on each SCO that represent their overall contribution to completion.
- To demonstrate the value of the new shared data buckets in 4th Edition, we added a notes feature that allows the learner to take brief notes and have them be available in any SCO.
Pretest or Post Test Rollup (Testing out)
- The learner can freely navigate through all activities in the course.
- The pretest can only be attempted one time.
- Once any test is passed, all tests are disabled.
- The post test can not be attempted until all content is completed.
- Completion, satisfaction and score are all tied to the most recently completed test.
- The learner can “test out” by completing the pretest.
- If the learner doesn’t test out, achieving completion requires completing all SCOs. This is done implicitly by putting in sequencing rules that don’t allow another test to be taken until all SCOs are completed.
- The use of an invisible dummy clusters to simplify sequencing and rollup rules.
- The use of the attempt limit sequencing attribute in conjunction with a precondition rule to disable the pretest after one attempt. Note how this requires setting cmi.exit to normal instead of suspend to end the attempt.
- The use of a global objective shared between the pre and post tests to record satisfaction and score.
Randomized Testing (Test/Question Banking)
- Content can be taken in any order.
- The post test can not be accessed until all of the content is completed.
- The post test is actually a test bank of 4 possible tests.
- On each new attempt of the post test, one of the possible tests is randomly selected.
- The learner gets two attempts to pass the post test.
- After the first failed test attempt, the learner immediately retries the test.
- Once the post test has been passed or attempted twice, the learner immediately exits.
- Overall course status is determined solely by the status of the post test.
- The post test cluster is the only activity that contributes to completion and satisfaction rollup. The post test cluster’s status is determined by rollup rules that say if any of the tests are satisfied, it is satisfied and completed.
- Overall course score is read from a global objective (since we can’t set the score for the post test cluster using a rollup rule). The score of the last test attempted is the score for the course.
- The retry post condition on the post test cluster to try another test after failing.
- The two separate retry rules on the post test cluster to achieve the logic (not satisfied AND not attempt limit exceeded) OR (unknown satisfaction AND not attempt limit exceeded). Combining AND and OR conditions requires separate rules.
- The exitAll rule to exit the course once the post test has been satisfied or the attempt limit has been reached.
- Randomization controls to randomly select a new test.
- The exitParent rule on each individual test to ensure that the post test cluster’s post condition sequencing rules are evaluated whenever a test is completed.
- The use of hideLMSUI to ensure that a test is not exited with a suspendAll request. A suspendAll when the test is still active will prevent the attempt count on the Post Test aggregation from being incremented.
- Only flow navigation is allowed.
- There are four learning objectives for this course. For each learning object, there is an associated content SCO and a test SCO.
- Passing a test will satisfy the associated learning objective.
- When a learning objective is satisfied, both the associated content SCO and test SCO are skipped.
- When the learner completes the course without satisfying all learning objectives, he is remediated back through the course but skips all content/test that have already been mastered.
- Only the tests count towards rollup.
- Each test counts equally towards all rollup metrics.
- The dummy wrapper around the content to enable retry with retrying the root activity which would reset all of the global objective data.
- The use of control choice exit on the retry wrapper to prevent access to choice requests on the root activity (which would begin a new attempt and reset data).
- The rollup consideration of ifNotSkipped to ensure that tests that are skipped during remediation don’t affect overall completion status. (Satisfaction and measure aren’t an issue because these are stored in the global objectives which are not reset.)
- For more information about this sequencing strategy, see these blog posts: