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:
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
I’m gonna take a quick break from the SCORM Cloud beta tour to lay out a decision we’ve just made. In creating the SCORM Cloud user interface, we confronted something every web developer has been dealing with forever…
Which browsers are we going to support?
This question is a little different for us than most companies in that we have two distinct audiences: the companies that embed our software and those that use it directly.
In supporting companies like we do via SCORM Engine and SCORM Driver, we have an obligation to provide them with the support they need. And let me tell you, many of our clients still support IE5.5 (the bane of a designer’s existence).
So, we’ve got a particular responsibility to support the lowest common denominator (or something close to it). It is not our place to drag our customers’ customers forward in the browser evolution… We don’t get to make that decision for them, and so we won’t. This decision applies to the following products:
- SCORM Engine
- SCORM Driver
- Embed-able components of SCORM Cloud, accessed via the API
For our embed-able, compatibility based products, we support and will continue to support the following browsers.
- Firefox 1.0 and higher
- Internet Explorer 5.5 and higher
- Safari 1.0 and higher
- Chrome (all versions)
For our customers and their customers … we have a certain obligation … . But when it comes to the products we offer directly to the customer, we get to make our own choices. And I don’t feel bad about eliminating a potential customer by virtue of an informed decision if it affects only Rustici Software.
In designing and implementing SCORM Cloud’s new UI, we went to our usage metrics. In looking at Google Analytics, we’re seeing that just 7% of our total visitors are using IE6. For us, that number is low enough that we’re willing to ask those users to upgrade if they want to fully experience SCORM Cloud (and its Test Track functionality). Our apologies go out to those of you locked into old browsers by your situation or employer, but we’re going to drop our support of IE5.5 and IE6 for our customer facing products.
To travel hopefully is a better thing than to arrive, and the true success is to labor.
–Robert Louis Stevenson
OK, fine, he’s right and all. Creating the new version of a product is fun and all. But shipping it, polishing it, finishing it, that’s pretty awesome too.
Today is the confluence of a bunch of different work around Rustici Software.
- SCORM Engine? 2009.1 released
- SCORM Driver? A new release including SCORM 2004 4th Edition
- SCORM TestTrack? 2009.1 has already been applied, so this is fresh and clean too.
I’m psyched. Great new versions of old products out, and a clean slate to start on some new stuff. Thanks to the guys at the office, and, importantly, the cookie intern.