Replacing the imsmanifest.xml file in updated courses

G’day,

We’re about to have an LMS update imposed on us that will be improving functionality in one area but will cause us some grief (going backwards) in another area. I’m hoping to find a solution to fix the grief bit before it’s forced on us.

My question is this: Does anyone have anecdotal experience with using the original imsmanifest.xml file in subsequent updates of their SCORM files? As an example: You publish course 1 and upload that to the LMS… realise there is an error (eg. bad navigation or MD wants a different photo used) so you fix it, republish it but use the original imsmanifest.xml file in the newly published SCORM package and upload that to the LMS. Does the course function 100% normally or are there issues/gotchas to be aware of?

I’ve submitted a case about this with Articulate support and their final response is that it’s not suggested nor will it be supported. But I’ve seen this recommendation being made before (even our LMS vendor suggested other customers are doing it but they then retracted the suggestion).

So why am I asking for this???

I’m desperate for a workable solution moving forward and hope that someone out there has successfully been doing this.

We’ve always had major problems with the LMS’s “Replace” function – it rarely ever works, even after making what seems like small changes to the course. The new LMS software update will be forcing us to jump through a lot of hoops to get updated content correctly set up and running – especially for actively running courses where we’ve got a mix of learner completions and those yet to do the course.

On our LMS, we upload our SCORM files into the “Content” area. In the content window for an uploaded SCORM file, the interface provides a “Replace” function but it typically produces an error stating that the course structure has changed, even if we make only small changes to the course. After much enquiry with our LMS vendor about it, we’ve been informed that the imsmanifest file is being interrogated upon uploading the new file and it’s ONLY allowing the following 4 changes to be made, otherwise it causes the error:

Item titles
Sample: <title>Jefferson</title>

Mastery score
Sample: <adlcp:masteryscore>90</adlcp:masteryscore>

Launch data
Sample: <adlcp:datafromlms>1,1,1,1,1,1,1,1</adlcp:datafromlms>

Starting url (href and parameters)
Sample: <resource identifier="R_S100001" type="webcontent" adlcp:scormtype="sco" href="index.html" parameters="">

(note: we would only potentially need to change the first two and, as far as I know, don’t ever need to change the third or fourth once a course has been uploaded and launched)

So, if we add/delete/replace a new “resource” file in the course (like images/videos/audio) this causes a fail as it updates this as a change in the manifest file. This isn’t such a big issue on our current LMS version as we can upload the SCORM as a new Content file, then go into the Course’s Activity and just swap out the old content with the new content and all the user data (completions etc) is retained within the activity (nothing is lost). After the next LMS update, the content file will be locked to the activity (meaning we can no longer swap it out), forcing us to close the Activity off and build a new Offering/Activity within the course. This will cause us issues with our active/completed learner data, which we’ll have to carefully manage hundreds of learners from the old Offering/Activity to the new Offering/Activity – painful and something we want to avoid!

This is where the suggestion of copy/pasting the FIRST imsmanifest file into subsequent updated SCORM files – that way the LMS has no issues with the new SCORM file being uploaded. We’re using SCORM 2004 v3. I’ve tested this and it works (it allows the “replace” to succeed where it previously failed if I kept the new/updated/changed manifest file in the SCORM). I’ve also done some preliminary testing where I took a 52 slide course, cut it down in Storyline to 4 slides and then published it to SCORM 2004, uploaded it to the LMS and then tested it as a 4 slide course. I then published the original 52 slide course but I copied/pasted the original manifest file into it (from the 4 slide course) and used the LMS’s “Replace” function to update it. I then successfully ran the course, closing and opening it at various stages, multiple times and had the full 52 slide course experience with all the images and videos showing/playing as expected. Each time I closed/resumed the course, the LMS was able to keep up with what slide I was on and the variable settings updated along the way and it accurately captured the completion trigger at the end. Everything seems to be working, despite the advice to steer clear of doing this – hence why I’m hoping someone out there has already been doing this successfully or knows of where this type of a workaround may/will go wrong. BTW, this was an extreme example. I don’t normally make such huge changes as this, but I figured that if it worked with such a massive change, it should be safe for the MUCH smaller changes we usually make when fixing a course.

Your advice is MOST appreciated!!!

Brett