Forum Discussion
SCORM 1.2 Suspend Data--Seems Wonky to My Pea Brain
Hi, Justin! :) Thanks for the detailed reply. Much appreciated. Also, please pass on my "thanks" to Engineering for considering my issue and taking the time doing so.
You've always been a great and knowledgeable professional to work with. And so is Steve. I really respect his expertise and knowledge, much as I do yours. So when Steve makes a suggestion like he does above, I give it a lot of weight.
I can't speak to his suggestion as he's far more knowledgeable on these technical things to me but it seems to have a lot of merit to me. So does Steve's suggestion have weight and possibility?
Also, Steve doesn't overstate the severity of this issue or the sheer hell it can put us folks in. Support requests for things like this can drain an organization and infuriate learners, learners' management, and course sponsors.
Or when you discover an issue like this at the 11th hour before releasing a course, it's a terrible and very stressful place to be as a developer as you have to scurry to find a solution and you need more detailed help.
I know that publishing to SCORM 2004 and Tin Can are probably the best solutions. No argument there. However, some folks can't use them yet--either their LMS does not support Tin Can or SCORM 2004 natively (like Moodle), or their LMS may not support SCORM 2004 "right" (like Saba) or Tin Can is not available yet for their LMS.
That said, I hope you folks, at the very least, can help us out more here. The KB article that you folks have here is a great start: http://www.articulate.com/support/storyline-2/exceeding-scorm-suspend-data-limits-sl2
But, IMVHO, we need more.
I'm not interested in how the proprietary algorithm works and even what all is stored. But, I'd like to know, as a developer, ALL the things that I could do in Storyline to try and reduce resume data.
Do too many layers on slides impact things? Layers on masters? Button or objects with many states? Does something like taking the answers in multiple choice or multiple select questions or interactions and making them just A, B, C, D, etc., and then add separate text boxes for the rest of the answers and then not randomizing answers, reduce resume data? Etc., etc.
You folks obviously know how resume and the algorithm works better than we do, so I'd like to strongly urge that you folks consider augmenting that KB article and provide detailed and comprehensive suggestions on how to possibly reduce resume data.
You could probably do that relatively quickly and it wouldn't involve possible software changes. How to design courses efficiently for AICC or SCORM 1.2 would a fantastic resource for developers to have in hand before starting a new course or in troubleshooting an existing one.
My initial post above lists some things to try. But I don't know if they are all valid or not. Or maybe if there are more things we can try.
We need you folks to do that. Would that a possibility? :)
One could make a cogent argument that, as you folks have increased the amount of data being sent with Storyline 2, you may have a responsibility to help us out more here. At the very least, again, document in detail all the things that we as developers can do to potentially reduce resume data when SCORM 1.2 (or AICC) must be used for a course and the LMS strictly enforces data limits per the respective specs.
Also, having things in more detail from you folks would help us when discussing things with clients. Telling a client that I have to change or remove or do something in a certain way because "I think" it may increase resume data and cause bookmarking/completion issues just does not have as much weight than you folks having something in black and white that I can refer to and show the client.
For the course I was working on, I saw the additional resume data for answering a quiz question or interaction vary wildly--from well over 400 characters per slide initially to over 200 characters per slide as I changed some things to over 100 characters when I created a new, vanilla version of the quiz.
That says to me that's it's clear we as developers can do things that influences the amount of resume data. We need you folks to help us out here. (And maybe strongly consider Steve's suggestion.)
Sorry for the long post. But after living with this issue for a long time, I'm a little bit passionate on this . . .