SCORM 1.2 Suspend Data--Seems Wonky to My Pea Brain

Nov 04, 2014

For the last couple of weeks I've been working on a SCORM 1.2 resume issue for a Storyline 2 course that I'm trying to finish up on for a client.  I posted on this previously but that post appears not to be available now in the new forums.  So here's an update . . .

First of all, I have to say the Articulate front-line support person that I've been working with has been very helpful and very responsive.  Couldn't ask for a better experience there.

Anyway, back to the problem.  Basically, I have a SCORM 1.2 course that, after you launch it from the LMS and fail the final quiz, you, say you exit from the quiz results page. When you re-launch the course later to re-try the final quiz, and bookmarking kicks in, you are not returned to the quiz results page but to somewhere in the middle of the quiz to a quiz question that needs answering.

So bookmarking appears not to work right.

After that happened I filed a case and working with Articulate support, we confirmed it was a issue with the amount of resume (of suspend) data. It was exceeding the SCORM 1.2 limit of 4096 characters as nicely described here in the KB

So, when re-launching the quiz turns out I was being returned to just before the SCORM 1.2 4096 character limit had been reached in the previous session, which makes sense.

So, working from a couple of my own ideas and more suggestions from my fellow Super Heroes (thank you, Steve F. and Phil. M) I tried to reduce the suspend data in the course by trying some of these things:

  1. Publish to SCORM 2004 3rd or 4th Edition or Tin Can/Experience if you can or LMS supports. (Not an option here--the LMS only supports AICC and SCORM 1.2, and SCORM 2004, for a variety of reasons, is not an option).
  2. Reduce the number of slides in a course.
  3. Reduce the # of layers in a course
  4. Consider using lightbox slides for layers that repeat over many slides or come from masters.
  5. Set as many slides as you can to "reset to initial state" if you can.
  6. Reduce the number of questions in a quiz or cut any freeform interactions that you can.
  7. Use freeform questions instead of text based questions as less data may be sent.
  8. Reduce the use of longform variable strings.

The course is fairly short, just 50-55 slides. Most slides have a pause layer and transcription layer for displaying narration text.  Three of the slides are separate multiple response quiz questions at the end of the topics and 10 slides are simple multiple-select questions for the final quiz.

The course also use a mandated Storyline template that the client had developed by another firm.  I had to use that template with little, if any, variations.

The master had 4 layers on the layouts which I was able to cut down to just two by moving two of the layout layers over to two lightbox slides. The other two layers I could not reduce due to the way lightbox slides currently work in Storyline (needed more customization than currently is permitted).

To verify the suspend data overage, Articulate Support had me turning on LMS debugging in the course and send them the log files. So, after providing that for them, I decided to watch the log files myself and record the amount of suspend data after I had moved to a new slide.

If you've not set up a LMS debug file for a SCORM course, this is how you do it.

Actually, kind of fun to watch the debug file generate and see how it builds up with and after each slide in a course.  Neat tool.

And this is the line you want to look for in the LMS debug file to see the suspend data.

This command will appear many times as you deal a with a slide (so I was always looking at most latest occurrence of the string in the debug file for my character counts).

For that line, eliminate the "strValue=" and anything before it and then copy the data after (for that line only) and then bring that text into something like Notepad++, and then select all the text to get a character count for the resume data.

And when you exceed the SCORM 1.2 data limit, you'll see a line like this with "intSCORMError=405" in the LMS debug file.

Now my method for recording the suspend data was not exactly perfect as recording the suspend data after moving to a new slide also includes data for visiting that new slide. But I was mainly looking for general trends in going from slide to slide.

Going through simple, click-to-read slides with simple narration seemed to add only 7-20 characters per slide (and usually just 7 characters) when moving to a new slide.  Seems like a reasonable number to moi.

However, when looking at the "check your knowledge" questions and the final quiz questions, what I found initially was jaw-dropping. I was seeing well over 400 characters generated for each.  So just with my 10-question final quiz, I'd was going over the 4096 character limit for SCORM 1.2 suspend data.

After trying some of the things I listed above to reduce resume data, I was able to get the quiz questions to over 200 characters per question.

But still too much data . . .

This past weekend, I re-created the quiz from scratch using the default plain template in Storyline and nothing else. Quiz questions seemed to now add over 100 characters of resume data--pretty consistently 114-115 characters regardless of the amount of text in the question answers.

Much better but still too much data to my (limited :) ) way of thinking.  And I'm left to ask what in the real course itself is causing that number to be even higher? 

If there is indeed something in the template causing things to balloon up, it'd be nice if we as developers could know that to prevent that in the future.

