Question Bank sends cmi.suspend_data through the roof!

Feb 15, 2023

I've had a simple SCORM 1.2 course fail testing due to the suspend_Data limit being exceeded. I was shocked as this is not a complex course, and not that big (62 slides and 3 custom T/F variables).

Using ScormCloud and testing each section, I have found the culprit - a question bank with 10 questions. This has added 2500 characters to the suspend_Data limit just in itself?! Why on earth is this happening?

More details:

So, in my first 6 sections, we have about 8 multiple choice questions scattered throughout, and one drag-and-drop. In total, by the end of the 6th section, the suspend_Data is 1,735 characters - about what we would expect.

My final section - section 7 - is an assessment made up of 10 questions (8 "pick one", and 2 "drag-and-drop"). The questions are in a Question Bank so that their draw can be randomised.
Let me be clear. There are only these 10 questions in the Bank, and every question is always asked to the Learner, just in a different order each time.

By the end of these 10 questions, my suspend_Data had sky rocketed to 4,368?!?!

Do 8 pick one, and 2 drag-and-drop questions need almost 2500 characters just to hold their suspend_Data?

8 Replies
Luciana Piazza

Hi Andrew,

Thanks so much for reaching out with your findings. Sorry to hear that you're experiencing this issue with your project. 

Would it be possible for you to share your file with us? I'd like to take a closer look on my end. You can share the .story file in this thread or privately in a support case.

Thanks so much! 

Andrew Hanley

Hi Luciana, I cant share it - this is under client NDA.

After working all afternoon I have found out some interesting things though.

The randomised Question Bank doesnt seem to be adding in many additional characters to the suspend_data. I removed the Question Bank, and just went with the same 10 questions, but set up sequentially; one after the other. However, the suspend_data is still having over 2000 characters added to it over these 10 questions!

Another interesting thing is when I look at the actual suspend_data, I can see many many examples of what I would consider totally unnecessary bloat in the data being sent.

For example, in many places, we have the following strings of characters:

  • "g_default"
  • "g_default_Visited"
  • "g_default_Selected"

By the names being using, Im guessing this has something to do with States?

This seems to go against what Articulate themselves have said about Storyline. I understood that one of the things the engineers had done to ensure the suspend_Data was as small as possible was to compress and encode it. This doesnt seem very compressed to me.
"g_default_Selected" = 18 characters.
"g_d_s" = 5!

Its only a saving of 13 characters, but these instances are scattered a large number of times throughout the "suspend_data" and with a limit of only 4000 for SCORM 1.2 and 2004 (2nd Ed.) then being able to not waste several hundreds would be of significant value.

So, are States handled poorly in Storyline for the suspend_Data? If so, then interactive types like Drag-and-drops are naturally going to have a much larger suspend_data footprint than other slide types; given that they have more States by default.

Luciana Piazza

Hi Andrew, 

I understand the need for confidentiality. In case things change and you'd like to send along a sample file (without client info), our team would be happy to sign an NDA so that we can take a closer look at your .story file. Just a suggestion! :) 

Thanks so much for sharing your findings with us. We appreciate it!

I'd like to have our talented Support Engineers weigh in on your discoveries in order to assist you better. I have created a support case on your behalf so they can investigate this further. One of our Engineers will be reaching out to you shortly via email. I have shared all of the details you provided within this ELH thread so they are in the loop! 

Thanks so much for your patience! 

Phil Mayor

Are you using the quiz review function? If not have you tried set the slides to reset to initial state rather than automatic, may reduce the data saved into resume data. Also Storyline will send the question and response strings to resume data, so using freeform questions can help reduce the death sent. Feel you pain though resume limits are always difficult to troubleshoot, what LMS are you on maybe able to increase the limits.

Andrew Hanley

Morning Phil! Good to hear from you again, and thanks very much for replying; I really value your input on this one.

So you are quite right, Im using the Review function, and I understand that will always add some "bloat" because of the need for the slides to remember their resume state. And unfortunately, that also forces me to use the "Resume Saved State" so that the review works correctly. :/

I didnt realise that about the question and response strings being sent too.
However, I already always use Freeform as my question types (I find it quicker than using the Graded Question route). So again, Im not sure there is anything I can do there.

What I have found is quite interesting. One of my questions is a drag and drop with 3 "dropzones" into which 18 draggable items need dropped! And even though none of the objects have "drop correct" or "drop incorrect" states (all only have "normal"), its still quite a lot of objects and I thought just through permutations alone, this might be contributing a huge amount to the suspend_data.
But it isnt. In fact, it's impact was astonishingly low.
With that question in, suspend_Data = 4299
Without, suspend_Data = 4205

So less than 90 in that one question which is by far the biggest of all (in terms of objects).

...which makes it even more head pickling and frustrating that if the biggest question is requiring so little suspend_Data.... what on earth is taking up all the remainder?!

I do still think there is a bug in there because I cant see any reason whatsoever, that Articulate would have to use "g_default_Selected" and "g_default_Visited" etc. There are so many of those instances in the suspend_Data that it makes me think someone forgot to encode that bit, or use an alias, or whatever else the other data is using. The rest of the suspend_data is completely unreadable more or less, yet these stick out like a sore thumb.

Anyways, Im going to spend one more morning to see if I can get anywhere else with it; just for my own knowledge - and the Engineers have reached out to me so we will see if they shed any more light.

Thanks again! A.

Jürgen Schoenemeyer

you can see the growing resume string live in the browser
(the resume string for LMS and publish to web is identical)

  • publish to web
  • then start with chrome
  • Press F12 (-> browser console will open)
  • Select tab "Application"
  • open at the left "Storage / Local Storage"

you see the resume string - it is updated with every "slide leave" or "show slide layer"

@articulate - it is important to make the resume string more compact - scorm 1.2 will stay with us for a LONG time (moodle only supports scorm 1.2 - no scorm 2004 - and unfortunately this will not change)

Andrew Hanley

Jürgen - thank you so much for sharing this!
I was always querying the string from the LMS end of things... which as you can imagine, made the whole process of testing and diagnosing much longer and more intensive.

This is a great tip, and I will use it for sure. Thanks again for sharing!

And I shall also add my whole hearted agreement to what you say. SCORM 1.2 is still the predominant standard for my clients, this is not going to change any time soon, and having bloated strings that we as developers have no ability to refine is something that needs addressed.