Blurry HTML5 Output in Zoom Regions

I've seen posts dating back two years about how images exported by Storyline 2 to HTML5 are blurry. I've seen the response that this is because images in HTML5 are not vectorized. One only needs to look at the images in the exported "mobile" folder of  a SCORM package to know that this non-vectorization is not the problem. Storyline is exporting images that are blurry, smaller than they should be, and highly compressed. Storyline does this even when publish image quality is set to 100%. It does this when image dimensions are higher than the dimensions of the stage, but not higher than the 2048px maximum images dimensions.

When Storyline passes an image that is already blurry to HTML5 as input for HTML5 to render, it is not HTML5's fault. HTML5 cannot improve the bad quality of the images that Storyline is passing to it. When will this major defect be addressed?

25 Replies
Leslie McKerchie

Hi James!

I just wanted to quickly pop in and welcome you to E-Learning Heroes!

Your post has created internal conversation and testing. The QA Team has also been reached out to for further clarification as well.

So, I do not have a response at this time, nor do I have any kind of timeline to share - but I did want you to know that your comment was received and being looked into.

Ashley Terwilliger

Hi James,

I discussed this with our QA team, and this is currently by design. Let me explain a bit further. Storyline will always conduct a certain amount of compression especially with media files. When you also include the option for mobile we look to further optimize it for issues you may encounter with memory and speed. 

In your situation, if you're inserting an image that is larger than the overall story size, but smaller than the maximum image size you'll see it scaled on publish (looking in the mobile output folder) to match the story size. That is what I saw when testing out the scenario you described above and also shared with our QA team. The zoom regions will cause further blurriness based on the documentation here. 

I hope that helps clarify, and if you have further questions feel free to let me know. Also you can always share your thoughts here in regards to the change of the behavior as a feature request. 

James Bertelsen

It does not help clarify. Storyline still distorts images beyond recognition in its export process, and you're telling me this is by design. Do you know how I've "solved" this problem without having to redo all my work? I preview in Storyline, record the animation using screen recording software, export to MP4, and display that instead of the native Storyline animation. MP4 is not vectorized. It looks excellent, and is reasonably well compressed. Make excuses if you like, but I see them for exactly what they are.

James Bertelsen

Based on further analysis, and referencing the attached files, here is what is happening.

1.     Start with a stage that is 720 wide.

2.     Embed images that are 2048, 1024, and 720 wide and zoom in on the image.

3.     Export to SCORM

4.     Flash export (in the story_content folder) exports images that are 1440, 1024, and 720 wide.

5.     Flash 1440 zoom looks good. Flash 1024 zoom looks OK. Flash 720 zoom looks unacceptable.

6.     HTML5 export (in the mobile folder) exports images that are all only 720 wide. All zooms look unacceptable 

So it would appear that the problem is that the HTML5 zoom never exports an image that is wider than the stage, but the Flash zoom exports images that are up to twice as wide as the stage.

As an entirely separate issue, because Flash uses vectors for shapes, the rectangle and text contents look good in the zoom.

Storyline does not support this feature for HTML5 exports, and so the rectangle and text do not look good in the zoom. 

It appears that if Storyline just used the Flash-exported images, which can apparently be exported at least twice as wide as the stage, instead of using the HTML5-exported images, which Storyline inexplicably limits to the width of the stage, this part of the HTML5 zoom blurriness problem could be resolved.

Ashley Terwilliger

Hi James,

Thanks for sharing the additional information and a copy of your file. I was discussing it with our QA team when this came in and we were going to ask to see a copy of your file as well so that we could try and understand what you were seeing. I'll be in touch after we've had some time to review it, so I appreciate your patience and understanding as we seek to look at what you're describing and comparing it with elements of how we'd expect it to behave. 

Adele Sommers

Kudos to James for pointing out the details of this egregious issue. I've just encountered it myself, but not in the context of mobile devices. Now that some browsers, such as Chrome, are eliminating support for Flash — or more people choose to disable it — the problem will appear with more frequency on desktop computers.

For example, a client of mine recently reported some Storyline anomalies that were visible only because his browser does not have Flash enabled, so he was unknowingly viewing the HTML5 version on his laptop. This means I'll now need to troubleshoot HTML5 as vigorously as I do Flash, and modify the mechanics and aesthetics to suit both types of output.

Leslie McKerchie

Hi Adele!

Our team has continued our focus on HTML5 output and looking at ways in which we can provide HTML5 only or first - it's something we feel strong about and have committed a lot too going forward, but we don't have a date/timeline yet in regards to when that will be available. We will certainly keep folks posted once there is additional information to share. 

