SCORM Modes, Credit & Behaviors
It was determined in the release of version 4.0.8 of the SCOBot Content API the mode of 'normal' be removed as a requirement for setting data against the SCORM Runtime provided by the LMS. The technology implication is; your "setvalue" calls would get blocked by SCOBot if you were not in 'normal' mode. This control made sense at the time, as you should not be adjusting information after you submitted your attempt for a grade. However, there are some use-cases that deviated from this.
Past customers were not interested in students adjusting their attempts after submission, so SCOBot ignored 'setvalue' calls when not in 'normal' mode. The actual fact is, the platform may ignore them, but there is a possibility it doesn't. This is tricky business as you are attempting to manage your customers expectations, and deal with endless use-cases. So if you are in review mode, you really shouldn't be changing your data, but as you'll find below its all left up to how you read between the lines.
Whether or not an LMS persists any of the data sent by the SCO, while in a mode of review or browse, is outside the scope of the SCORM.
- You don't want the student to change their answers any further in 'review' mode
- Moodle (SCORM 1.2) actually launches your 'graded' suspended attempt in 'review' mode
Uh oh - In this situation you may have gone to the trouble of disabling user input in 'review' mode, so now when you relaunch your suspended attempt, you can no longer answer questions.
Just from a User-Experience standpoint this makes it highly problematic to effectively manage your session behaviors from a SCO perspective. Can I change the answers and it actually update my attempt so my Teacher knows? If I change my answers will it even save? Typing for no reason only to have your answers go into a void is an experience, but not a good one.
- You want to let the student know that their data may not be recorded.
- You search high and low for a reliable means of knowing whats possible on the LMS platform.
This is exactly the situation. You don't want your student endlessly typing up an essay only to find the bug ugly green data monster to eat their homework because you didn't do yours. This is the #1 highest complaint I get "It's not recording my data" ... and you can't ask "well what mode or credit were you in?"
Reliability shouldn't be a four letter word. And you shouldn't be accepting further changes to the student attempt in review mode. Especially ones that adjust their score or outcome.
- You want to accurately status the student attempt so when they suspend, score, progress can be displayed.
- Certain rules implemented by the platform may choose to take action regardless of the exit type of 'suspend' and may choose to launch you in other modes than 'normal'.
Of course it's a matter of how something should work, and then often how it actually works. All to often I find platforms that do not properly manage the end of a student attempt. Any other exit type than 'suspend' is an attempt ending state. Suspend, actually means I want to resume the same attempt and pick up where I left off. The LMS has a responsibility to generate a new clean attempt as long as the student has not exceeded their attempt limit if one is present, or the ability to review their work.
In SCORM 2004
Browse The SCO is presented without the intent of recording any information about the current learner session.
Review The SCO has previously recorded information about the learner attempt and is presented without the intent of updating this information with data from the current learner session
In SCORM 1.2
Browse The student wants to preview the materials, but not necessarily challenge the SCO for a grade.
Review The student as already seen the material at least once and has been graded.
The language used here leaves it open for the LMS to decide whether or not it allows the SCO to record the student attempt with this altered data. At the same time however, it requires both browse and review modes 'cmi.credit' value be placed in 'no-credit'. So its possible the intent here is to not give the student credit for making changes to their attempt, but giving the ability to adjust it. Food for thought anyway.
There were not dotted lines to "what is graded?". Does that mean we shouldn't set a score until the absolute end of the SCO? In Moodles case, if you set a score, that meant you were graded. Not that you exited in another way that suspending. Even if it was 1% and you suspend your attempt to take it later. When you re-launch you'll be in review mode. In their defense it may be possible to twist the definition of review mode in SCORM 1.2 as "The student has already seen the material at least once, and been graded". But the problem is the student didn't see the material, they suspended.
Right... so you launch in 'review' or 'browse' mode, SCORM insists the LMS set your attempt 'cmi.credit' as 'no-credit'. This somewhat puzzling action that links to your 'cmi.mode' in SCORM 2004. So in terms you could think about, they mean that whatever you do in a 'no-credit' situation will not change or enhance your score. But, by all means give them the illusion that it will unless you do something within your content to signify the student data is not being recorded. And then later in the specification they state that; "LMS is free to do what it wants with the data". Head spinning yet?
In SCORM 1.2, they did not make any restrictions about whether it must be set in credit or no-credit. But if your placed in no-credit, cmi.core.lesson_status cannot be altered. And if your in browse mode, it can only be altered to 'browsed'.
For a pre-test, or practice section this makes total sense to go in no-credit mode so the students interactions do not effect their score.
Since it begs to be repeated ...
- Browse - SCO is presented without the intent of being recorded. Credit is set to no-credit.
- Review - SCO has previously recorded information without the intent of being recorded. Credit is set to no-credit.
-
Normal - SCO is presented with the intent of being recorded. Credit can be set to credit or no-credit.
This is the default mode if no other mode is in place to identify it.
Without the intent of being recorded
Any information communicated by the SCO is informative
The LMS is free to do what it wants with the data
This language implies the SCO could still submit data against the API, but the LMS may or may not act on it. Not exactly the user experience you're looking for?
SCORM 1.2 did not make any mention of generating a clean attempt after a '', logout, timeout exit mode was set. So the end of the attempt may just result in your entry mode being set to '' instead of resume, and your mode being set to 'review'. This is probably the most unclear way to determine when something is truly done, submitted or turned in. And if you make changes, would your teacher even know or care? You could probably treat or think of some these more like sessions where more data was added or removed. But if you were already graded, the extra effort may have no effect.
In SCORM 2004, they made it much more clear that the LMS is responsible for generating a new clean attempt.
A subsequent learner attempt on the SCO will involve a new set of run-time data.
You may be on a platform that partially implemented SCORM 2004 on top of SCORM 1.2 logic. This is commonly a skeleton implementation to support SCORM 2004 calls in a very lazy way. It tends to lead to more implementation and behavioral issues. This also leads to finger pointing and angry stake holders.
Your content may be Shareable, but know thy Platform capabilities or your deployment may be met with some friction. How much of this can you rely on? Do you have a way to track back to your Platform team to get answers? Can you demo a system before you buy?
If you're in SCORM 2004, you may want to consider alerting the student that when 'cmi.credit' is 'no-credit' there actions will not effect their score or status.
cmi.core.credit (SCORM 1.2) and cmi.credit (SCORM 2004) may be more reliable means than checking that your in 'normal' mode if you're doing absolutely anything to manage user expectations.
Either way, over time some of this got fleshed out, but you may find yourself in the wild, wild west.
