Problems with HTML5 output and LMS

Hi,

Apologies in advance for the length of this post, but I'm trying to be thorough.

I've just run a battery of LMS tests with a six-slide Storyline course.  The course, if this matters, was imported from Studio and then modified in Storyline.  The summary is that saving and restoring works properly in every desktop browser I've tested, using the Flash-based output, but saving fails using the HTML5 output on the iPad, Safari and both the PC and Mac versions of Chrome.  These tests were all run inside our home-grown LMS, which has been online for years (and which, I will admit, is not perfect, and I suppose could be the source of the problems, but that's not what the evidence suggests at present).

I ran the following tests:

1.  Launch unstarted course, complete course in one session

2.  Launch unstarted course, stop halfway through, then resume to the end in the same browser

3.  Launch unstarted course in one browser, stop halfway through, then resume on another browser to the end

I tested using Safari6, Chrome23, Firefox16 on OSX Mountain Lion, IE9 and Chrome23 on Windows7, and IE7 on XP.  I also ran Mobile Safari on a third generation iPad running iOS6.  I launch all courses in a new window from the LMS.  "Completion" in my course is determined by # of slides viewed--for this test, 6 out of 6 tests.  Course was published using SCORM2004, version 2.

Results:

TEST 1:  All Storyline output formats, browsers and devices passed this test.  That is, in any of the above configurations, if you started a course anew, and completed it in a single session, state was properly tracked back to the LMS.  More specifically, an LMSCommit() command was fired back to the LMS when the last slide loaded, and that command told the LMS that the course was complete.

TEST 2:  The combination of desktop browsers + Storyline Flash output passed this test.  All browsers tested against the HTML5 output, however (iPad, Safari6 and Chrome23) failed this test.  More specifically, the course launched properly the first time, saved properly at the end of the first session (by just closing the browser window), and then restored to the proper slide when the second session was launched.  I was able to continue on to the last slide of the course during the second session, but once I hit the last slide of the course, no LMSCommit command was fired back to the server.  Moreover, if I closed the course window, an LMSCommit command was fired off to the server, but that command did not say the course was completed.

3.  This worked in all cases, except if the course was restored to the HTML5 version of the course, in which case it behaves just like case #2, above.  For example, I could launch the course on the iPad, quit, then resume on IE9 to the end, and the course would mark complete.  However, if I started the course on IE9, then resumed on the iPad, it would restore to the right slide, but the course would not mark complete.  Just to make sure this problem wasn't limited to the iPad, I launched the HTML5 version in both Safari and Chrome, and witnessed the same behavior.

So it seems like something is wrong with the way the HTML5 version is "counting slides", at least on restores?  Has anybody else encountered this?  Obviously, this is a show-stopper, so I'm certainly hoping that I'm just doing something wrong.

Also, and I don't know if this is relevant, but just in case, any time I launch a previously unlaunched enrollment with the HTML5 version, I see this screen first:

The title of the course appears above the "Play" button, and an image of the first slide appears to the right, but I've removed those for privacy issues.  So I have no idea if this screen is related in any way to the issues I'm seeing, but I'd sure like to not have this slide appear.  Any way to make that happen?

Thanks in advance,

Ben

42 Replies
Ben Mueller

Update here:  I've run a few more tests, just to make sure I'm not missing something obvious.  For this test, I launched an unlaunched enrollment of the course on the iPad, in Firefox (viewing the Flash output), and Safari (viewing the HTML5 output).  I quit the course at the same slide for all three versions, and the LMS recorded the identical string in all three cases, which is:

1A6405060on1001012f0101101111010120000

I can't begin to understand what that means, but the fact that all three cases record the same data back to the LMS seems like a good sign, and suggests that the save mechanism in both versions of the course, and my LMS as well, are behaving properly.

Another test:  I reduced the # of slides required for completion from 6 to 5, on the assumption that perhaps the HTML5 version of the course was mis-counting the slides as a result of the restore.  Alas, this did not solve any issues.

Peter Anderson

Thanks for the post, Ben. Interesting stuff. Curious to know if you get the same results when you run your course through SCORM CloudIt would help us determine if the issue is Articulate-related or if it's on your LMS's side. If it appears in SCORM Cloud as well, we'd be happy to take a closer look at what might be going on. But if you can't replicate the issue in SCORM Cloud, it's probably an issue that you'd want to take to your LMS team. The articles here and here may also help clear up common LMS issues.

Let us know what you come back with. Thanks again!

Ben Mueller

I'll have a look at SCORM Cloud now.  


While I don't doubt that it's possible the problem may lie with my LMS, I'm not sure quite where the problem might sit, given that the Flash-based version of the course behaves just fine.  My assumption (perhaps incorrect) is that the Flash-based version and HTML5-based version behave identically w/r/t to LMS.  Are there differences between how the two versions communicate with the LMS?  I also find it puzzling that the HTML5 version correctly restores to the proper slide, regardless of where it was initially launched.  If it *didn't* restore to the right slide, then one could make a good case for the LMS munging the data load.

Anyway, I'll report results back.

Ben Mueller

Okay, I've confirmed that it's not working in SCORM Cloud.  I'm seeing the same behavior as my tests above.  I opened a support ticket earlier today, and uploaded both the original .story file as well as the course output.  To recap:  if I run through the course in one sitting, then it's marked complete in SCORM Cloud; if I stop partway through and resume, then it resumes to the proper slide, but does not mark complete.  

If it's useful, I can post the SCORM CLoud logs here.

Ben Mueller

Hi Angel,

That's not quite the issue I'm seeing.  The course runs properly on the iPad regardless--it just fails to send the proper "course complete" command when the user has actually completed the course, as I outlined above. 

Once the course has actually been completed, then it doesn't have to send a "complete" command back to the LMS, and so the condition you outline isn't an issue.


Ben

Ben Mueller

Hi all,

I wanted to update the forums at large here.  The Articulate support team was able to confirm the bug I reported, not only with the file I sent them, but also with a new file they created.  They've sent it off to the QA team for further investigation.

This bug is a major show-stopper, at least for me, as it renders the HTML5 output of Storyline useless, and therefore negates one of the major reasons to use Storyline in the first place.

Peter, whatever pressure you can bring to bear to get a quick resolution to this issue would be much appreciated.  I'm dead in the water until this can be resolved, and my bosses are going to start asking sooner rather than later about alternatives.

Thanks,

Ben

Peter Anderson

Thanks for the update, Ben. I'll make a note in the QA file that this is a time-sensitive matter for you. I can't give you an exact timeline on when this may be fixed, but I assure you that that they'll work hard to get it resolved ASAP. I'll let you know as soon as they have. Thanks again for your help bringing this issue to our attention.

Ben Mueller

Hi Peter,

I wanted to check in on this issue.  I haven't heard anything from the QA team on progress regarding this bug, nor anything regarding a timetable for a fix.  I'm not sure whether Articulate was shut down for the holidays or not, but obviously this is still a rather pressing issue for us, as it still has us stopped cold in our tracks.  Any nudge you can provide towards a solution, or even towards getting more information on the status, would be great.

Ben Mueller

Thanks.  It's appreciated.

I'm sort of surprised this hasn't come up elsewhere (or if it has, I've missed it).  Seems like a pretty spectacular show-stopper, and therefore one that I would expect would generate more hand-wringing than I've seen to date.  Do most Storyline developers deploy courses which they expect users to complete in a single sitting?

Garry Nordenstam

Ben Mueller said:

Thanks.  It's appreciated.

I'm sort of surprised this hasn't come up elsewhere (or if it has, I've missed it).  Seems like a pretty spectacular show-stopper, and therefore one that I would expect would generate more hand-wringing than I've seen to date.  Do most Storyline developers deploy courses which they expect users to complete in a single sitting?

There appears to be some significant SCORM issues with the HTML5 output. I've had an open case that has been duplicated by Articulate Support and Rustici Support in which the course unexpectedly sends an LMSCommit and exits the course. That's also a show stopper for me regarding HTML5. I reported it in early December.
Ben Mueller

Hi Peter,

I'm checking in with both you and Jayem again.  It's been over a month now since I first brought this issue to Articulate's attention, and to date I have had no formal confirmation whatsoever as to whether Articulate officially recognizes this as a bug that needs to be fixed (which, in my opinion, it most certainly does), or anything about a timeline as to when it will be fixed.  We need to start hearing formal assurances that Articulate intends to resolve this issue.  Is there anything more you can do?

Ben Mueller

I wanted to update the status of this issue, and do a little ranting.

It's been over a month since I brought this very serious bug to Articulate's attention, and as of today, all I can get out of the Articulate team is that they have replicated the bug, but have no time frame for when or even if they plan to fix it.  This is simply unacceptable.  This bug is bad enough to render the HTML5 component of Storyline 100% useless.  If that component is useless, then the entirety of Storyline is useless.  Flash is most definitely not the future, so why bother investing in a platform that can only output Flash?

Articulate needs to provide actual, candid answers so that its customers can make actual, concrete plans.  We are in a really awful holding period right now where we are being asked to hope that maybe Articulate will decide to someday maybe fix this bug.

Ben Mueller

i got some more concrete answers from support early this afternoon.  The bug has been confirmed and they are hoping to release a fix as part of their next update.  There is no specific date for the next update, but Articulate did just release an update on December 14, 2012, so the next one probably won't be for 3 months or so.

Peter Anderson

Hello all,

You may find that your LMS shows a status of Failed or Incomplete for an Articulate Storyline course—even though the learner completed it—when all the following conditions are true:
*  The course is being tracked by the number of slides viewed.
*  The course includes HTML5 output.
*  The learner started the course, exited before completing it, and later resumed and completed it.
*  The learner viewed the HTML5 version of the course.
This issue was corrected in Update 3 for Storyline. Please review the following article for more information:
Ron Orme

Ben Mueller said:

Hi,

Apologies in advance for the length of this post, but I'm trying to be thorough.

I've just run a battery of LMS tests with a six-slide Storyline course.  The course, if this matters, was imported from Studio and then modified in Storyline.  The summary is that saving and restoring works properly in every desktop browser I've tested, using the Flash-based output, but saving fails using the HTML5 output on the iPad, Safari and both the PC and Mac versions of Chrome.  These tests were all run inside our home-grown LMS, which has been online for years (and which, I will admit, is not perfect, and I suppose could be the source of the problems, but that's not what the evidence suggests at present).

I ran the following tests:

1.  Launch unstarted course, complete course in one session

2.  Launch unstarted course, stop halfway through, then resume to the end in the same browser

3.  Launch unstarted course in one browser, stop halfway through, then resume on another browser to the end

I tested using Safari6, Chrome23, Firefox16 on OSX Mountain Lion, IE9 and Chrome23 on Windows7, and IE7 on XP.  I also ran Mobile Safari on a third generation iPad running iOS6.  I launch all courses in a new window from the LMS.  "Completion" in my course is determined by # of slides viewed--for this test, 6 out of 6 tests.  Course was published using SCORM2004, version 2.

Results:

TEST 1:  All Storyline output formats, browsers and devices passed this test.  That is, in any of the above configurations, if you started a course anew, and completed it in a single session, state was properly tracked back to the LMS.  More specifically, an LMSCommit() command was fired back to the LMS when the last slide loaded, and that command told the LMS that the course was complete.

TEST 2:  The combination of desktop browsers + Storyline Flash output passed this test.  All browsers tested against the HTML5 output, however (iPad, Safari6 and Chrome23) failed this test.  More specifically, the course launched properly the first time, saved properly at the end of the first session (by just closing the browser window), and then restored to the proper slide when the second session was launched.  I was able to continue on to the last slide of the course during the second session, but once I hit the last slide of the course, no LMSCommit command was fired back to the server.  Moreover, if I closed the course window, an LMSCommit command was fired off to the server, but that command did not say the course was completed.

3.  This worked in all cases, except if the course was restored to the HTML5 version of the course, in which case it behaves just like case #2, above.  For example, I could launch the course on the iPad, quit, then resume on IE9 to the end, and the course would mark complete.  However, if I started the course on IE9, then resumed on the iPad, it would restore to the right slide, but the course would not mark complete.  Just to make sure this problem wasn't limited to the iPad, I launched the HTML5 version in both Safari and Chrome, and witnessed the same behavior.

So it seems like something is wrong with the way the HTML5 version is "counting slides", at least on restores?  Has anybody else encountered this?  Obviously, this is a show-stopper, so I'm certainly hoping that I'm just doing something wrong.

Also, and I don't know if this is relevant, but just in case, any time I launch a previously unlaunched enrollment with the HTML5 version, I see this screen first:

The title of the course appears above the "Play" button, and an image of the first slide appears to the right, but I've removed those for privacy issues.  So I have no idea if this screen is related in any way to the issues I'm seeing, but I'd sure like to not have this slide appear.  Any way to make that happen?

Thanks in advance,

Ben


Did anyone come back regarding the picture here showing the Play button? Is there a way of automatically playing?