LMS/SCORM Complete status

Question:
If the LMS manager and the LMS provider are clear that the status “complete” shall appear when for example the student took a test and passed. Why is this still so complicated to implement that? Is this a problem of the SCORM definition, or a mismatch of field names?

Answer:
It is all about WHEN the completion status is sent. Some LMSs assume that a SCO contains only one page. Therefore, if the SCO has been completed, the student session is finished, and there is no more to do. However, if the SCO has multiple pages, and after the student completes, they visit other pages, the LMS could decide to stop tracking any further results (I have seen this). Sending a status to the LMS is not hard, but it can be hard to calculate it, especially if it depends on scores or behaviors from previous sessions. Also, there can be timing issues. Typically, one wants to report status type information as the user leaves a page or loads a page. With some LMSs, if the messages arrive too quickly, the LMS drops messages. In the case we were seeing with the AICC Basic IE6+, FF+ for frameless, the reporting problem existed because as each page of content is unloaded, the course reports the time on the page and the current lesson status. When the course gets to the Exit page, it has more to do. When the page loads, it sends the course completion status (putParam/ LMSSetValue). Then, separately, it has to send the ExitAU (equivalent to LMSFinish() and LMSCommit() in SCORM) message. With AICC, these are messages sent directly to the server. You can’t send more than one at a time, so we had to split them into onunload for one page, onload for the exit page, and onclick for the exit page. We were possibly seeing a timing issue that the onunload from the previous page and the onload for the exit page were arriving too soon (or in the wrong order) at the server. The onclick for the exit button wouldn’t be such a problem since the user will take at least 0.5seconds before they click it.

Another big issue is what to do when the user “exits” the course. This can either occur with an explicit “exit” button or if the user closes their browser. Many authors don’t want the exit button, and many users simply won’t use it. Therefore, if the user clicks “X” to close their browser window/tab, the course must send the exit messages. This can get difficult. So there needs to be an overall onunload for the course/frameset. Some newer browsers are preventing sending of messages directly to servers when pages unload because of security. Also, how does one send two or 3 messages simultaneously as the browser is shutting down?

Aside from the theoretical issues, there are some simple practical ones. When the course is built, it needs to be tested in the delivery environment. We often find problems in sequences we didn’t expect the student to follow – they start the course, jump to the end, jump to a test, exit, come back… With the AICC course we were working with there was an additional issue that it seems that the browser behavior changed over time. We saw that the onunload message from the prior page was arriving at the LMS after the onload from the final page. So, the onload message set the status to complete, but this was overwritten when the previous page’s onunload message arrived. We did expect the messages from the previous page to arrive after the message from the current page.