Now here's the kicker. I took an earlier version of the course that was done in Storyline 1 Update 5 and published it out to SCORM 1.2 and set it up in the LMS.  I went through the course, touching each slide and quiz questions, and failed the final quiz. I then exited the course from the final quiz results page and looked at the last suspend data string sent to the LMS.

Then I opened the same course up with Storyline 2 Update 1 and published it out to SCORM 1.2 and set up a new course in the LMS. I then went through the course exactly as I had before, and answering every quiz question the same. Again, I exited from the quiz results page and looked at the last suspend data string sent to LMS.

I then compared character counts from both trials:  The Storyline 2 Update 1 version had produced 32% MORE SUSPEND data.

Now I'm not a programmer and my old pea brain may not understand all what is going on, but I'm left with at least a couple of possibilities . . .

1) Storyline's suspend data generation MIGHT POSSIBLY BE inefficient and could benefit from some tightening.  Again, I'm not a programmer but I scratch my head when it takes at least over 100 characters (in a plain vanilla version of the course) and over 200 or 400 characters each in the designed version of course with the mandated template to record my answers to a simple multiple choice quiz question.  Something doesn't seem right to me there . . .

2) Something in the course is causing the resume data to balloon up to over 200 or 400 characters when the plain vanilla version only has over 100 characters. But what is that? I'm using Storyline as it is meant to be used, and the supplied template isn't doing anything special or highly customized. So why the difference in suspend character counts?  Is Storyline 2 keeping track of a lot of new things as we proceed through a course?

One more kicker--publishing to AICC produced nearly the same amount of resume data as its SCORM 1.2 counterpart (which is good).  However the course didn't have the bookmarking problem at re-launch.

AICC has the same suspend data character limit of 4096 characters. But it appears that this LMS was not enforcing the AICC character limit the way it was with SCORM 1.2.  An unexpected, but very lucky, result--and a temporary solution.

Unfortunately, using AICC is just an interim solution at best. The client the course is for wants SCORM 1.2 as they will be migrating to a new LMS soon and it may not support AICC.  And the new LMS does not support Tin Can yet and they're currently having trouble getting SCORM 2004 3rd of 4th edition to work.

Sorry for the long post but I thought I'd share my recent experience in case it might help someone else in some way.  Starting to feel like I'm engaged in one of the labors of Hercules . . .  ;)

Hoping I hear something more definitive from Articulate support soon.  The QA team is looking at it.

With fingers crossed  . . .

79 Replies
Stephen Cone

Hi Justin,

I recently stumbled across this post when I was researching an unrelated issue. Unfortunately, I have not had the opportunity to experience Storyline 2, so I will limit my comments to my experience with Storyline 1.

I understand that the suspend data Storyilne is sending back to an LMS stores much more than the standard interaction details for a given course. I also understand that Articulate has made the calculated decision to encode and compress the suspend data so you can fit more data within the character limit.

I would agrue that your not being efficient at all in terms of the data you include in the suspend data string because you're relying too much on the compression.  One example that comes to mind is that the Interaction IDs that Storyline generates are overly verbose and contain redundant text. I've typed in an example of an Interaction ID from one of my courses below:

Scene2_QuestionDraw91_Slide1_MatchingDropDown_0_0 

That's approximately 46 characters devoted to a single ID.  Seventeen characters of that string could have easily been removed by eliminating the question type from the string, especially since you already use SCORM to send the question type to the LMS as a separate value. The string could have been truncated further by using initials or eliminating the descriptive text (e.g. 2_QD91_1_0_0). 

In comparison, Articulate Studio '09 just used a simple "QuestionN_N" approach for the Interaction ID.

It may seem silly to be concerned with how many characters are in string, but ultimately they all add up usually to the dismay of an Instructional Designer or client who has to change how a course functions because the suspend data exceed 4096 characters.

And Gerry? We have our developers ensure that all the review questions are set to resume to initial state. That seems to reduce the size of the suspend data. I suspect based on Justin's comments that may also to apply to non-quiz slides as well.

Thank you

Jennifer Ritter

I've also run into this same problem and have submitted a feature request, as per Ashley's suggestion.

Thanks to everyone who has contributed to this thread. You've all done a fantastic job of investigating, documenting, and explaining the problem.

On a potentially related note (since technical details are not my area of expertise), would a multi-SCO packager feature theoretically be able to help with this?

Steve Flowers

Hi Jennifer -

Possibly. Breaking a large module down into smaller chunks (A, B, C, D) would mitigate the effects of the suspend data ceiling. But the multiSCO would still be separate SCORM packages bundled up. If you bundled this in a SCORM 2004 package and your LMS handled intraSCO navigation, you could bounce from the end of one to the beginning of another.

Trouble is that all LMS don't handle this the same way:)

This is one of those I'd really love to see solved.

Robert Edgar

