Flaw in Storyline's implementation of iOS html5
Oct 27, 2015
After banging my head against a brick wall with Articulate's customer support, I'm hoping someone in the community can help me out.
I have an 1100 x 800 module that displays an annotated reprint that works fine on a PC or Mac in a scrolling window, but always "shrinks to screen size" on an iPad when viewed using html5 output. That won't work for this module because when the window shrinks, the reprint is unreadable.
I asked Articulate support why Storyline insists on forcing the shrinking, but they won't tell me what the problem is. A programmer friend tells me it looks as if it's something within webkit but can't work out how to modify it.
Does anyone have any idea what is happening and if there is a workaround? I don't want to have to go back to Lectora unless I have to, but at least they generate REAL html5 output!
Thanks for any help you can give me!
7 Replies
I can't say for sure without seeing at least a screenshot but it sounds like a viewport issue. Essentially, unless you define the viewport size for iOS it will scale the content. If you define the viewport width and height you're aiming for in the meta tags the content should fill the screen.
The Configuring the Viewport article has all the details on making these adjustments.
Hi Steve
Thanks for the reply - unfortunately I've been there and done that - Storyline overrides the viewport. My frustration is that the support people won't tell me what they did!
Rob:
I think the default choice for most developers is to not control the viewport but to allow automatic scaling. As the vast majority of web sites and apps would be best scaled, the developer needs to go out of their way to override the default behaviour and specify dimensions.
Which leaves it up to us to add specific code to override the default scaling (if this is, in fact, the problem). Storyline is probably using the default scaling behaviour 99% of developers likely want and should be using in most cases.
What should work is adding the required viewport meta tags into the generated HTML page(s) manually. Give that a go, upload the modified files, and see if it fixes the issue.
Hi Steve
Yes, we've done that - if you change the viewport in the story.html5 file it momentarily allows the enlarged module to appear but then js kicks in and forces it to shrink again. My developer put a js trace on what was happening and was able to locate that it is a WebKit problem - he tells me it's a CSS rule controlled by webkit-transform: translate3d, but we can't modify that.
I may be one of the few developers wanting to create a scrollable window, but there are other things at work here. Articulate tells us they don't support gestures in html5 - wouldn't zoomable content be a great feature? Obviously they have programming problems with doing that, so I guess they've just disabled scaling - maybe if you allow scaling you'd have to allow gestures, and that would perhaps break SL - it would be nice if they'd come clean and tell me what is happening and why!
That certainly looks like a brick wall. Sorry I couldn't help more.
Rod, was that the only problem? The file doesn't run on the right size but all the animations are working? Is there any problem with the images or the menu settings?
I've been having problems with the html5 version in several online courses, including published courses. They've been showing these sort of problems for a week now.
Did anybody try the old html5 version of older courses? Did they show any problems or errors?
Let me know, thanks.
This is the only html5 problem I've hit. BUT I'm wondering if the problem is that Articulate are using some weird "non-html5" kludges to make their code work on iPads. That would explain why using gestures and scaling would break whatever they've done. It would also explain why they won't say what the problem is ... maybe it would open a can of worms!
This discussion is closed. You can start a new discussion or contact Articulate Support.