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:
- 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).
- Reduce the number of slides in a course.
- Reduce the # of layers in a course
- Consider using lightbox slides for layers that repeat over many slides or come from masters.
- Set as many slides as you can to "reset to initial state" if you can.
- Reduce the number of questions in a quiz or cut any freeform interactions that you can.
- Use freeform questions instead of text based questions as less data may be sent.
- 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
I would like to add a GREAT Solution from another forum, namely the concern for the usability of the suspend data, this would help resolve both forum issues by allowing us to see what is being pushed to the LMS
Deborah Seidman &James Jordan
16 days ago
I don't have a problem with them compressing the data. I have a problem in their not releasing a tool to be able to look at the data. If they want to keep the routines close to their vest them they could simply publish a tool on their website like google translate. You paste something on the left and push a button to get uncompressed data on the right. If you edit what's on the right you should be able to click a button to translate it back to the left. Not supplying anything is the ultimate frustration.
Thanks Stephan for linking to that other thread - as I know questions of suspend data and how to read through it are common questions in the forums, but not something our team can offer support for.
Ashley,Justin has made an even clearer explanation THanks!
Justin Grenier Author Stephan Sinka
26 minutes ago
Good Morning, Stephan.
The decision to compress Suspend Data is less about protecting proprietary information and more about making sure we don't exceed the data limits that some Learning Management Systems impose.
Further still, we can't offer a web-based suspend data decoding tool right now since our compression/decompression routine is dependent on XML data that is unique to every project. It is not possible to decode the suspend data without first parsing the XML and then creating the correct object structure to read it. Again, we're not trying to hide anything. It's just that this model honestly isn't achievable at the moment.
If you have a set of LMS Debug Logs that we can help you diagnose, please feel free to send them over and we'll be happy to take a look:
https://www.articulate.com/support/contact/submit.php
Thanks for adding your voice to our community!
Has there been any futher resolution to this issue? I can see the last post was 8 months ago. We are piloting SL2 for our organization but have an LMS that will only support SCORM 1.2. If we are saying to avoid the freeform questions, does that mean everything has to be built manually? Is it only for the final (scored) test or all the interactions in between (not scored).
Thanks.
Hi Natasha,
There are a number of issues here.
For myself, we tested by saving and re-launching courses with longer and longer suspend data strings (essentially, adding questions to the course at about 20 at a time, then testing, then adding 20 more), and found that the length of the suspend data string was not a problem in SCORM 1.2 either for Storyline 2 (which continues to work far past the 4096 number, at least into 12K-long suspend strings) and neither for our LMS (Oracle's ELM 9.1).
So the first thing is to empirically test your LMS for its ACTUAL limit for the suspend string. If the suspend string breaks in the LMS, relaunching with the bookmark won't bring you back to where you left off. Each question you add will lengthen the suspend string. (Gerry shows you how to measure the string length earlier in this thread).
If you want to add a question as an exercise WITHOUT adding to the suspend string length, set the question to "Slide Properties/When revisiting: Return to initial state". in the Base Layer Slide Properties tool (the little gear icon in the bottom right of the Question screen view). If you need to save the data as to whether the question was answered correctly by the learner (whether in the course body or as a post-test), you need to set it to "Resume saved state".
Note that if you're having trouble with your test questions pushing your suspend data strings past their limit, try returning all interactions and questions in the course to "Return to initial state", then break any post tests into their own activity or component, separate from the course body.
I hope that helps. Good luck!
Hi Natasha,
The SCORM limits aren't set by Storyline, but by the LMS standard - so there isn't anything that we can change to raise that limit. In terms of changing what Storyline sends it's dependent on what you include in your course and you can see the suggestions here for ways to look at changing that set up.
Hi, I've been getting with the line
"strSCORMErrorDiagnostic=cmi.core.suspend_data may not be greater than 4096 characters, your value is 9565 characters"
in the debugging file due to exceeding the number of characters imposed in the SCORM1.2 which is the only standard I can use in my LMS. This error is causing that bookmarking is not working so users sometimes have to retry again slides they already visited. Also some users are getting sometimes disconnection issues messages saying "Error- unable to acquire LMS API, content may not play properly and results may not be recorded."
And finally yesterday I found this thread and put in practice some of the strategies that are discussed here and yay!!!! I fixed it.
What I did was this:
1.- I changed the name of the objects, elements, text boxes to smaller names. Instead "Text_Box_#" I am now using "T#". Same for Markers now are M1 or M2, etc. I just simplified all the names.
2.- Deleted the unused variables.
3.- Reset as many slides as I could to "reset to initial state".
4.- I have a quiz bank of 48 questions where I randomly draw 10 questions. I changed titles of the questions to images to reduce text as much as possible. In every question I had text with the instructions such as "you have 2 attempts" I changed those titles for images with the text that I did from a print-screen before deleting the text. I think this is not necessary but I did it anyway.
5.- Put the SCORM in SCORM Cloud activating first the debug mode. I did the training and then when I checked the debug file I don't have the error line anymore....yay!!!!
Cool. :) Glad the thread helped you.
Didn't know your #1 and #4 would work. Thanks for sharing!
So while folks here are trying to figure out how to live in the size limit imposed by standards conformance, it is my view this is solving the wrong problem.
I would recommend you engage the LMS Vendor to resize the Core_Lesson or Suspend_Data attribute in their database to a much larger size. If the vendor will not do that, change vendors.
Compressing of the tracking data is a bad solution as it increases by orders of magnitude the complexity of supporting e-learning content that is showing tracking problems because the suspend data is not readable. Sooner or later you bump into a size limit if the course gets too big. When the data is not compressed you can compare data from a person who completed the course to someone who has not completed the course. Storage is cheap.
We support AbilityLMS where it's database was increased to support much bigger sizes and Articulate is like the John Deere commercial where Articulate produced courses just work and when we see Articulate technology we know there will be not be any support problems in tracking. I also much prefer for the course developer as a best practice to use expressive variables as someone has to support the course after the developer has moved on, of if it has been some time since the developer worked on the course, Text_Box# is a lot more expressive than T#.
It is simply a poor excuse by the LMS vendor not to be willing to increase the size of these fields. It is not an issue in standards conformance, it is an issue in supporting the customer.
One word of caution in SCORM CLOUD is the fact it is a stable and controlled environment. It is not the real world of your users running the training at peek times, when anti-virus or some other process jumps the CPU to 100%, when users have 30 browser windows open and all the other things users and local environments do that might introduce instability into the operating environment. There is a place for SCORM CLOUD for sure; however, the better LMS vendors support real-time logging of all course to LMS communication.
Hey folks, was running into this same problem and tried numerous things mentioned above to try and get the suspend data below 4096.
So, after much reading it turns out that if you do knowledge checks using the Articulate Quiz template and you don’t explicitly say “reset to initial state” on each one then it saves hundreds of characters toward that 4,096 limit.
We set all the KCs to reset (since they are not marked quizzes) and we no longer got the error in debug. Now if y'all could program the default to be "reset to initial state" instead of automatically decide and then saving the resume state automatically, I think you might have less people stressing over this. Also if there's a way in the community to show the most recent posts first so one doesn't have to read dozens of posts before finally getting to the solution.
Because these posts are kind of old, can anyone update me on this issue? Is it fixed yet? Thanks.
Hi, Becky! I wouldn't use the word "fixed." Just the nature of Storyline and the potential of a lot of resume data being sent to LMS for bookmarking. Things are still the same. Storyline can potentially track a lot of things depending on how you've designed things.
If you use SCORM 1.2, see if your LMS honors the 4096 character limit for SCORM resume data or has an override. Some LMS's (e.g., Moodle) have an override and let the content running in the learner's browser to send more than 4096 characters and will store all of it for bookmarking when the course is re-launched by the learner.
Or use SCORM 2004 3rd or 4th Edition or Tin Can/Experience if your LMS supports it and supports it in a way you like.
If you're stuck with SCORM 1.2, look in this thread for some recommendations on how to reduce resume data or look the Articulate KB article: https://articulate.com/support/article/exceeding-scorm-suspend-data-limits
Or make your courses smaller or use multi-modules.
What I did to address the issue was to make sure all my slides or at least the majority are configured as "reset to initial state" rather than "automatically decide". Just this change fixed it for me. The other day I developed a super long course in Rise and I was getting the issue. In this case, I had to chunk it into 3 smaller modules and problem solved :D
Another option that might work in some situations is to divide your course into two pieces--the main content and the final quiz.
Put the main content on a web server outside the LMS. Then folks can access it whenever for performance support.
Then just put the quiz in the LMS. Tell folks that access the main content that they have to pass the quiz in the LMS to get completion credit.
Remind those accessing the quiz they need to review the web content first before attempting the quiz.
Not an ideal solution by any means but it is a possibility.
Hi All, I don't know if we've ever seen a solution that has improved this yet over the years. I totally follow and get what everyone is saying.
Something new is now rearing it's head. Articulate Rise - which we don't know how it layers and we don't know what version updates they do to the software because it is cloud based. The problem is back.
I build a 30 page course. I completed it to 100% but when i go back in to use it as a resource it only shows i took 71% of the course. Perfect case that i can recreate.
So everything above is back again and now we don't even know and are guessing what is going on in the versions of the cloud based software.
Problem is not the authoring tool is saying do this and the LMS's are taking the brunt of possible lazy design or coding.
Thoughts.
Hi All,
I don't know if this is my problem or not. Admittedly, I've never heard of suspend data until now. I have one course loaded into Docebo that isn't really all that large but does have a ton of layers and only 1 learner is having an issue with it. After he retries the quiz a few times, it returns him to a slide in the middle of the module and it is like he hasn't ever started. I tested in SCORM Cloud and I can't reproduce the error. The client is ticked off but I see no issues with the module itself and Docebo says it isn't them. Could it be this suspend data that you are all talking about? I need something to take back to them. Please help!
Great question, Nora!
Suspend data could be the problem, and here's a good article on how to isolate whether or not it really is! If you need a hand with the testing and troubleshooting process, please reach out to our team and we'd be happy to take a look!
Hi Doug,
I had this problem once and it got resolved by changing all my slides and layers to "reset to initial state". that fixed it for me.
I appreciate your advice but I've tried this where possible. The base
layers must stay Saved State due to variables. This hasn't helped so far.
Thanks for the feedback.
Nora
Nora.
Did you publish as scorm 2004? Because that is pretty much the only solution. Until articulate fixes their compression. My gut says it’s a fight between lms not letting more through and authoring getting lazy on compression until we all get frustrated and force them to fix it. Which ain’t gonna happen.
only other solution may be to make smaller file or don’t worry about the bookmarking after you complete. Hit that threshold. Funny thing is we don’t know when or what page it’ll hit the limit.
I’ve used scorm 1.2 for since 2001 and never had problems until last year. Never used 2004 until then. It solved the problem. Cmi5 and tin can will resolve it as well as they handle bug data very well. But reporting is way different. But worth time.
thoughts. I have more thoughts and suggestions maybe pm me.
No lazy design here, Doug! The actual battle is between:
You're absolutely correct in identifying SCORM 2004, xAPI, and cmi5 as the solution(s). Thanks for helping out!
Hello all,
If most suspend data threads are saved (when tested across devices and browsers), then the logic is working.
If there are occasional problems, it is likely that the suspend data thread is corrupted due to a loss of connection between the client and the server, while the client (the learner using the courseware in the browser) had continued to navigate through the course.
I suggest developing JavaScript that runs in the Storyline client, and that pings the server, and saves the suspend data thread each time the learner navigates from one screen to another. If the "ping" returns a message that the server is not found, then message the learner that they should close the browser, and re-launch the course. It should (all else being equal) re-launch from the previous screen.
This is a suggestion, others please join in. If this doesn't make sense, please post your reasoning.
Thanks!
Robert
Robert Edgar
Program Manager, Learning Systems Design and Development
Director, Stanford Redwood City Digital Production Studio
Stanford | University Human Resources | Learning Solutions Group
485 Broadway, University Hall, 3rd Floor, Room U309
Redwood City, CA 94063
Cell: 650-387-5914
rbedgar@stanford.edu
Visit Us Online: Learning Solutions Group
Stay Connected: Cardinal at Work Connect
See Our Studio: https://redwoodcity.stanford.edu/campus-resources/srwc-digital-media-production-studio
Robert,
Not all of us are proficient in JavaScript to be able to utilize this type
of high-end coding solution. I really need something that I can apply
either within Storyline or within the LMS without having to resort to
outside custom solutions. I'm not trying to be offensive, I am just sharing
where I sit in terms of my expertise.
Nora
Hi Nora,
Oh, you are certainly not offensive.
This is a big problem for many though, and I offer this possible solution to those who might use it.
Best
Robert
Robert Edgar
Program Manager, Learning Systems Design and Development
Director, Stanford Redwood City Digital Production Studio
Stanford | University Human Resources | Learning Solutions Group
485 Broadway, University Hall, 3rd Floor, Room U309
Redwood City, CA 94063
Cell: 650-387-5914
rbedgar@stanford.edu
Visit Us Online: Learning Solutions Group
Stay Connected: Cardinal at Work Connect
See Our Studio: https://redwoodcity.stanford.edu/campus-resources/srwc-digital-media-production-studio
Hi Robert,
Pretty much what happens is the storage on the LMS or cache is where the limit gets hit. So it doesn't matter what you're doing. It is the volume passed, hit limit and then dead end.
Best way to see what is happening. Have a course of 10 slides. Complete go through, and it gives completion. The learner relaunches the course and shows up on page 7, the learner has to complete the last three pages to get completion, or it will show in progress. The server holding the bookmarking information is complete, so it will never let you fill pages 8, 9 and 10. That is the cmi limit or cap. This puts everyone into a looping effect where don't go back into courses, or if you do, it ends up starting on the page it maxed out at.
So your discussion of javascript, etc., is a moot point. Solutions are pushed to the 2004 standard and make the content smaller in volume to fit within the limit. The limit is stupid for 1.2. 2004 a bit better, and in a tin can/cmi5, it is fully open throttle. Your javascript would work great in tin can/cmi5.
Having said this, the LMSs and Articulate need to do better at compression. Lazy design in the systems is what is creating this headache. Not us designers, the developers. The funniest thing ever is why on earth would a command that is on 6 mg be so limiting when size doesn't matter. The intelligent thing would be for LMS or Articulate to design a code that would stretch that limit; not like we don't have the size now since we are talking exabytes of information.
Cheers,
Doug Kipta, CTDP.
Advisor, Learning Systems and Platforms | HR Learning Services | Suncor Energy Inc.
C: 403.296.8696 | C: 403.650.4722
dkipta@suncor.com
HR Learning Services Portal