Question Bank sends cmi.suspend_data through the roof!

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! 

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.

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! 

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.

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.

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)

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.

Agree completely with the statements about Scorm 1.2 being with us for a while (forever). Moodle however, is one of the few LMSs where you can override the limitation.