“Just program it in HTML5.” “We are switching to HTML5.” “HTML5…HTML5…HTML5…”

Sound familiar? What does this cry for HTML5 mean for e-learning developers?

That Was Then

When e-learning was first gaining momentum (about 15 to 20 years ago), building courseware required some degree of programming capability: HTML and JavaScript to build a primary code base, ActionScript in Flash to create interactive objects and content, and a good knowledge of SCORM standards.

I would present at conferences and proclaim that attendees needed some of these programming skills. People would smile, shake my hand, and agree to learn more programming skills—and then they would hire me to create their programs for them. Simply, many instructional designers and facilitators charged with building e-learning were not interested in computer programming.

Fortunately, e-learning authoring tools came into prominence. Soon, everyone was an e-learning programmer. You simply opened PowerPoint, created a presentation, and clicked a button to have an interface wrap your PPT in a nice SCORM package.

And for a long time, many e-learning authoring tools exported solely to a Flash format, and the .swf files they generated required the Flash player for learners to view the content in a browser. This was great because the Flash player was already built into every desktop browser, so everyone could view the Flash content.

Voilà, your e-learning projects were complete! Check the box! Done!

This Is Now

In 2015, however, the Flash player does not function on mobile devices, and is even falling into antiquity, in some experts’ opinions. Instead, industry leaders are rallying behind the HTML5 banner. Led by Apple, the cry has sounded: “Flash is DEAD!” Meanwhile, programmers like me are saying, “Long Live Flash!” Why? Because e-learning “programmers,” who solely use authoring tools to build their courseware, are not able to create compelling e-learning interactions with the support of Flash.

Indeed, most companies are asking for HTML5 to become the standard, and traditional e-learning programmers are forced to comply. So, although the advent of authoring tools was a good way for companies to rapidly build e-learning libraries (because they made the “programming” piece of e-learning development as easy as creating PowerPoint slides), it’s not good when the standards start to change.

Here’s the rub: HTML5 requires developers to go back to being programmers. In fact, the same designers rallying behind the HTML5 banner are taking a collective gasp, asking: What do you mean my authoring tool can’t export to HTML5? For developers like me, it’s an easy leap back into the world of hand coding, WYSIWYG programming, and browser testing. Developers who have only used authoring tools, though, are probably going to struggle in this new world.

To be sure, several popular authoring tools now export to HTML5, but the consistency of the projects to work across browsers is still an issue. The authoring tools are getting better, but until a pure HTML5 authoring tool is available (they are coming!!!!), the best way to create HTML5 content is to code it specifically for the device used in your environment. Bottom line: The only way to properly create a solid HTML5 course is to hand code it yourself.

Basically, this means that industry has come full circle—back to programming our own e-learning courseware, back to web standards, back to structured programming. So, if you ran away from programming and hand coding (and into the arms of your favorite e-learning authoring tool), but are now on the HTML 5 bandwagon, you are going to face a huge learning curve.

For guidance on how to pair e-learning development tools with your own programming skills, check out Technology for Trainers, 2nd Edition. This updated ATD Press book guides technology-hungry trainers through e-learning development, with brand-new chapters on mobile devices, learning management systems, and e-learning development software.