Here is what for me is a related thread. I contributed to this thread because we had lost bookmarks and courses left incomplete, and I suspected the suspend_data string. It turned out not to be that--our LMS did not enforce the 4096 limit. A major cause of loss of bookmarking turned out to be lost connections. So I used the bWarnOnCommitFail variable from Articulate (in the story.html file) to add a pop-up message for the learner whenever the connection between the course and the LMS is dropped. But now I'm having problems with the course not communicating ANY completions with the server--unless the learner finishes the course, closes the course, then RELAUNCHES the course, and then closes it again. On the SECOND close, the LMS shows the completion.  Anyone have any ideas on this one? 

Gerry Wasiluk

The other issue with multi-SCO's is they usually all have to complete successfully in the LMS for the entire course completion to go through.  Should one completion not get through--say, there's some network issue--it can really frustrate the learner.  And what module do they have to try and get to complete?  Not obvious.

Doesn't happen a lot but I've seen it happen a few times . . .

Robert Edgar

Hi Gerry. Thanks. The solution to this problem was to use the default "Next" button on the Results page. I wanted to pop on a "Next" button in the "Success" layer, so that only a successful learner could get to a "Congratulations" page that followed. But it turns out that the completion doesn't get sent if that default "Next" button isn't on the Results page.  So there ya go.

Robert Edgar

Gerry, I'm working on ELM 9.1, which is the Peoplesoft LMS now owned by Oracle. At the moment I'm still without an answer. It seems that the bWarnOnCommitFail, when set to "true", conflicts with the submission of the completion message to the LMS server. The other symptom that I'm seeing is that in some of my tests varying the  bWarnOnCommitFail and my forcing the completion message using a short piece of Javascript on the Results slide, the Player "Exit" link is made unresponsive throughout the course.

Has anyone successfully used the bWarnOnCommitFail in a course? I'm delighted when it works, but it does seem to interfere with these other functions.

Robert Edgar

An update: the problem of having to relaunch a course to complete it is happening only on Firefox. Chrome has no problem working with the bWarnOnCommittFail = true setting. The "Next" custom button is not an issue, confusion for that was caused by my having accidentally switched between Firefox and Chrome for a test. Ill test now to see if there are any Firefox settings that might let the completion work.

Barry Hinks

I'd echo others in this thread in that having a list of items that increase the suspend data would help with designs. I've had a course working perfectly for 2 months, until I needed to share outside of the LMS on a platform for 3rd parties to access and now the course exceeds the suspend data limit on their LMS. I can only assume our LMS (Cornerstone) has an override for SCORM 1.2 limit.

This as others have said, at the last minute has caught me out and I've sat here today trying to reduce (unsuccessfully) the suspend data. I even separated the end test from the content (65pages) and this still leaves above the suspend limit, so what's causing it??!!

It would be so handy to have a top 20 / top 50 list of what contributes to the suspend data limit & a % ratio e.g. resume saved data on a page = 5% of your overall limit.

I can republish in SCORM 2004 which works in SCORM cloud but frustratingly the suppliers bespoke LMS doesn't recognise the resume feature in Storyline for SCORM 2004, but does in SCORM 1.2???!! Otherwise I'd have a solution, whereas now I've no idea what my next move is ...

 

 

 

 

Ashley Terwilliger-Pollard

Hi Barry, 

I'm sure you've seen that the suspend data is not human readable, and that's due to our proprietary set up to help compress and help folks not hit the data limit.  Folks have submitted feature requests to be able to uncompress it or access all the content included - but I don't know the viability of those based on the proprietary nature. 

As you can see from this article about reaching the limit, things that are included are the resume status of the course, and each slide, variable value, etc. 

Hope that helps a bit

Ian Poole

I have recently experienced the same problem with exceeding the suspend data limit. Using the (very helpful)  information in this discussion I switched on debug and did some tests.

The only way I found to reduce the data significantly was to set ALL slides to "Reset to initial state". For instance, a simple multi-choice question was sending 110 chrs back when the re-visit was set to "Automatically Decide". Changing it to "Reset to initial state" reduced the data to 9 chrs. My entire course went from over 10,000 chrs to around 1200 chrs. The course contains 147 slides including 9 sub-assessments, 10 result slides, 57 questions spread across 33 question banks. Passing the nine sub-assessments achieves a course pass via a final result slide.

Unfortunately the ability to review answers is lost when the slides are set to "Reset to initial state". So, I used a custom variable for each of the nine sub-assessments to hold a copy of the scorepercent variable for each. These were used with sliders to show how the student performed in each. If the student stops and starts the course these custom variables (and the slider positions) are maintained and they can pick up where they left off. Although they can't review their answers they can see which of the assessment topics they need to re-visit before attempting it again.