Our Question
"Recording a learner’s answer is simple."
True -or- False
Let’s assume for the purposes of this exercise that the grading mechanism is in place within the content. We know, then, which answer the learner chose and whether it was correct. How would we record that via the SCORM Driver?
It really is just this simple.
//Get a reference to the ScormDriver
var SD=parent;
/*
SD.RecordTrueFalseInteraction(strID, blnResponse, blnCorrect,blnCorrectResponse, strDescription, intWeighting, intLatency, strLearningObjectiveID);
*/
SD.RecordTrueFalseInteraction(‘question1’, false, true, false, ‘Recording a learner’s answer is simple.’, 1, 3000, ”);
What if you couldn’t use the SCORM Driver?
Well, the answer is that it takes a bunch of steps, and those steps vary substantially in the different standards supported by the SCORM Driver. In this case, we’ll examine the steps in SCORM 2004 as pseudocode, stopping short of worrying about the syntax itself.
- Confirm that you have previously discovered the SCORM API (this in its own right is challenging).
- Clear the LMS error information. What does that mean?
- Use GetValue(‘cmi.interactions._count’) to see if there are any prior interactions recorded so that you can record the next one after the existing ones.
- Check if there were errors in retrieving that value.
- Standardize/validate the type of the “true/false” value provided by the developer.
- Create a valid SCORM identifier from the value provided by the testing engine. As a hint, the regular expression required to do this looks something like: str = str.replace(/[^w-()+.:=@;$_!*’%]/g, “_”);
- Record the “id” of the interaction via SetValue, check for errors.
- Record the “type” of the interaction via SetValue, check for errors.
- Record the learner’s response… is it “True”, “T”, true, “t”? Check for errors.
- Record the “result”… is this supposed to be “correct”, or “Correct”, or maybe 1? Check for more errors.
- Record the “.correct_responses.0.pattern”, which, by now, is obvious, right? Oh, yeah, check for errors.
- The “description”…
- The “weighting”…
- The “latency”… wait, is that milliseconds? Or seconds? Um, errors? Yeah, we should probably ask the LMS how we’re doing again. But wait, what do we do if there are errors? Is there any effective way to debug this stuff?
- Back to it… record the objectives.
- And the timestamp, which obviously needs to be formatted as an Iso8601 timestamp. What in the world does that look like? (The answer is: 2008-11-04T13:39:12.)
- Check for errors one more time.
This is all to say… even at its simplest, recording a straightforward SCORM activity can be exceptionally difficult. What takes a single function call via the SCORM Driver takes no fewer than 11 interactions with the LMS if everything goes according to plan.
Compound this complexity with the four supported standards (AICC, SCORM 1.1, 1.2, and 2004) and the countless interpretations of those standards and the need for a proven codebase becomes abundantly clear.