Adele Sommers

Thanks for your reply, Leslie — being able to render an HTML5 production that is aesthetically and mechanically equivalent to Flash should be one of Articulate's top priorities. The inexorable elimination of support for Flash is forcing the issue into the forefront for Storyline authors, as HTML5 will soon become a requisite delivery format for desktop computers as well as devices.

I know the Articulate team has made great strides in improving the look and behavior of HTML5 output. Right now, however, HTML5 output still seems "quirky" at best and buggy at worst. That said, it seems to me that this particular issue of zoom image quality should be relatively easy for the team to resolve, compared to some of the other HTML5 challenges. 

James Bertelsen

Since I don't want to have to do quality assurance checks on both HTML5 and Flash every time I export a course, I just disable Flash in the output SCORM package and then check the content in HTML5 only. It would be nice if HTML5-only were a Storyline export option, so I wouldn't have to go into the code every time to disable Flash.

Louise Gillespie

Hello. I have been trying to publish a file with zoom regions. 

It is hopelessly blurry when published as CD version. 

When I publish as SCORM with HTML5/Flash setting, it is clear on one computer and still blurry on another. Can you please suggest what settings may be contributing to this? I have attached the file. 

thanks. 

Ashley Terwilliger

Hi Louise,

Thanks for sharing your published output. Could I take a look at your .story file to see what you've set up and the publishing settings you were using? 

Also what version of Storyline are you using?

We still have an issue with our team for Storyline 2 as the zoom regions are blurrier in HTML5 than Flash. It's a difference in how our Flash and HTML5 players were built, as the Flash player can specify higher resolution images than necessary and Flash will automatically use them when a region is zoomed. The HTML5 player is rendering images at a given size onto a canvas, and when the region is zoomed, it can only use the pixels that were on screen and zoom those. 

With Storyline 3 and 360, we rewrote the HTML5 publish output to ensure a better experience and match to what you've come to expect in Flash. 

Louise Gillespie

Hi Ashley. I am using S360. I published the file as flash/html5 fall back. It is still blurry when viewed on IE11, although clear in Chrome. Unfortunately, we can't just tell learners to use Chrome as IE is the organisational default. The module will only launch in IE if pointing to the HTML5 file (not the flash one).

Also, frustratingly, it worked on SCORMcloud in IE, just not when it was loaded to our LMS (Success Factors).

We are trialling publishing it as HTML5/flash to see if that works. Can you please suggest anything that will help it launch in IE? I have attached the story file.

Ashley Terwilliger

Hi Louise, 

When you're viewing the content in SCORM Cloud and using IE - did is display blurry for you there? To clarify, when you're viewing it - it's only the IE output that is blurry, in SuccessFactors? But that's only allowing you to show HTML5?

My guess on SuccessFactors and IE is that it's blocking the Flash output, but also not allowing for the information to be passed to use HTML5. You can see a few troubleshooting steps and workarounds for this here.  

Do you know if you're seeing the HTML5 output in Chrome? 

All this info will help as I give it a test too - although, I'll be testing in SCORM Cloud I want to make sure I'm doing the same Flash vs. HTML5 set up that you have! 

Louise Gillespie

Hi again

The output is blurry in IE only. It is fine in Chrome and SF. the systems team can only point it to the HTML5 output (index_lms_html5.html), whether or not I publish it as HTML5_Flash or Flash_HTML5.

I haven't been able to update for a while. When I try to download the update, it says 'Failed to update' and that's all. Error message attached.

I'm not sure where you are based. I'm in Melbourne (Aus) so the time difference is making this a bit protracted. Is there a local support desk? It's not that I don't appreciate your help.... ;)

 

 

Louise Gillespie

Hello again

I have successfully installed the update and continue to have the same problems whether I publish as HTML5/Flash or Flash/HTML5.

I looked at the troubleshooting tips and can confirm that:

* I updated today so should capture the August change to Flash 

* the launch file already has the compatibility meta tag and code listed 

* compatibility view is already turned off

* it works in Chrome but this is not the default browser for our organisation (more's the pity)

I'd love any other suggestions you might have. Otherwise I think we're going to have to provide instructions about installing Chrome and just field the phone calls that will result (not a great option!)

Ashley Terwilliger

Hi Louise,

Sorry for the delays in responding - I'm US based (and so is the majority of our ELH team), and although we don't have an Australia based team our Support Engineers are available 24/7 here. 

I'll go ahead and open a case for you and that way our Support team can reach out to work with you one on one!