Determining scope

We began with a very basic, "bare-bones" integration between Docent and the SCORM Engine, to see what might be missing from the three main SCORM touch-points: course import, course delivery, and viewing results in the LMS.  

Course Import

The course creation workflow necessarily straddles both systems. Importing a SCORM package creates an entry in the Rustici Scorm Package table, and also populates certain Docent course properties with some of the information from the SCORM manifest. So our process creates an empty "temp" course in Docent, and then waits for the import to complete to finalize it.

Rustici's import page was inserted into Docent's SCORM course creation process. Starting in Docent, an instructional designer clicks "Create a new course" and selects SCORM as the type. This creates a temporary, empty shell of a course and prompts the ID to import the manifest. Once the course is imported, the Course Code and Title are populated from the manifest, and then all the Docent-specific properties are finished manually.

Problem area: Manifests
We knew from the beginning that many of the SCORM manifests we had been using were incomplete and not 100% conformant. The Docent LMS was very forgiving, and would accept and use flawed manifests. And as well, there are many elements inthe scorm specification that we simply don't need. So the same manifest would often do just fine for multiple courses. We could change the launch link, course code and title within the LMS after import. We knew we'd have to create distinct and confomant manifests for all 700+ courses before importing them into the new system.

What we did to fix it: 

For one-time use during the migration to the SCORM Engine, our Docent consultant  created a spreadsheet that generated then imported clean manifests for all existing SCORM courses in two clicks.  

For manifest creation after the migration, we created a "simple manifest maker" that generates a valid SCORM 1.2 manifest for a course of any number of SCOs, and drops it right into the course folder on the webserver. From there, it can be uploaded using the standard Rustici import control. We leave our courses out on a web server rather than zipping them and storing them "in" the LMS.

Uploading zipped SCORM packages never made much sense in our environment: besides the fact that the instant a course is uploaded, in our experience the instant a course is uploaded, someone inevitably discovers a typo or wants a revision, and it has to be re-uploaded. Also, there's no business reason for restricting access to most of our courses, so we make them accessible and searchable on the corporate intranet. Specific course pages can be accessed directly from the search results, as part of our reasoning that if the course was worth looking at once, it's probably worth using again as reference. Only the quizzes are hidden unless there is a SCORM API present.

Problem area: Settings management and the lack of retroactively alterable presets

Once it is imported, Rustici provides hundreds of settings which improve the compatibility of just about any type of SCORM course, and can also alter its behavior and navigational controls.In the basic integration there was no specified way to manage or change these settings. We decided to use a copy of the Noddy LMS settings page as our interface. This interface also allows you to create presets from a group of settings, which can then be applied to other courses at the click of a button. But there was no way to change the settings across all courses that had had a certain preset applied to them.  The preset was not stored with the course, just the settings. To change presets on a group of courses it would be necessary to go into each course and apply a new preset.

There are hundreds of settings, and each type of course (1-SCO unscored, Multi-SCO scored, Captivate, etc.) uses a very specific combination of them.  We currently only use about 6 or 7 different presets at the moment, but eventually it may grow into 10-15 types as we devise new course structures or purchase new course creation software. Over time we expect to change some settings for specific course types as we learn more about what works best. 

What we did to fix it: 

We decided to create a method of storing the settings preset with the course by classifying courses, so they could be changed as a group when necessary. We call these settings presets "course categories."

The Rustici settings interface:

A Course Category can be any set of courses different enough to warrant using its own set of settings for any reason. The criteria distinguishing these groups of courses can be structural:   e.g. "1-SCO Unscored course" or "Multi-SCO Scored course",  or vendor-specific: e.g. "Articulate" or "Adobe Presenter".

Course categories are added by making a new "template course" which has applied to it the settings required by the new type of course. Template courses are flagged in such a way that they are recognized as category templates by the system. Each new SCORM course must have a category applied to it before it is saved the first time.

Category menu:

After applying a Category template, settings can be altered on an individual course, and if necessary, the course can be held out from future settings updates associated with its template.

If at some point the settings associated with a course category need to change, they are simply altered on the appropriate template course, tested, then a database query reapplies the new settings to all courses of that type.

Problem area: no way to edit SCORM data without reimporting manifests.

Docent had a convenient interface for editing some SCORM 1.2 properties such as main launch link, SCO titles and mastery scores right in the LMS without needing to re-import. There was  no way to make quick edits like that in Rustici's system without re-importing the course. There are times the launch link for a SCO or mastery score needs to change and we don't want to   import a new version of the course. 

What we did to fix it:

We created an interface in the Docent course editing area that allows us to alter certain SCORM properties for each SCO of each version of the course.  This allows quick fixes to mastery scores, SCO titles and launch links. Re-importing a course creates a new version, and we found it necessary to configure the SCORM Engine to only show that version to users who are newly enrolled. If a user is already enrolled for the course they will not see the new version. So for many reasons we prefer to use this interface for certain changes.

Each version is listed separately, with an editable launch link.

Drilling down into each version displays editable fields for SCO titles, launch links, mastery scores and other data.

Next: Course Delivery >>