Wednesday, June 3, 2009

What does a SCORM LMS actually do?

I was just asked some great questions on how LMS's actually work with a course. I thought others may be interested in this conversation:

I have worked with a number of LMS's. Why is it that all the work is done on the course side? The LMS must do something so that the course can send data. What does the course do, what does the LMS do? Is the LMS the data receiver and then processes the data in a given way (how flexible?. Does the LMS create the reports?
The course sends the data. I need an example here for example the status complete:
Does an LMS has a datafield that is set to “completed – not completed” depending on what the course sends? How many datafields are there for a course to be “SCORM”-compatible? Which fields? What does an LMS need to do to be SCORM-compatible?
Start a course, notice the exit, write a status, store the test results ----?

For most LMSs, what the LMS has to provide is a User ID when they launch the course, the “suspend_data” (2048 characters that the course set the previous time it was taken), the user name, the previous time on course, and a few other “core” fields. That is what is provided with a good SCORM course. There is no logic that the LMS is supposed to perform (with SCORM 1.2 and earlier): An LMS only provides data storage and retrieval. With AICC, since the course couldn’t really get to the content sent by the LMS, the requirement for data retrieval was minimal.

For SCORM 1.2, conformance, all that a course needs to do is send LMSInitialize and LMSFinish. This would make a course SCORM “conformant”. That is why you will see tools out there that can turn a Word document into a SCORM conformant “course”. Of course, instructionally this has no value except to track that someone has taken the course. A simple web statistics tracker could tell you that (you can see what users based on their IP address have seen what pages of content.)

For an LMS, to be SCORM 1.2 conformant, they must handle LMSInitialize(), LMSCommit(), LMSSetValue(), LMSGetValue(), and LMSFinish(). The important work is set by LMSSetValue, which specifies the variable name and the value. To be 1.2 conformant, there are 10 “core” values that must me supported. Most 1.2 LMSs have traditionally only supported about 5 of these (student_id, student_name, lesson_location, credit, lesson_status, entry, score, total_time, exit, session_time). There are some other groups of values called “objectives” and “interactions” where a course author could put in the score for individual questions. In SCORM 2004, support for these is required. The ReadyGo courses have used these in SCORM 1.2, but there are only a handful of LMSs that have tracked them and even fewer that have been able to report on them.

For continuity of behavior from one session to another, therefore, the course generally has to put the data it might need into the “suspend_data” field, and then it can parse it when it loads. With the better LMSs, the course could ask for a listing of the objectives and interactions that were previously provided along with previous lesson status and score. The difficulty is if you have 20 questions in 4 tests within one SCO (unit). It is hard to retrieve this type of detail from most LMSs since they only support the “core” set. So, with WCB, we use the suspend_data field to store/retrieve previous scores that have been set by the course. Then, in terms of logic for certificate generation, the course has to take care of it.

Because of the difficulties in retrieving data, there is a perception that a SCO should be designed to only have one question in it. That is why you will see many authoring tools that set up every test question, and usually every page of content to be a separate SCO. The golden rule with SCORM is that one SCO cannot send the user to another SCO, so this means that after each SCO (or “page” in most cases), the course has to exit from the LMS, and the LMS has to launch the next SCO. In some cases, this can take a noticeable time since the LMS has to retrieve the user’s previous data and package it so that it can be obtained by the SCO. In a good LMS, this may be a lot of data. So the end user suffers a delay between each SCO. If the SCO is designed as a chapter or an entire course, the delay will not be noticeable. However, if each page is a SCO, the course-taking experience could be painful.

No comments: