cmi.core.exit & cmi.exit

Ok, I just had to write a quick blurb about this one: in about 3.5 years of using SCORM in my own course code, I had never used cmi.core.exit (SCORM 1.2) or cmi.exit (SCORM 2004). Seems incredibly daft of me now that I’ve taken a few minutes to review the documentation.

The what

What does cmi.exit do? It provides some context to the LMS regarding why the course was closed. For instance, if the course was closed because it was completed by the learner, the exit status should be set to "logout". Likewise, if the course was closed before it was completed (and the learner intends to resume where they left off), the exit status should be set to "suspend".

The why

So why is setting cmi.exit important? Well, as I learned tonight, the SCORM specification states that if cmi.exit is not set to "suspend", the LMS is not supposed to store the data used for resuming the course, and will even infer a state of completion! Even if you specify a lesson status of "incomplete", if you don’t set cmi.exit to "suspend", the LMS is free to interpret that lack of "suspend" as a completed course session — especially if you aren’t using a mastery score for the LMS to evaluate.

The SCORM 2004 docs state:

If the cmi.exit is set to “normal”, “logout”,”time-out” or “” (empty characterstring) then the SCOs learner attempt ends. The SCOs Run-Time Environment data model element values of the current learner session will NOT be available if the SCO is relaunched.

The how

If you’re using the pipwerks SCORM API wrapper (JavaScript), you could include something like this in your course code:

SCORM 1.2


//the status gets set by your course code
var courseStatus = "incomplete";

function quit(){

   if(courseStatus === "completed"){
      scorm.set("cmi.core.exit", "logout");
   } else {
      scorm.set("cmi.core.exit", "suspend");
   }
   
   scorm.quit();

}

SCORM 2004


//the status gets set by your course code
var courseStatus = "incomplete";

function quit(){

   if(courseStatus === "completed"){
      scorm.set("cmi.exit", "logout");
   } else {
      scorm.set("cmi.exit", "suspend");
   }
   
   scorm.quit();

}

The d’oh!

I never paid much attention to cmi.exit (or cmi.core.exit) because the LMS I have been using didn’t enforce that rule. If I set the lesson status to "incomplete" then closed the course, the LMS assumed the course was going to be resumed, and left the lesson status alone. Plus suspend_data was always available, regardless of whether the course was suspended or not.

Tonight while I was troubleshooting my new course interface, I noticed that no matter what SCORM code I used, the course’s lesson status was being set to "completed" every time I closed the course. I had ZERO instances of the word “completed” in my course code, so how on Earth could my course possibly get set as completed? It was driving me bananas! Eventually, I started looking at the bigger picture (manifest, LMS implementation) and discovered the cmi.exit issue.

(As mentioned in my update at the top of the page, I investigated my older courses and was relieved to discover that I had been using cmi.exit the whole time, I just forgot about it when creating my latest interface. *Sigh*)

It just goes to show that not all LMSs are equal, and even with a standard like SCORM, you can still run into implementation issues from system to system.

Oh, and it also shows that you should read the manual. I’m a guy, so I generally don’t like to look at a manual unless I absolutely have to. 😉

Update: I just double-checked my old code, and yes, I was using cmi.exit on my older projects… I just forgot about it somewhere along the way!

New SCORM ebook coming soon!

I'm writing an ebook explaining how to build an HTML-based SCORM course. Subscribe to be notified when it's ready, as well as receive early bird pricing and some free goodies!

No spam, no sharing your email address, unsubscribe at any time. Powered by ConvertKit
Advertisements

3 Replies to “cmi.core.exit & cmi.exit”

  1. Not only that but cmi.exit value has an effect on the sequencing under 2004-which navigation request is used and if it’s used at all. It also has an impact on what the lms sets the cmi.entry to for the sco to read on re-entry(if it’s a re-entry.) I ran into a similar issue where my sco was setting the lesson_status at the end of the first screen-if a user bailed on it before it was set, under, 1.2 the LMS sets the lesson_status to completed. Which is different from 2004 where progress_measure and completion_threshold come into play.

Comments are closed.