Give us an "HTML5-only" Publish Option

I've seen the staff arguments that "HTML5 is still an emerging standard."

No. It's not. It was emerging in 2008. Now it's a standard and Flash is all but dead as it is rife with security issues and unsupported on the devices that real people use most. In December 2011 (the year Adobe abandoned mobile Flash), research firm Strategy Analytics forecast sales of HTML5 compatible phones would top 1 billion in 2013. We are among a growing tsunami of companies that are looking to eliminate Flash-based content and containers as soon as possible.

I've also seen the staff arguments that "HTML5 displays differently in different browsers."

News flash; so does everything else on the web. Let us deal with that. It's what we do. It's time to give us the option to publish as HTML5 only.

37 Replies
Matthew Bibby

Hey Dave, it would be a good idea if you submitted this as a feature request so the right people see it. 

I agree with you 100% that there should be an option to publish as HTML5 only and I'm sure many others in the community feel the same way.

You may also be interested in having a look at this white paper that Articulate released a while ago outlining their strategy for multi-device e-learning

Daniel Sposato (Philly)

I agree that there should be an HTML5 only option. And I would imagine they would be making that a top priority.

Though I have to point out that after recently finishing a year long project in Captivate 7 & 8, SL2 HTML5 output is wonderful! So many times I had to go back and literally recreate an interaction from scratch because an unidentified slide (that I had to find manually) would self destruct the entire publishing process. Also I remember trying to get a drag and drop to work just using HTML5, Javascript and CSS 3 years ago. What a mess that was! 4 different browsers displayed it differently and only got it to work in one of them. And I still had to compromise on the overall look.

I've been building interactions for my company with SL2 and I'd say less than 90% of them have had HTML5 publishing issues. From my perspective, I'm extremely happy with the output options! But look forward to seeing the options expanded.

Steve Flowers

Would prefer to see energy put toward making the HTML5 output accessible. Making an SWF-less publish is pretty easy in the current version. Takes less than a minute (20 seconds if you're quick or 5 seconds if you want to write a bit of batch script)

Here's a quick publish and scrub of swf's:
https://dl.dropboxusercontent.com/u/19820702/sans-flash/index.html

Here are the steps I followed:

1) Publish with HTML5 output as an option.

2) Rename the story_html5.html to index.html

3) Search the published output folder for *.swf. Select and delete the swf's. Careful not to delete other stuff in the story_content folder. There are dependencies in this folder that the html5 player uses to display content.

4) Delete the story.html file.

The swf's are goners and it's running for me. A little different process if you're publishing for LMS.

**On a machine with Flash player removed, the HTML5 version will simply run in the place of the Flash version. Launching story_html5.html (or renaming to index as above) will have the same effect.

While I think it would be great (and possibly trivial) to add an HTML5 only publish option, I'm not sure it's in my top 10 wants (maybe not even the top 100 given how simple it is to sweep out swf's for anyone offended by the presence of something that won't even be requested if the story_html5 file is launched).

In my top 10?

  • Accessibility in HTML5
  • JS and IDE exposed system and player variables (more of a real player API)
  • A fluid authoring timeline (oh, how I miss Flash and AfterEffects when building / syncing timeline elements)
  • Complete CSS control over player elements (would prefer the player theme be 100% CSS driven from a central CSS file, not embedded in a page and strewn about)
  • Trigger-based read / write timeline control (jump to time) and object property control (position, scale)
  • Suspend-data compression that doesn't blow up progress in SCORM 1.2 when the LMS 4K limit is exceeded
  • Portable captions (SVT, VTT) and a caption display element
  • Ability to add script elements to the head of the page (loaded once) and include js libraries in a spot that's easily referenced. This is the primary cause of post publish surgery in my case and I'd prefer not to have to do this <shrugs>.
  • Symbols / library objects (as in Flash, Illustrator, Tumult Hype) for reuse across a story.
  • Quizzing improvements like more consistent and flexible application of Master Slides (things don't always stay where I want them and often shift around between authoring sessions) and a more robust way of setting up remediation and retesting (like automatically removing questions already taken from a pool when retaking a section quiz and a sophisticated way of setting up "adaptive" paths without complicated chains of triggers)

I'm 100% sure that my preferred priorities don't line up with the dev team's. But I could be wrong:) 

Dave Howard

Did you miss the part about "eliminating Flash-based content and containers"? My post was not an ask for workatounds to manually point to different files and edit HTML and XML files. THAT was a different thread. Thanks anyway.

Sent from my mobile device. Please excuse brevity and mistypes.

Dave H.

Dave Howard

Steve, I was asking articulate to "Give us an "HTML5-only" Publish Option" They either will and join the no-Flash 21st century or they won't.

When I go back to work, I'll send your tweak recipe to our IT group and our security team to see what they think.

Sent from my mobile device. Please excuse brevity and mistypes.

Dave H.

Steve Flowers

Side-note: SWF's themselves aren't the security risk. SWF's from untrusted sources, like Java from untrusted sources (or hacked sources) accessed by a user from a machine with a vulnerable player / plug-in are the risk.  If the Flash player is turned off, these swf's won't load. They'll be pretty useless (and harmless). If the Flash player is still active, the risk isn't as much in the player as it is in the user falling prey to, or navigating to, sites designed to trap folks with low awareness (or reputable sites hacked to add swf's that'll exploit the vulnerability.) 

If the Flash player is removed from the machine, Storyline's launch file will redirect to the HTML5 output automatically. If the browser doesn't support HTML5, the launch will let the user know they're out of luck.

I gave two potential options in separate threads. One, to respond to the OP in this thread, lists a set of steps that can be taken to surgically remove SWF's from a web published output. The other, in the LMS thread, lists an option for editing the manifest file (literally a 30 second operation) to direct the LMS to launch the HTML5 output directly and bypass the launch file that loads the Flash-based player. In the case of editing the manifest file, there isn't a way for the LMS to direct to the user to the Flash-based output.  The files are there but there isn't a link to request the files. The swf and player will never load onto the client, like they were never there.

One downside of leaving the SWF content in the published package is the extra upload weight. SWF's not accessed are zero risk to a client machine and to the server. They aren't a worm or active threat. Certainly cleaner to remove them. But you'd probably want to run a search and delete and then run something like RELOAD editor to rebuild the manifest of resources.

Dave Howard

I recommend our security blog.
http://www.welivesecurity.com/

As I said in my original post, Flash is unavailable on the devices 78% of connected humans use to access online content. Why so much crossposting?

Sent from my mobile device. Please excuse brevity and mistypes.

Dave H.

Ashley Terwilliger-Pollard

Hi Dave,

It looks like Steve and others have you covered here - and as Steve mentioned if you publish with the HTML5 option enabled, you users will be able to access it on the devices as mentioned here in the system requirements. 

I know lots of folks have shared their thoughts on an HTML5 only option - and that's certainly a sentiment we've shared with our product team, and that users have submitted as feature requests which you're welcome and encouraged to do so here as well.

If you're referring to multiple threads with in regards to the cross posting, users are welcome to start a new thread at anytime if they don't find something that matches what they're looking for or if they just choose to start a new thread. Staff monitor the entire product forums so that we can pop in when and where appropriate and also look to the community at large for assistance. Not knowing if community members have seen a particular answer, our answers can sometimes look repetitive but we just want to make sure folks have all the information that they need.