At the end of the SCO: To close or not to close
The problem with closing
You created a wonderful SCORM conformant content object, what in SCORM-speak is called a SCO. Now you run it in a learning management system—a LMS in SCORM-speak. This particular LMS opens a new window and plays your content object in it. All is well until the learner reaches the end of your SCO. But now it just sits there, even though the learner should no longer be able to do anything with it. The situation is confusing. You would like to make your content object go away automatically, but it won't. You would at least like to be able to program your content object to close the window automatically, but for some reason that doesn't work.
Perils of closing the window
There are two ways for a LMS to launch a SCO: In a frame or in a popup window. If the SCO is launched in a popup window, it "owns" the window and therefore it can close it safely. But if the SCO is launched in a frame, it does not own the context of the frame. The frame will be either part of a frameset or an iframe in a web page. This frame context is part of the runtime environment provided by the LMS. If the SCO closes the browser window that contains that part of the runtime environment, this can have nasty consequences. Tracking data may be lost because the runtime environment may not have time to save the data. If the frame is part of the main interface for the LMS, closing down the window effectively throws the user out of the LMS, which is probably not a good user experience.
The bucking windows experience
Have you ever watched a rodeo? A door open, a bursts onto the arena bucking wildly with a cow person on top hanging on for dear life, and in a few seconds the show is over. The arena is cleared, and then the next horse bursts onto the arena with a different cow person, bucks wildly for a few seconds, and then the show is over again. In a sequencing scenario, popping up and closing a window for every activity may be a rather jarring experience for the learner, especially if the activities are short. Every time the user chooses to continue to the next activity, the window for one activity closes and then another one bursts onto the screen for the next activity. This annoying behavior can be avoided in a LMS by using a frameset with a "stage" frame in which the SCOs are played one after the other. However, a number of LMS implementers still use a simple popup approach. Technically, there is nothing wrong with that. In fact, there is currently no defined standard that specifies how to provide a seamless experience in a single window. So far the closest approximation of such a seamless experience is with LMS implementations that play the SCOs in a frameset in a window that stays open throughout the sequencing session.
To close or not to close, that is the question
We saw that if the runtime environment creates a popup window to run the SCO and launches the SCO directly in that popup window, the SCO "owns" the window and it can safely close it when it finishes. In fact, this is often the expected behavior. If the runtime environment launches the SCO in a frame, the SCO is not allowed to close the window that contains that frame. So the simple answer to the question whether to close or not to close is "it depends." This leads to two other important questions: How do we make our SCO smart enough to close or not close the window depending on the situation? How do we make this work for the user when the window cannot be closed?
Automating the closing of the window
Only the SCO designer knows when a SCO is "finished". Typically, this corresponds to some event like the user finishing an assessment or clicking an Exit button. There might not be a formal Exit button; the SCO may have some internal trigger that signals that it is time to end the SCORM API communication session. When this happens, a SCO can use JavaScript to easily determine whether it is running in a popup window or not. It can check whether the window in which it is launched has a parent. If it has one, it is running in a frame or frameset. If it does not, then it should be safe to close the window. But even then, the browser's security settings might not allow a script close the window.
Making it work for the user
If the SCO cannot close its window but the activity is finished, the SCO should prevent further interaction by the user with its content. The most effective way to do this is to switch to a passive display that is visually harmonious with the rest of the SCO but only contains a prompt to confirm to the user that the activity has finished. For example, in a multi-page SCO, this could entail going to a passive "exit page". A passive page has no interactive elements. The passive page should be displayed in the SCO before it closes the communication session by calling Terminate or LMSFinish.
Using navigation requests
SCORM 2004 allows a SCO to invoke a navigation request. The runtime environment will act on the navigation request when the SCO calls Terminate to end the communication session. However, the SCO should still go to a safe passive page before calling Terminate for two reasons. The first reason is that you don't know how long it is going to take the sequencer to decide how to process the data and determine how to act on the request. The second is that the request may be denied, because the sequencer determines, on the basis of the available data and the sequencing rules in effect, that it cannot honor it. In that case the SCO might very well remain displayed until the user chooses to do something else, using one of the controls provided by the LMS in its own user interface.
Advanced defensive coding for quirky behaviors
Experience has shown that with some LMS that use a popup window there is an implementation quirk that results in the window not closing even if the SCO can determine that it could be closed safely. For example, there might be an unexpected dialog box that prevents the script that would normally close the window from executing. It may be possible to work around that problem by using a recurring timer to trigger the closing of the window if we can determine that the window can be closed safely. This needs to be scripted carefully to avoid runtime errors. However, it still not likely to work in many cases because of the default security settings on recent browsers, which prevent window closing by a script thread that is not initiated by a user click or key press. A timer event is treated as such a script thread. If you choose to attempt this timer-based defensive technique, the timer should be recurring because single-shot timers sometimes fail to trigger due to system load or other conflicts. When the function called by the timer executes, it should first check whether the window is not already closed, and it should use a try-catch construct to avoid causing unnecessary error messages if the browser decides not to allow the window to close. In any case, you should still design the SCO so that it will display a passive page if the window fails to close.
One should consider seriously whether adding the level of complexity involved in something like the timer scripting technique is worth the effort, especially since the browsers increasingly deny the closing behavior by a script. In my opinion, it is not worth it. Keeping things simple and designing the SCO to go to a safe passive page when it "finishes" should be sufficient most of the time.
This work is licensed under a Creative
Commons Attribution-ShareAlike 2.5 License.