How to force the LMS to call index_lms_html5.html?

We want ONLY the HTML5 version of a particular course to load in the LMS (Cornerstone OnDemand). We are all good on how to output to HTML5 and we have tested the file locally. When we publish from Storyline 2 update 7 we get both the SWF and the HTML5 files in the output. I am guessing there are dependencies.

It seems, however, that we're going to have to do some manual editing of the manifest file and possibly some other files in the output in order to get the LMS to launch ONLY the HTML5. Before I try brutal hacks like removing the index_lms.html file or manual trial and error edits—does anyone know how to do this already?

UPDATE: One of my IDs has figured out how to work around the LMS and browser hiccups and force HTML5 to load in any compatible browser.
Not sure if this link will take you directly to his post (with screenshots) but if not, it's on page 3 of this thread. Thanks a million @BrettBerish.

https://community.articulate.com/discussions/articulate-storyline/how-to-force-the-lms-to-call-index_lms_html5-html?page=3#

Thanks to Phil, Steve, Mike and Ashley.

97 Replies
Aubrey Berish

Hey all, I think I have a possible solution on how to force HTML5. Instead of trying to restructure the SCORM manifest or other files (which LMSes can be quite fussy about) we're going to make the browser check think you're on an Android device. This makes Articulate's output go directly to it's HTML5 setup and not even try Flash.

This works on CornerStone for sure, kudos to Dave on finding the tucked-away setting to change. (I'll be pointing out where). I also tested in IE11 and desktop Chrome.

1. Publish your project from Storyline.

Have it set to LMS output, HTML5 turned on, iPad output turned off. Everything else configured as needed for your course.

2. Click "open" on the publish screen, then locate these two files.

(Leave the little publish dialogue box open, it'll be handy later.) You'll be editing story.html and index_lms.html, not the versions that say HTML5.

4. Open index_lms.html in an editor and revise this line of code

I'm using Notepad since everyone has it, but Dreamweaver and Notepad++ people go for it. We're going to change the 8th line in this file to say var g_bAndroid = true; here is a before and after.

Save and close.

5. Open story.html and revise these two lines

Same concept, we'll be changing the 51st and 54th lines of this file to say var g_bAndroid = true; and var g_bRedirectHTML5 = true; respectively. Before and after:

Save and close.

6. Zip & Upload to your LMS

This is why I suggested keeping the publish dialogue open, you can just hit Zip in there. Other zipping utilities, including the baked in Windows one, can do a folder-in-a-folder or have the zip name be weird, which can confuse some LMSes, CornerStone included

7. [Cornerstone Specific] Disable compatibility mode before final publish

Cornerstone just loves to hide lots of functions behind incredibly tiny unlabeled buttons. It's like an easter egg hunt, excellent user interface design! when you publish your project on the LMS, here's where the option hides.

 

Tada. Let me know if this works or doesn't, or if you know of simpler ways to accomplish this.

Steve Flowers

It should. There are a few different ways to handle the load redirect. The problem with scrambling layers is likely being caused by something else. The only time I've seen this problem is when a module had previously been loaded and run and attempted to run again. Clearing local cache fixes this problem.

Phil Mayor

Caching in some LMSs can be a really bad issue, when I worked for the Health Service over here they used some sort of local caching that meant if I updated a course anytime in the day and viewed it, and then updated it would never show the new version until the next day really made my life difficult.

Deb Bowden

My IT department just presented me with a long list of Storyline courses that will cease to work with an interim LMS due to .swf files. I've forwarded this thread about forcing the LMS to call the .html file, which they've been able to do. The problem is that, they say, all interactions and videos still exist as .swf files inside the published course. They're recommending I move all embedded course videos to Brightcove and use links instead AND, remove all interactions that require Flash.

Any ideas that will spare me having to rebuild everything?

Brian Allen

Deb, if your content has been published for LMS with the HTML5 checkbox selected then your courses should still function even if .swf files aren't supported by the interim LMS.

I would recommend testing with a browser like Chrome with the flash plugin disabled to find out for sure. If you test with the plugin disabled and your course still functions then you can be assured that your content will work in the interim LMS.

Here are some steps that might help you disable the plugin for testing - http://www.androidcentral.com/chrome-disable-flash

Drew .

I came across this thread after I found a solution that worked for me.  So I pass this on in case it helps someone else.

I edited the index_lms.html file and on line 9 changed

if ((g_biOS || g_bAndroid) && true)

to

if (true)

Thus it is always true and always runs html5.

This seems to work fine.

Drew

Sam Carter
Matthew Bibby

In some environments, yes.

But on the other hand, I have a couple of large clients who won't be moving away from Flash anytime soon for a variety of reasons. So options are good! 

 

Right. As do all of us. But as of now, there is no option for an HTML5-only client although Storyline does support a Flash-only client.

 

 

Matthew Bibby

Yeah I know Sam and I agree, a HTML5 only publish option would be good.

That being said, if Flash is not installed on the computers, then the published output will essentially behave as the same as HTML5 only.

There are no security issues that I am aware of that come from .swf's simply existing on a network and without Flash players installed, these files will never run. If you are aware of any, please let me know.

It seems to me at the moment there is a lot of fear and uncertainly regarding Flash, but I don't think it is as bad as some think.

Anyway, for the meantime it's not too time consuming to remove the .swf's manually for those who are particularly sensitive to this issue or have concerns regarding file size.

Brian Allen
Matthew Bibby

There are no security issues that I am aware of that come from .swf's simply existing on a network and without Flash players installed, these files will never run.

This is my understanding as well, and beyond the statement above, server admins should be able to simply remove the Flash mime type from servers. 

Over the past couple of weeks I've just sat back and marveled a little at the almost frenzied hype around this whole issue, discussions of going thru and removing .swf files from published output on servers, etc. 

It's a little crazy...

Matthew Bibby
Brian Allen

server admins should be able to simply remove the Flash mime type from servers. 

Good point Brian.

Yes, I know what you mean about the frenzied hype...

I think it is partly because of the misinformation in the media regarding the changes that Chrome are making. There are so many clickbaity articles floating around at the moment that essentially say 'FLASH WILL NEVER WORK AGAIN!!!', that it must be hard for people who don't understand the technical aspects to get to the truth of the matter.

At this point, I'm not concerned at all. 

That being said, I am looking forward to seeing Articulate continue to improve their HTML5 output, as it definitely is the way forward. 

Brian Allen
Matthew Bibby

That being said, I am looking forward to seeing Articulate continue to improve their HTML5 output

That, and as some have suggested having an HTML5-only option would be good as well.  I honestly can't think of any reason it wouldn't be doable on Articulate's side of things...

Matthew Bibby

The only reason that I can think of, is that the HTML5 output is not supported in all browsers and feature wise is not on an equal footing with the Flash output.

If an HTML5 only option is provided, then you run the risk that people will publish to HTML5 only (because "FLASH IS EVIL!") without understanding its limitations.

This would lead to a bad user experience, an increase in support requests and potentially damage Articulate's reputation. 

The more I think about it, the more I realise that the right call for Articulate at this stage may be to not provide an HTML5 only option.