HTML5—What’s the Urgency?

I’m starting to get some questions along the lines of, “We’ve been hearing we need to switch to HTML5 delivery, and we’d like to be forward-thinking, but why and when should we do it?”

Those are really good questions; thanks for asking!

Some companies need to deliver content on iPads now. In that case, there is urgency to consider something other than a Flash-based solution. One option may be to deliver that content through (VPN) access, like Tom Kuhlmann wrote about on the Rapid E-Learning Blog a few months ago. The same post covers some publish-to-video and -PDF options. If those don’t suit your needs for interactivity, you’ll probably want to check out some of the existing HTML5 authoring tools.

For companies that aren’t planning to deliver content to mobile devices any time soon, there may not be that much urgency, and it might be difficult to understand why you would want to switch to HTML5 delivery at all. If you don’t have issues with your current technology, it’s even more difficult to explain without getting into ideological discussions (including the ever-popular Why HTML5 Will Kill Flash/Why HTML5 Will Never Kill Flash debate). You can find plenty of that elsewhere on the Internet and we’ve promised not to re-tread that topic here, so just a few words in the service of answering the question…

For me, it mainly comes down to recognizing that browser plug-ins came along largely to fill a very real gap in web technology; HTML wasn’t initially built to deliver rich multimedia. But that gap is closing fast with the capabilities of the HTML5 stack of technologies, and I have more faith in the community of companies, organizations, and individuals that keep pushing web standards forward than I have in the individual companies that develop proprietary plugins. I don’t think that plugins are evil; I simply don’t think they are the way of the future. Your company may choose to produce content in Flash or Silverlight or Quicktime and your desktop/laptop users will be able to access it as long as the company supports that technology, but when introducing new devices into the mix, your need for more widely-accepted technology will likely grow.

So, if you are considering a change to HTML5 delivery for future-proofing, my advice is to take a hard look at your needs and the existing software options and be willing to wait a bit if necessary. The authoring applications that are available now either aren’t as powerful or aren’t as compliant as some of the tools to watch that I mentioned in last week’s post. So if you buy something now, I think there’s a good possibility you’ll end up with:

• software that’s not powerful and flexible enough to meet future needs,
• software for which you’ll have to spend a lot of time testing the output (which you’ll have to do to some degree anyway), or
• software that doesn’t take advantage of as many modern HTML5 features as you might expect.

That’s not to say that existing software isn’t good, but more competition would accelerate and further development. I think we have a little way to go before the market is mature enough to have lots of solid contenders for your software-buying dollar. And you may find yourself using combinations of tools more than you have in the past, as well.

In some ways, this whole situation feels a little like the tail wagging the dog, doesn’t it?

It’s seemed like, for years now, that the learning industry has had delivery figured out. Now limitations on that have us scrambling for new tools—some of which might not even meet our needs. There’s a good chance you’re going to be in the market for a new authoring tool or two soon, so I think it’s a good time to take another look at what strategies your tools support.

This is a huge conversation, but the issues I do want to mention that are on my radar more and more these days are reusability and revision of content. One of the cool things about HTML—5 or otherwise—is that the published output is viewable, changeable code (rather than an object inside of a plug-in), that’s easier to manipulate, even without native files. That’s the kind of openness that can promote greater reusability and easier revision, at least in a manual workflow…though if revisions are a huge factor in your company’s workflow, you might consider tools that handle that programmatically.

I hope this has cleared up a few things and, yes, opened a few cans of worms, as well. One of the things I’ve been privileged to experience over the last couple of years is that this conversation over delivery technology—seemingly a small part of what we do and already debated to a pulp in the Flash vs. HTML5 Ring of Death—has opened up for me much larger conversations about design strategy, semantics (in a good way), accessibility…the list goes on. And we need to have these conversations. I’m as game for a good Articulate Studio vs. Adobe Captivate conversation as the next person, but we also need to remember that our jobs are bigger than that. Much bigger.

Let’s discuss.

Judy Unrein designs learning solutions at Artisan E-Learning, blogs at E-Learning Uncovered and onehundredfortywords, and tweets at @jkunrein.