Wednesday, December 14

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.

8 comments:

Kelly Meeker said...

This is great insight into the "clicky clicky bling bling" trap - designing media to take advantage of available technology, rather than designing interactions or tasks and then assessing the technology needed to support.

Steve said...
This comment has been removed by the author.
Steve said...

I really like this discussion. One of the things I think we are leaving out of the discussion is the opportunity to challenge our assumptions about content packaging and change the defaults from the standard framed linear presentation to alternative modes. We've worn ruts in this framed template pattern.

You alluded to this in your final sentence, I believe. Our jobs are bigger than simply maintaining status quo. The opportunity to shift the mindset and update our expectations to better match the problems at hand is huge. Much bigger than an update of content or the litany of conversations that surround changing from one technology to another. In my mind, that really doesn't change much of anything for the better if we don't think more about how we apply the new technology in better ways than we did the old one:)

eeellama said...

I think the transition from Flash to HTML5 could come more quickly than expected in some IT environments where they have tired of constantly updating the Flash player. In those companies where updates are not optional and have to be done quickly for compliance reasons, and where IT dollars are being squeezed, you may find that companies will gladly drop Flash support if a viable option exists.

There are also economic forces within the eLearning tools industry that will also see HTML5 as a competitive advantage, and this will hasten the move away from Flash creation tools. New tools drive new sales, and HTML5 promises to provide reasons for lots of updates down the road.

Contract eLearning designers could also benefit if companies need to re-create courses quickly because of corporate decisions to drop Flash from desktops.

I don't see this scenario happening overnight, but clearly Adobe is seeing that they need to be on the HTML5 bandwagon quickly, and that it is possible that Flash's days are numbered.

Kevin Mulvihill said...

Extremely well said, Judy. Thanks for sharing an excellent post!

Judy Unrein said...

Thanks for your comments, Kelly, Steve, eeellama, and Kevin, and you have no arguments from me on any point!

eeellama, I saw the same thing from IT departments when I was internal (them hating supporting Flash), but it's not a point that has resonated with all of my audiences so I don't normally bring it up. I'm glad to hear someone out there has had the same experience!

Steve said...

Ugh... The Flash player is one of **many** things IT support staffs don't like to update. But the verb support is kinda the bread-and-butter of IT support, no? As an IT guy, this isn't because it's a hard thing to do. It's not predictable and the announcements that trigger the update abruptly sound like the sky is falling. At this point... it's one of those old hat tasks that you take on 10+ times per year. It's not complex to accomplish and IT IS NOT JUST FLASH that requires update. Most of these updates can be centrally pushed.

Lots of folks love to hate Flash. Some of this hate is justified. The rest is just riding the coattails of the justifiable reasons.

Most folks would be hard pressed to make a business case for discontinuing Flash player support. It would be foolish to suggest it or to propagate this as a possibility at this point. We still support the Authorware player on our image for backward support of content that was built 15 years ago. I expect nothing different with the Flash player on the desktop.

moncler jackets said...
This comment has been removed by a blog administrator.