Introduction

The eLearning standard “SCORM 1.2” defines a JavaScript API to exchange date between the Learning Management (LMS) and the learning content, called Sharable Content Object (SCO) by SCORM. Basically, this API defines a handful JavaScript functions that the LMS has to provide to the SCO to initialize and finish the communication, transfer data, and to handle errors.

The function to finish the communication (LMSFinish) has to be called by the SCO as soon as the student has finished the learning content or navigates away (e.g. by entering a URL, closing the browser…). If the student uses the SCO’s interface elements (like a quit button) there is no problem to execute some JavaScript and call LMSFinish. But, in most instances, the students will use the browser elements (like the close button or the location bar) to leave the SCO. To catch such cases the SCO should use the onunload event to trigger JavaScript when the student leaves the learning content. Unfortunately, the onunload event is not supported by the Opera Browser and there is no other possibility to guarantee the execution of any JavaScript when the student leaves the page (see stackoverflow discussion).

Since the SCORM 1.2 standard requires the SCO to call LMSFinish which cannot be guaranteed when the SCO is running in the Opera browser there are some points the SCO designer should be aware of. Of course, the simplest solution would be to use some browser detection and exclude the Opera browser or less rigorous, to integrate some warning to urge the students to use the SCO interface elements to finish the learning content to ensure a consistent data transfer with the LMS.

In very general terms, all LMS operations defined by SCORM 1.2 that are triggered by calling LMSFinish are problematic for SCOs running in the Opera, because to due the reasons above they might will not be triggered when the user leaves the SCO. In the following I will list all these LMS operations and try to give feasible solutions.

All information are taken from the document “Sharable Content Object Reference Model (SCORM) Version 1.2 – The SCORM Run-Time Environment (October 1, 2001)” (SCORM_1.2_RunTimeEnv.pdf).

LMSFinish ensures data persistent

By calling LMSFinish the SCO ensures that all data are persisted in the LMS.

From the LMSFinish description (page 3-8):

Description: […] This call signifies two things:
1. The SCO can assured that any data set using LMSSetValue() calls has been persisted by the LMS.
2. The SCO has finished communicating with the LMS

It is important to know, that the API does not need to instantly persist each data change resulting from LMSSetValue calls, but can implement some caching approach (e.g. on the JavaScript side) and persists the data on the next LMSCommit or the LMSFinish call.

From the LMSSetValue description (page 3-10):

The API adapter may be designed to immediately forward the information based on some other approach.

From the LMSCommit description (page 3-11):

If the API Adapter is caching values receiving from the SCO via an LMSSetValue(), this call requires that any values not yet persisted by the LMS be persisted. In some implementations, the API Adapter may persist set values as soon as they are received, and not cache them on the client. […]

Opera solution

Since the SCO does not know whether the API implements a caching approach and (as described above) the LMSFinish call is not guaranteed, the SCO designer should call LMSCommit after calls to LMSSetValue to ensure the persistence of the data even if the student leaves the SCO unexpectedly.

LMSFinish could change cmi.core.lesson_status

If the SCO does not set the value cmi.core.lesson_status the SCORM standard requires the LMS to change the value to either “completed”, “passed” or “failed” when the SCO calls LMSFinish.

From the cmi.core.lesson_status description (page 3-25):

Additional Behavior Requirements: If a SCO sets the cmi.core.lesson_status the there is no problem. Hower, the SCORM does not force the SCO to set cmi.core.lesson_status. There are some additional requirements that must be adhered to successfully handle theses cases:

• Upon receiving the LMSFinish() call or the user navigates away, the LMS should set the cmi.core.lesson_status to “completed”
• After setting the cmi.core.lesson_status to “complete” the LMS should now check to see if a Mastery Score has been specified in cmi.student_data.mastery_score, if supported, or the manifest that the SCO is a member of. If a Mastery score is provided and the SCO did set the cmi.core.score.raw, the LMS shall compare the cmi.core.score.raw to the Mastery score and set the cmi.core.lesson_status to either “passed” or “failed”. […]

Opera solution

Since there is no garantee LMSFinish is called the SCO designer has to take over the responsibility to set the cmi.core.lesson_status to the correct value. This can be achieved by calling LMSSetValue for the cmi.core.score.raw field as soon as the student’s status changes, e.g. after he has completed the learning content, passed or failed a test. As described above a call to LMSCommit should be used to ensure the data to be persisted in the LMS.
Moreover, after the LMSInitialize call, it could be reasonable set the value of cmi.core.lesson_status to “incompleted” if it is “not attempted” (which indicates the unchanged default value) to prevent the LMS to do any changes to the cmi.core.lesson_status value even if LMSFinish is called.

LMSFinish could change cmi.core.entry

Upon receiving the LMSFinish call the LMS changes the cmi.core.entry value.

From the cmi.core.entry description (page 3-26):

Additional Behaviour: Upon receiving a LMSFinish() or the user navigates away, the LMS should set the cmi.core.entry either to “” – (empty) or “resume” […]

Opera solution

There is no real problem with the cmi.core.entry field, but the SCO designer has to keep in mind, that the value of cmi.core.entry might remain unchanged “ab-initio” (which is the default value that indicates the first time the student enters the SCO) even if the student enters the SCO multiple times.

LMSFinish could logout the student

If the SCO sets the value for cmi.core.exit to “logout” the LMS should log out the student from the system.

From the cmi.core.exit description (page 3-32):

Additional Behaviour: […] In addition, the LMS should log the student out of the course when the SCO that set the cmi.core.exit to ‘logout’ has issued the LMSFinish() or the user navigates away

Opera solution

Since there is no guarantee the logout operation is executed by the LMS, the SCO designer cannot implement a “Logout LMS” functionality in the learning content, which should not be a problem in most cases.

LMSFinish could change cmi.core.total_time

After each launch the SCO reports the last session time (cmi.core.session_time) to the LMS, which accumulates all session times upon the LMSFinish call to a total time (cmi.core.total_time).

From the cmi.core.total_time description (page 3-30, and page 3-33):

Additional Behavior: […] When the SCO issues the LMSFinish() or the user navigates away, the LMS should take the last cmi.core.session_time that the SCO set (if there was a set) and accumulate this time to the cmi.core.total_time

Opera solution

There is no really solution for this problem. In result, both the SCO and the LMS cannot trust on the time stored in cmi.core.total_time to be the total time the student has spent in the SCO.

Summary

There are some points one should keep in mind when implementing SCORM 1.2 compliant learning content that should run in the Opera browser. All problems described here result from the fact, that there is no possibility to call LMSFinish when the student unexpectedly leaves the SCO. Of course, these problems could also happen in other Browsers, e.g. by killing the browser process before the onunload method was executed, but they are less common.