In general, we knew that the existing Docent course-enrollment and launch workflow was inefficient and frustrating to the user. When there is a choice, we usually have a preference for shorter paths to the user's desired target, and decided to take this opportunity to try to approach a 1-page workflow.

For the "bare-bones" integration phase, the only thing that was changed in the course-delivery workflow was the function of the green Launch button to the right of each course.

The course Launch button enrolls the user and launches the course when they are not already enrolled, or simply launches the course when the user is already enrolled. 

In the original Docent workflow, clicking Launch used to open a second page - the "SCO-tree" page - which listed the sections or SCOs of the course, with corresponding Enter the Lesson buttons. We'd always considered that second page to be an unnecessary step, although the information it conveys is useful to the user. Besides adding to page-load time, another drawback of this page was that it was only viewable while the course was in progress. Once the course was completed, only summary course status and score were accessible to the user.

The old SCO-tree page

In the bare-bones integration phase, the Launch buttons on the Learning Plan were altered to open the course window directly, without first navigating to the SCO-tree page, in keeping with our desire to reduce clicks and page-loads as much as possible.

The new Launch button opens the course directly.


Problem area #1: individual SCOs' score and status were missing from the user's view.

When testing the bare-bones workflow, we realized that although launching the course directly from the Learning Plan was quicker, we had lost necessary information about the status and score of each SCO. The Learning Plan does display summary status and score information for each course, but no internal detail. 

We considered using the Rustici-provided SCORM-tree navigation to provide some of the missing information.  If enabled, a navigation panel displays complete/incomplete status for each SCO. However this feature was rejected as an insufficient solution because it does not display scores, the information is not available once the course is closed, and also because our usability specialists thought it was confusing, redundant and took up too much screen real-estate.

Problem area #2: no way to jump directly into a specific section.

Many of our courses are one-sco courses with detailed Tables of Contents, allowing the user full control over how to navigate the course. But there ARE some multiple-sco courses, and now there was now no way to navigate directly to a specific SCO. 

What we did to fix both problems:

We created a "SCORM-Tree" display on the Learning Plan, right under each course title. This displays each SCO in the course, with accompanying score and status and a corresponding "Open" button that jumps the user into that SCO. Although it is possible in SCORM 2004 to force sequential order between SCOs, and thus conflict with providing automatic "Open" buttons to each SCO, we have never used SCORM 2004 on any courses, and are unlikely to do so before migrating to another LMS, if at all, so we did not provide any logic to shut off the "open" buttons for that use case. 

Courses which require special sequencing are typically created within a single monolithic SCO in our environment. We decided the benefits of providing this type of display outweighed any possible conflicts with sequenced courses.

A five-SCO course, with the SCORM-Tree open.

When the Learning plan Loads, all SCORM-Trees are closed, to keep the view as clean as possible.  

A tiny toggle beside each course opens the SCORM-Tree.

There are two ways to open the SCORM-Tree. The user can open it manually by clicking the little triangles to the left of each course title. The tree also opens automatically when the course is launched. On closing the course window, the data is automatically refreshed via ajax. 

The SCORM-Tree display is designed to work whether or not the user notices the little toggle triangles. They were kept small to avoid cluttering up the screen with more controls.

The SCORM-Tree draws its data directly from the SCORM Engine database, so it is always as accurate and up-to-date as possible.

Problem area: SCORM Tree not always updated automatically

The course window "Close" event is not always captured for various reasons, so the SCORM Tree sometimes does not update automatically.

What we did to fix it: 

The first step was to provide a fall-back, so the user would be prompted to manually update the SCORM-Tree data. 

When the course launches, the SCORM-Tree opens if it is not open already, and shows the message "Statuses shown below may be old. Please click to update!" When the user responds by clicking the yellow bar, the Tree updates via Ajax.

Since the course window opens on top of the Learning Plan window, if the course window is closed correctly, the user will never see this message because it disappears when the course rolls up. But, if the user closes the window too abruptly for the rollup to occur, they will see the "please update" message. 

The second step will be to address the root cause of the failure to capture the window close event, and we are currently working on improving reliability and optimizing the steps that happen on return from the course.

Problem area: inconsistent launch behavior between use cases: 

Launching a course from the catalog, from the learning plan, when enrolling first, or in already-enrolled courses each behaved slightly differently. We wanted the user not to have to guess or even understand the differences - there should be no thinking involved, and there should be fallbacks whenever user mistakes were possible.

What we did to fix it: 

Every possible method of enrolling or launching was tested, and the desired workflow diagrammed, developed and tested again to make sure it was as consistent and streamlined as possible. It turned out to be so intuitive that users needed no instruction on the changes when the SCORM Engine launched. 

We did discover usability problems with our courses in the process, which are as important as fixing problems in the LMS, since to the user, they are the same thing.

Problem area: Course opens in multiple windows accidentally or intentionally

Users sometimes double-click the Launch button and open two intances of a course, one window right on top of another. To the SCORM Engine, these represent two attempts. If the user completes the course in the top window, it closes, and then they see the other window. When they try to close the second window, it checks to see if the course status is complete or not, then finds that it is NOT, because it is checking a cached copy of the status created when it opened. So it resets the status to "incomplete" and exits with "Suspend".

Under Docent's SCORM control, if users accidentally opened a second window it would not reset, because the course was checking the "real" status in the database.

What we did to fix it: A function was added to the launch button that hides the launch button on the first click, and replaces it with a little "loading" spinner. After a second, the launch button returns, but this prevents double-clicks and so prevents at least some of the causes of double-windows. 

It was also determined that if a user opens a course, then right-clicks and opens one of its pages in a new tab, it does not register as a second attempt, and so the statuses are accurate on both pages.

