Forum Discussion
SCORM 1.2 Suspend Data--Seems Wonky to My Pea Brain
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 n...
Good Afternoon, Gerry.
Engineering has weighed in on your question, and I'd like to summarize what I know for you.
- There is a lot more to our suspend_data than just whether or not the learner got the question right and what they answered. We store the location on the timeline, the navigation history (to support the Previous button), the current state of objects, variable values, interaction results, and much more.
- There are a lot of factors that go into what we store in our suspend_data, based on the features a particular object uses. Our algorithm is fairly long and complex, so it would be difficult for us to document the specifics. Also, it's proprietary. :)
- We don't see anything to indicate that we have a defect here. Everything we see tells us that we are being as efficient as we can be with the storage of suspend_data.
- It is expected that the suspend_data for Storyline 2 is larger than the suspend_data for Storyline 1. Due to added features, Storyline 2 requires additional suspend_data.
Please let us know if you need anything else, and have a great day!
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
