Step 22 – Progress and Completion – cmi.core.lesson_status

The process by which cmi.core.lesson_status is determined is quite complex. So, with a deep breath, let’s see if I can figure it out. Here – as far as I can tell – are the basic rules.

  1. The value of cmi.core.lesson_status can only be one of the following:
    • passed
    • failed
    • completed
    • incomplete
    • browsed
    • not attempted

     

  2. When the course is first launched, cmi.core.lesson_status should be set to ‘not attempted’ by the LMS. That makes sense so far.
     
  3. The course/SCO is not allowed to set the value to ‘not attempted’ – only the LMS can do that.
     
  4. The course (or ‘SCO’ in SCORM terms) can change the value of cmi.core.lesson_status at any time. The SCORM specification says “normally the SCO determines its own status and passes it to the LMS”, and that’s certainly my experience. But, apparently, we also have to handle the case when the course/SCO doesn’t do this. So …
     
  5. When the course calls the LMSFinish() function, or when the student navigates away from the course (i.e. closes the course window), the LMS should change the value of cmi.core.lesson_status to ‘completed’. This doesn’t make any sense to me … if a student looks at one page and then closes the course, should it really be indicated as ‘completed’? And should the LMS overwrite the value of cmi.core.lesson_status if the course has already changed it to (say) ‘passed’? The SCORM specification is somewhat vague on this so I have to assume that the LMS changes cmi.core.lesson_status to ‘completed’ if, and only if, its current value is ‘not attempted’ i.e. the course/SCO hasn’t previously made any attempt to change it.
     
  6. The LMS now looks at the value of cmi.core.credit.
     
    • If cmi.core.credit is set to ‘no credit’, the LMS looks at the value of cmi.core.lesson_mode. If it’s set to ‘browse’, the LMS changes cmi.core.lesson_status to read ‘browsed’. Otherwise, it does nothing.
       
    • If cmi.core.credit is set to ‘credit’ (remember that, in my ‘imaginary’ LMS, all courses are going to be designated as ‘credit’), the LMS looks for a mastery score that was set in the manifest file when the course was imported into the system. The manifest file is part of the SCORM ‘Content Aggregation Model’ which I haven’t looked at just yet. But let’s – for the sake of argument – assume that the LMS knows whether this value has been set, and what this value is. If the mastery score wasn’t set in the manifest file, the LMS does nothing. But if a mastery score was set in the manifest file, it compares it to the value of cmi.core.score.raw and sets cmi.core.lesson_status to ‘passed’ or ‘failed’ accordingly.
       

Utterly confusing. So here’s a flow chart which I hope captures the logic behind all of this.

How to Set cmi.core.lesson_status

But all is not lost. There are a couple of things that I can do to simplify this process.

  1. Remembering that I am going to treat all courses as ‘credit’ – a choice that the LMS and not the course makes – I can eliminate the test for the value of cmi.core.credit.
     
  2. cmi.core.lesson_mode isn’t a mandatory element and I’m not supporting optional elements, so I can eliminate everything to do with setting the ‘browsed’ status.
     

Here’s how it affects the flow chart.

Simplifications!

And here’s my simplified version.

Setting cmi.core.lesson_status - much easier!

Next time … how to implement this in code.

Be Sociable, Share!
This entry was posted in Run Time Environment. Bookmark the permalink.

5 Responses to Step 22 – Progress and Completion – cmi.core.lesson_status

  1. jcasolutions says:

    When you make this statement “course (or ‘SCO’ in SCORM terms)” it is incorrect. There is no such things as a course in SCORM. What most people consider a course is equal to a content aggregation in SCORM. A content aggregation can contain multiple activities that launch multiple SCOs. To say a course is a SCO or even to say a content aggregation is a SCO is assuming a 1 to 1 relationship when in fact there is a 1 to many relationship. When you make the assumption that a course is equal to a SCO then that limits you to tracking only one SCO per course and the database should be set up so that you can tack “n” number of SCOs per Content Aggregation and that data should be stored per user / per session.

  2. scormio says:

    If the SCO isn’t setting lesson_status itself it’s not SCORM compliant. The SCORM specification outlines the responsibility of the RTE in detail and it does not specify that the LMS should handle this situation. lesson_status should only be set to not attempted by the RTE, the rest is up to the SCO to work out….

  3. Steve Addison says:

    Hmmm … you may well be right, but that’s not how I read the RTE specification. This is the section of the RTE that places additional requirements on the LMS:

  4. Chris Phillips says:

    I always had a problem with this part of the spec.

    It seems that it would be best to let the content control all the lesson status & require it to do so. LMS’s shouldn’t make assumptions about what the content developer intended.

    Even worse is that many LMS’ will overwrite the content sending “complete” with a “passed” or “failed” status based on the assessment mastery score/student score.

  5. Steve Addison says:

    Agreed. Ideally, I think that a content/LMS runtime specification should either be content-centric (allowing the content author complete control of pretty much everything), or server-centric (allowing the content author only a very limited set of options). The SCORM 1.2 standard seems, at least to me, to divide the responsibilities rather awkwardly between the LMS and the content author.

Leave a Reply

Your email address will not be published. Required fields are marked *