Testing interactions in Dokeos SCORM tool

Because one of the most complicated tools in Dokeos is the SCORM tool (found in dokeos/main/newscorm/ ), and because I am currently checking the inner-workings of the interactions inside this tool (Dokeos version 1.8.5), I thought it would be good to write down, once and for all, how I actually check whether the tool is right or wrong, and whether the content is actually the culprit or not.

Getting the right tools

The elementary tools for these tests are Firefox (I recommend version 3 for its better handling of JavaScript debugging) and its excellent Javascript debugging extension by Joe Hewitt: Firebug. Getting Firebug installed in Firefox is easy (download and restart Firefox), and activating it for your current Dokeos portal is just a matter of clicking the little cockroach icon in the bottom-right corner of your browser and choosing to activate the "Script" feature.

Setting the breakpoints

Now that you have the right tools all setup, you need to go inside a SCORM learning path inside Dokeos, then select the script you actually want to check. This is done through the "Script" tab in the Firebug window, and picking the right script. You need to pick "scorm_api.php" here, because although it ends with a ".php" extension, it is actually a dynamically created JavaScript script. Furthermore, it is the SCORM API, so this is where all messages from the SCORM content are passed to Dokeos. What you want to do now is to set breakpoints, where the JavaScript will halt, report on the current status of a few variables, and ask you to confirm that you want to go on before doing anything else. In this case, we want to test SCORM interactions, so what we're interested in here is how the SCORM content sets and gets interactions-related variables through the JavaScript code. There are only one getter and one setter in the SCORM API. Namely, LMSGetValue() (around line 127) and LMSSetValue() (around line 323). Because interactions are things that are only written (and never queried), what we're most interested in is the LMSSetValue() part. That is, if you want to put a breakpoint on interactions in LMSGetValue(), you will find there are only two related calls: one for cmi.interactions._count and one for cmi.interactions._children. You can put a breakpoint on these two cases but it is likely that will not help you much. So what we want is to put some logging (huh... some breakpoints, sorry) on the interactions case in LMSSetValue(), that is around line 372. Setting a breakpoint on the line:

if(myres = param.match(/cmi.interactions.(d+).(id|time|type|correct_responses|weighting|student_response|result|latency)(.*)/))

will have the great benefit of showing us if a call to set an interaction goes through, and at the same time of giving us some information on what information the call bears (we get to analyse the param variable here). Let's have a look...

Trying it

Now of course, you will need a SCORM content that sends interactions to try this out, and you'll need to be sure it actually sends interactions (otherwise your test is pretty much useless). Now trigger some interactions recording, and see what Firebug shows in its rightmost frame. You should see variables and their values appear there. Do they use the right parameters names? (there is a list of recognized parameters in the scorm_api.php script, line 372 - quoted above) If you want to go to the next step, simply click the green "play" triangle.

Result types

In my case, the problem I found was that the setting of interactions actually started at interaction ID 1, whereas the setting of interactions should start at "0". It could be argued that Dokeos, to avoid errors in this case, should prefill all the interactions between 0 (included) and the given interaction ID, and I think this is the way to go. I will check in the SCORM documentation first to make sure this is an option.