Storyline 1 - HTML5 output LMS issue with suspend_data

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
Marcus White

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.

Sam Hammond

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! 

Justin Grenier

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:

  1. As originally reported by Marcus and confirmed by Steve, Storyline's HTML5 output is submitting suspend_data to the LMS even when the course is set to never resume.  Storyline is properly honoring the "never resume" setting, but the consensus seems to be that we shouldn't be sending the suspend_data at all.  Marcus and Steve, can you please help me understand the impact of this suspend_data being sent to the LMS?  If the course is still (not) resuming as expected, what specific problem is this causing for you?
  2. As amended by Sam, his team can't perform item-level analysis on assessment data because Storyline's HTML5 output communicates suspend_data to the LMS in a compressed, non-human-readable format.  I really want to dig into this one, Sam:

Loving seeing this level of technical expertise in this thread, and looking forward to your feedback.  Thanks!

Steve Flowers

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. 

Sam Hammond

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.

395:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SetScore, intScore=0, intMaxScore=100, intMinScore=0
396:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In ClearErrorInfo
397:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In IsLoaded, returning -true
398:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In IsValidDecimal, strValue=0
399:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning True
400:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In IsValidDecimal, strValue=100
401:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning True
402:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In IsValidDecimal, strValue=0
403:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning True
404:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Converting SCORES to floats
405:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Calling to LMS
406:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_SetScore intScore=0, intMaxScore=100, intMinScore=0
407:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_ClearErrorInfo
408:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - SCORM2004_CallSetValue strElement=cmi.score.raw, strValue=0
409:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_GrabAPI
410:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Grab API, returning, found API = true
411:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Calling SetValue
412:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - strResult=true
413:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning true
414:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - SCORM2004_CallSetValue strElement=cmi.score.max, strValue=100
415:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_GrabAPI
416:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Grab API, returning, found API = true
417:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Calling SetValue
418:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - strResult=true
419:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning true
420:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - SCORM2004_CallSetValue strElement=cmi.score.min, strValue=0
421:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_GrabAPI
422:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Grab API, returning, found API = true
423:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Calling SetValue
424:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - strResult=true
425:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning true
426:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - SCORM2004_CallSetValue strElement=cmi.score.scaled, strValue=0
427:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - In SCORM2004_GrabAPI
428:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Grab API, returning, found API = true
429:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Calling SetValue
430:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - strResult=true
431:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning true
432:Fri Aug 26 2016 10:18:52 GMT-0700 (Pacific Daylight Time) - Returning true
433:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In SetDataChunk strData=2_dc607090a0b0c0NM101101112C01011011111101110111111011011111101112~2s2g00000000000000001^1^1^1^1^1^1^1^1^1^1^101010101010101010101^1^1^1^1^d Sam Hammond1^1^1^1^7id_cert14131^1^11111^2O0z6c6sklNc8zi.6B2Mev0hcpe.5petu4U7qh81^1^0~2ha~2v1cb101001a1a103cz0Q34003400340034003400340097E0001l1^550090344034003400kj2cne970020111^3400021000~2S343000~2R1cb1010210101136K0~2r1340034003400660001^3400d690o0_000101^d690o0W200101^f79020o00000111^f79020o0Y100111^3400340002110~2Q1cb1010210101120v~2r1340034003400660001^3400f79030o0U000111^d690o0Q200101^d690o00000101^f79020o0S100111^3400340002110~2U1220~2N1cb101021010133Bmc~2p1340034003400660001^3400d610o0Z200101^d610o0x400101^d610o0$100101^f71020o0r000111^34003400000ga705040800000000ga203050400000000a6002010000ymc0308070a090205000b01000000000000pga0605010b070302000000000pg001020304050607000000000me403020800010500000000ga705060103000000a600102000020040cMd0
434:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In ClearErrorInfo
435:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In IsLoaded, returning -true
436:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In SCORM2004_SetDataChunk
437:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In SCORM2004_ClearErrorInfo
438:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - SCORM2004_CallSetValue strElement=cmi.suspend_data, strValue=2_dc607090a0b0c0NM101101112C01011011111101110111111011011111101112~2s2g00000000000000001^1^1^1^1^1^1^1^1^1^1^101010101010101010101^1^1^1^1^d Sam Hammond1^1^1^1^7id_cert14131^1^11111^2O0z6c6sklNc8zi.6B2Mev0hcpe.5petu4U7qh81^1^0~2ha~2v1cb101001a1a103cz0Q34003400340034003400340097E0001l1^550090344034003400kj2cne970020111^3400021000~2S343000~2R1cb1010210101136K0~2r1340034003400660001^3400d690o0_000101^d690o0W200101^f79020o00000111^f79020o0Y100111^3400340002110~2Q1cb1010210101120v~2r1340034003400660001^3400f79030o0U000111^d690o0Q200101^d690o00000101^f79020o0S100111^3400340002110~2U1220~2N1cb101021010133Bmc~2p1340034003400660001^3400d610o0Z200101^d610o0x400101^d610o0$100101^f71020o0r000111^34003400000ga705040800000000ga203050400000000a6002010000ymc0308070a090205000b01000000000000pga0605010b070302000000000pg001020304050607000000000me403020800010500000000ga705060103000000a600102000020040cMd0
439:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - In SCORM2004_GrabAPI
440:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - Grab API, returning, found API = true
441:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - Calling SetValue
442:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - strResult=true
443:Fri Aug 26 2016 10:18:53 GMT-0700 (Pacific Daylight Time) - Returning true
Sam Hammond

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. 

Marcus White

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.

 

Sam Hammond

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.