Forum Discussion
Updating SCORM Packages in LMS
When updating SCORM package files, there are times when they do not reset the user's progress, but other changes still affect it, regardless of the settings when we upload.
Do we know whether changing the 'Player' within the course would trigger a restart or allow students who were in progress to continue?
Thanks!
(Using Storyline, FYI.)
6 Replies
I would always expect any change to restart the course, changing the player is likely to do that.
Isn't this is entirely a matter for the LMS? As far as I know there's no way for a SCO to directly force a reset of the user's data record held on the LMS, either via API calls or any settings in imsmanifest.xml. It would certainly seem sensible for an LMS to apply a reset to all users when a SCO is updated but there's no guarantee it will happen.
I've never tried this myself but a possible partial workaround would be to have a version number variable (e.g. mod_version) within your SL module, updated for each new version published, which is copied to a user variable (e.g. user_version) when the student exits the module say. Then on re-entering the module you could compare the two. If the module has been updated in the meantime then mod_version > user_version and you could use this as a condition to enact any suitable changes/resets/navigations &c within the module. This still wouldn't reset the user record on the LMS though.
This is, unfortunately, one of those questions that concerns both the authoring tool and the LMS, I suppose, in how they work together.
We use LearnUpon (for now...), and their documentation explicitly states: It's hard to predict what changes can require a new module version, because both SCORM and Tin Can standards generate flexible content modules.
And then, on the other side of it, I just don't know what constitutes a 'structure change' for the Player. We've discovered firsthand that as long as we don't change the pages/numbering, we're fine to change the content on each page. Even replacing the page changes the 'IDs' enough to affect the users progress.
Storyline will reject resume data if it doesn't match what it is expecting. Updating a course will often change the resume data when Storyline ca no longer use it. I believe it already uses a version control in the resume data to determine this.
Variables in storyline cannot affect this as the resume data is loaded before a slide loads.The player manages the resume data hence whY I suspect changing the player will break the resume data
ah, ha! I didn't realize the player was what managed the resume data itself. That makes sense then.
