A year ago, we talked about 5 things every piece of SCORM content should do. Today, I wanted to mention 4 things every SCORM test should do… Keep in mind, SCORM tests are a subset of SCORM content, so they should be doing those same 5 things I mentioned a year ago. Take that as a given. This is just a further set of details.
1. Record your interactions with full detail
SCORM provides a way for content to record the learner’s answers (and the questions) to the LMS. Put simply, do it. We see content all the time that elects not to report these interactions, and it’s a waste. Even if the LMS doesn’t report well on this information today, it could do so ultimately. And from a learning/remediation perspective, it’s crucial that the administrators of the LMS be able to see how their learners are progressing. Just do it. Nike would be proud.
Now for the details. Recording interactions can be done well or done poorly. If you want to do it really well, and your LMS supports it, opt to use SCORM 2004, rather than SCORM 1.2. SCORM 2004 allows content to be far more expressive in reporting interactions.
Next, understand the data model elements. I’ll spare you all the details here, but here are some highlights. For the purpose of examples, pretend like we’re working with this question:
What is my name?
A. Tim Martin
B. Reggie Benes
C. Dan Stook
D. Keith Bolliger
- Record the result (correct/incorrect) in cmi.interactions.n.result
- Record the learner response and correct response using a human readable identifier (or collection of them). Better to record “Tim_Martin” than “A” if the learner answered the question correctly. This gives the LMS an opportunity to share that data with the administrator in a useful fashion. And in SCORM 2004, “Tim_Martin” is now a valid response pattern. (In SCORM 1.2, “A” was the best you could do.)
- Use cmi.interactions.n.description. Frankly, this is one of the best additions in SCORM 2004, allowing you to record that the question was, in fact, “What is my name?” From a reporting perspective, this a vast improvement.
- If you’re going to go this far, you might as well complete the data model and record the following:
- cmi.interactions.n.type
- cmi.interactions.n.weighting
- cmi.interactions.n.latency
- cmi.interactions.n.timestamp
2. Understand the difference between state and journaling
First things first… interactions are recorded in an array. Take note of cmi.interactions.N.whatever. That array is sequential, and each time a SCO wants to record something to it, it has to ask for the next available space (via cmi.interactions._count). Separate from the N I’ve just mentioned, though, is the identifier of the interaction… cmi.interactions.n.ID.
If a piece of content wants to record a 10 question test and have a slot for each of the 10 questions, it can do that, even if they allow the user to update their answers. It would do so by cycling through the existing interactions and examining their cmi.interactions.n.ID to see if it matches the one that needs to be updated. This technique of updating a given interactions values by cycling through the array and resetting those values is called “state” or “stateful”. The recorded interaction indicates the current state of those values. It also eliminates any prior values that may have been recorded. State is a valid approach to recording interactions.
On the other hand, the array allows for you to simply add another value to the interactions array rather than seeking out the old array location and overwriting it. In this case, the content would simply request the cmi.interactions._count value and record the new interaction data in that slot of the array. In using this journaling technique, all of the historical values for that interaction are maintained. If the content wishes to retrieve those values, say on relaunch of the content, though, it has to be more intelligent about discerning which of the answers was most recently given.
Note, both journaling and state are valid option. It’s crucial, though, that the content manage it’s concept of cmi.interactions.n.ID well though. A piece of content that uses a new ID each time it reports and interaction is not properly journaling, because the association between multiple answers of the same question is lost.
3. Set completion status and success status
In SCORM 1.2, completion status and success status were rolled up into a single entity, cmi.core.lesson_status. It had six potential values, including completed, incomplete, passed, failed. In this world, it was impossible for the content to tell the LMS if a failed status meant that the user should be allowed to take the content again or not. Was it failed because they hadn’t finished? Who knew?
SCORM 2004, though, separates the concepts of passing and completing using two distinct data model elements:
- cmi.complete_status (completed, incomplete, or unknown)
- cmi.success_status (passed, failed, unknown)
This allows the content to be more expressive about whether a failure was final. Each content vendor is welcome to their own interpretation here, but making use of both completion_status and success_status is important in SCORM 2004.
4. Post a score
Lastly, be sure to post a score. It’s such a simple thing to do, and it’s hugely useful to the LMS. Take note, in SCORM 2004, the posting of a score should look like this for a 10 question test on which you got 8 right.
- Set cmi.score.raw to 8
- Set cmi.score.min to 0
- Set cmi.score.max to 10
- Set cmi.score.scaled to 0.8