Problem area: Learning modules not entirely conformant to the SCORM standard

Rustici's settings will compensate for nearly any type of course setup, but we found some issues that had to be fixed in the courses. One was that when a scored SCO was closed abruptly before getting to the quiz, it would simply complete. This had never been an issue before, but setting a score of 0 immediately upon course-load fixed it. 

Problem area: Learning modules had some Docent-specific code in them

Docent had provided some special javascript extensions to the SCORM standard that allowed the user to jump between SCOS right from buttons inside the course. We used this both for branching and for giving the user more navigational control on a few courses. Another javascript extension allowed the course to check if there were any more SCOs. We had used this to change the options available to the user at the end of the course depending on if the SCO was a middle or the last one. 

Both these extensions are non-standard and had to be removed from all courses.

What we did to fix it: 

Our courses are all linked to a master template containing the scripts and assets, so we simply removed these functions from the master template. 

Problem area: Use of Suspend mode much more important now than under Docent's SCORM control. 

Under Docent, simply closing a course without explicitly Completing it would cause it to retain an Incomplete status. Our courses regularly saved Objective and Interaction data, so as long as the course status behaved correctly we didn't worry about using Suspend every time it should have been used. Under the SCORM Engine, an incomplete SCO would often be marked Failed or Completed when closed, if it were not exited correctly with "Suspend."

What we did to fix it: Logic that incorporates the Suspend function where appropriate has been added to all possible ways to exit the course.  We added code that auto-generates correctly coded exit or suspend buttons in the course's internal navigation bar, depending on what the overall course structure is, whether the current sco is a middle or last sco, whether the course is scored or not, and what the contents of the next sco are. Functions can be added or changed on the buttons from a single central script.  

Instructional designers put a code into the config file for each SCO that represents the type of learning module it is, and thus the SCORM buttons that are required, and can optionally override the automatic text for each buttons for custom situations.

Course Rollup and Reporting

Problem area: Summary statuses don't match expected results based on SCO statuses.

Docent's summary statuses did not always match what we expected given the individual SCO statuses. For example, we would expect the overall status to be "In Progress" as soon as any individual SCO status was set to Incomplete, or left In Progress if a 1-SCO course was Failed.  These summary statuses are controlled by the interface between the SCORM Engine and the LMS, and are determined by a combination of the overall completion status and success status for the course, which are controlled by the Rustici settings panel. Some of our initial guesses about the business rules for setting these values in Docent needed to be revised. 

We created a matrix of statuses to guide those revisions, and I suspect that we'll be changing some of these again as we discover new special cases. 

Problem area: Remote completion data not available to the SCORM Engine, causing conflicts.

There are a few situations where we have devised custom interfaces to complete the course remotely, from the back-end, outside a SCORM session. These interfaces include one that allows a training coordinator to manually complete a SCORM course for the student for whatever reason, and one that allows a remote application to enroll and complete a course. 

These have caused various types of conflicts between systems, because the SCORM Engine is not aware of changes on the Docent side, and its data becomes out of sync with the Docent data. Worse, if a user opens a course which has been completed on the Docent side, Rustici is not aware of the completed status, and will "Un-Complete" the course by sending an "Incomplete" through the interface because there are no business rules to prevent that yet.  

What we did to fix it:

We're still debating exactly how to handle each of these situations, but I suspect that we will use TinCan for remote completions in the future, and perhaps add a trigger to the Training Coordinator manual course-completer function so that it also updates the SCORM Engine tables. Rustici also suggested adding a "rachet-upward-only" rule to the Interface between systems to prevent overwriting any Docent status with a lower status, which we will probably do.

Problem area: Transcript view of a course was now inconsistent with the one on the Learning Plan.

Once a course was completed, the Docent view of a course on the user's transcript had never included per-SCO statuses and scores, but now that users had the SCORM-Tree on the Learning Plan, we found in testing we wanted to see it on the Transcript page as well.

What we did to fix it:

We added a modified version of the SCORM-Tree to the Transcript page. It shows a "frozen" view of the interior statuses of the course, with no update function and no "Open" buttons.

Problem area: No visual confirmation of course completion

On course completion, the standard Docent behavior was to move the course off the Learning Plan onto the Transcript page. In the basic integration, this would happen without any explanation, so that the user would not necessarily understand why the course had vanished from the Learning Plan, and needed reassurance that the course was indeed complete.

What we did to fix it: At first we considered redirecting the user to the transcript page upon course completion but that did not fit the one-page workflow concept. Instead, when the course window closes, and the SCORM-Tree is automatically updated, if the summary status changes to Completed or Passed, a completion message is displayed that that waits for a user response to move the course off the page. 

A successful launch:

Despite various challenges, this integration project has completely eliminated java-related problems with launching and tracking courses for us. It has also made the LMS compatible with iPads and the new VPN system, as well as with types of courses that never worked well previously. 

The user interface and workflow surrounding enrollment and launching online courses has also been streamlined and shortened. However during testing, we uncovered usability problems in the courses themselves, that will take longer to fix. 

Next steps: 

Integrations with Drupal or WordPress, more Mobile content: We are currently implementing Rustici's TinCan upgrade and hope to use it to facilitate integrations with various blogging platforms and the ability to provide better mobile and disconnected content. 

The Vanishing LMS: One of our goals is to make the LMS "disappear" when not needed - which is most of the time. For most users, there is no compelling reason to log into a special website to take a course. While integrating the SCORM Engine, we added capabiliities that will allow users to enroll in and launch a course in one step, directly from an emailed or posted link and receive whatever confirmations they need right from the course window.