In my long experience in user interface design and implementations, I found that many
users either do not read prompts, or tend to misinterpret them when what the prompt says
doesn't fit their current mental model and expectations. For this reason, hoping that a user
will refrain from doing something stupid is not a substitute for putting in place something
that actively prevents the user from doing something stupid. This is basic usability (see
for example the many writings of Don Norman on this subject). We humans often think about higher level things while doing tasks for which we have automated "stupid" low level behaviors, like steering a car or clicking a "continue" button. This is why much well designed software asks, by default, "did you really want to do this?" when we attempt to do something that may have dire consequences. This is also why, IMHO, the SCORM 2004 3rd edition Sequencing and Navigation behavior specification that dictates that "Continue" should be enabled at the end of a sequence and has then the effect of throwing the user off the activity tree with an Exit All without any warning is problematic. It seems to negate decades of user interface best practice. The learner may be taken by surprise. If you believe that learning is linear and that it is good behavior to throw away a book as soon as you reach the last page, then the default
behavior defined in SCORM 3rd edition is fine as it is. If you believe that a user may benefit from being able to backtrack and review, however, before submitting his or her work to the LMS, then there is definitely a functional and usability problem here. However, it is possible for a content designer who is aware of this "feature" to work around this problem while still taking advantage of SCORM interoperability, by creating a "catch" activity for those cases; such an activity's sole purpose is to warn the user that clicking Continue again will result in termination of the package. Note that this will be an Exit All, not a Suspend All, meaning that there will be no opportunity to get back into the activity package except in a completely new attempt. A generic "catcher" for this usability problem is probably best not built into a learning activity SCO (unless yours is a single-SCO package), but rather in a separate activity and SCO. This "catcher" SCO is the activity that prevents premature exit. The SCO can be designed to still make sense in case the behavior specified by SCORM is corrected in the future--it can basically check whether continue" should be enabled, and if it is enabled display a warning of the consequence of
continuing. If not, then it basically just tells the user that the last activity in the sequence has been reached, and lets the user decide what to do.
A user of SCORM content is typically not particularly interested in in learning the idiosyncracies of SCORM sequencing or of the LMS user interface. IMHO it is reasonable to expect that such a user's cognitive abilities will be engaged in processing the learning that has been taking place. Learners deserve good user interface design to avoid spoiling the experience. It would be interesting to hear from content designers and authors, and from users of learning content, what they think should happen when you reach the end of a sequence of learning activities...
Labels: premature exit, scorm, user interface
