Storyline 1 - HTML5 output LMS issue with suspend_data
Jul 30, 2015
Hi,
We are using Storyline 1 update 8, we've set the player to Never Resume and we use our own JavaScript code to store the course progress within the LMS. If running the course via Flash all works fine. If we disable the Flash plugin and run in HTML5 storyline stores it's own course progress within suspend_data in the LMS, the standard encrypted way which we don't want and our JavaScript is ignored. The reason we don't want the encrypted progress stored within the LMS is that it makes future updates impossible, as if additional slides are added it corrupts the users progress and corrupts the course.
Does anyone know how to stop the player in HTML5 storing progress data within the LMS in Suspend_data and make the JavaScript triggers work as they do in Flash?
40 Replies
UPDATE: I have just found out a work around for us.
We were changing variable values on slides and checking the value on the master slide and then executing a JavaScript trigger. We have changed checking the value from the master slide to the slides and now the JavaScript gets triggered every time. It still stores data within Suspend_data but we now use lesson_location so all is good.
I appreciate you popping back in to share your experience and findings with the community Marcus :)
Hi Leslie -- I'm running into this bug as well, and it's a dealbreaker for us with respect to using HTML5 output.
We use SL2 to develop our online assessments which we publish to our LMS as SCORM 2004 v4 packages. The flash output sends item-level interaction data to our LMS via the cmi.interaction method exactly as expected. In HTML5, all that data is being dumped into the suspend_data bucket, which gets compressed/obfuscated.
This destroys our ability to perform item-level analysis on our assessment data, and puts us in the unenviable position of either publishing exclusively to flash (thus excluding some of our learner base and un-future-proofing our assessments) or hobbling our feedback and evaluation loop.
Please let me know when this will be addressed!
Hi Sam! I do not have a timeline to provide, but I do appreciate your sharing and I will add your feedback to the QA report and discussion.
Hey, all.
I'd like to clarify if perhaps we have two different issues being discussed here, and also dig into a better understanding of the impact of those issues:
Loving seeing this level of technical expertise in this thread, and looking forward to your feedback. Thanks!
Hey, Justin -
In the original poster's context, he was wanting to use suspend data for his own purposes. Storyline was overwriting this in HTML5, preventing his custom implementation from working.
For the latest post, I haven't seen this particular problem. Interactions have written pretty consistently for me across the board.
Hi Justin and Leslie. First off, thank you both for your responses! I agree there's a bit of conflation of issues going on here, but I honestly think they're both related. To clarify, I have also specified not to use suspend_data/resume in my HTML5 output, and I'm seeing that field being used anyway. My suspicion is that interaction data is going in there, too, in lieu of using other communication methods.
Justin, your second bullet point sums up what I'm finding quite nicely. I tested in SCORM Cloud and saw none of the item-level information being sent for each quiz question when viewing the session logs. Instead, there were some basic score sets calls being sent and then a SetDataChunk call that modified the suspend_data bucket.
Running in debug mode corroborates this finding. Here's a snippet of scorm communication for one interaction. I'd expect to be seeing interaction data passing between the module and the lms here.
Thanks for the information, Sam.
Can you please send us a copy of your .story project file so that we can test for reproducibility of this behavior?
Case #00878049 written and submitted! Thanks Justin.
Steve, your input is always appreciated. Glad you aren't seeing this issue!
To be honest, before this issue I hunted the forums to solve other problems I was having with my HTML5 output too, to no avail. So maybe my version is...off somehow?
(Specifically, I ran into an issue where I had to rewrite and move off-master some custom JS calls running in my module in order for them to work in HTML5, as the operating scope of my HTML5 module apparently differed from the Flash version. Oddly enough I had to remove the var lmsAPI = parent; and var player = GetPlayer(); lines from my scripts and that seemed to do the trick. I've seen other forums [graced by your presence!] say custom scripts should work interchangeably between flash and html5 with no rework required. Weird!).
It could have something to do with SL's specific implementation of the SCORM version I'm using w/r/t HTML5, as 2004 v4 is way less commonly implemented than say SCORM 1.2. Steve, not sure if you've tested quizzing in html5/scorm 2004v4 specifically.
Thanks again, Sam. It looks like Miker grabbed your Case, and I will follow along as well.
I've had lots of trouble with 2004r4. But I suspect my problems are LMS related. Dropping back to 2004r3 solves the issues I typically see within our LMS.
Hi Justin,
Our problem was, we create our courses with a custom menu and using JavaScript store the status of each topic in the suspend_data. When re entering the course the user would see their progress on the menu. In html5 though the suspend_data is being overwritten by articulate storing it's own progress, which means the users progress is lost and very unhappy people.
We have 80+ courses, so this was a big issue. A couple of big clients were stopping their users using flash so we had to move over to html5.
We found a work around by using lesson_location to store this data, but we are limited with the amount of data we can store. we're using SCORM 1.2.
Thanks for confirming, Marcus. This helps to understand the depth of impact of this issue.
Hi folks,
Wanted to circle back here after the fine people on the Articulate QA team got back to me with a working output.
It appears I need to eat a big slice of humble pie here, as it was my own custom tomfoolery in the lms.js file output that was preventing interaction data from posting correctly in HTML5.
I had made a customization to the lms.js file to pass in a custom Storyline variable for the interaction ID, which helps us better identify questions during item analysis. The customization I made worked in flash but failed silently in html5, inadvertently taking the entire BW_StoreQuestionResult command out with it. I had to edit the scope/namespaces of that bit of code the same way I did for my other JS triggers to get it working in HTML5 again.
Thanks everyone.
Great catch, Sam. So glad you got this working!
This discussion is closed. You can start a new discussion or contact Articulate Support.