Make the Move to HTML5? Everything You Need to Know to Have the Conversation

From time to time, I write things that get picked up by Magazines. In this case, I put together a series of thoughts for developers & companies looking to make a move from their existing Flash applications to HTML5. We deal with this subject just about every day, and are working with a variety of well known brands who are in the midst of the transition.

The published piece was edited quite a bit to keep it brief and formatted for print. I decided to also publish the full version here on my site because there is some decent information that might be of use as people find themselves having this conversation.

Original edited version published in Website Magazine, October 2012 as “The Flash to HTML5 Evolution”.

First, some background…

The question on the mind of just about everyone that has a role in managing aspects of a Web site is whether or not to move towards implementing new features or migrating to HTML5.

Before a real discussion over front-end Web technologies can be had, perhaps it makes a bit of sense to provide some context to put things into perspective.

HTML5 is a long overdue evolution of the Hypertext Markup Language. Hypertext, as a technology, has served as the face of the modern Internet since the early 90’s when unfettered Internet access became a consumer alternative to online services like AOL and Prodigy.

The problem with HTML was that it didn’t offer “that feel” that made consuming content on a computer match the expectations of users.  Let’s face it, HTML was invented to provide basic markup to the visual style of text displayed on your computer screen, provide a technical mechanism in hyperlinks that allowed developers to link different pages of text together, and in 1993, the Mosaic Web browser gave us a way to view images inline with the text on a page.

From that point forward, we’d see a consistent push forward to make HTML provide more and more features so that Web sites could eventually emulate the types of experiences that users desired and that content creators aspired to create.  Rich Internet Applications emerged for a reason – the combined force of user experience designers and technologists worked to push the capabilities of Web UIs forward to meet the evolving demands of users, leading to the ability to create web-based applications that could provide more robust, single-screen, and immersive user experiences.

At the time, HTML wasn’t the capable of accomplishing these goals. Macromedia (Adobe) released Flash MX and later Flex, providing the development tools and single content runtime engine (The Flash Player) that could be used to render applications on the Web in a fashion that could.

With HTML5, We’ve now come full circle, and the technologies that started the RIA evolution seem to be slipping away into obscurity, being  replaced by more powerful iterations of HTML, JavaScript and CSS.

As someone that has conversations with clients, software partners and others in the industry almost every day about Web and Mobile application design and development, I don’t think there has been a hotter topic of conversation since the MSIE 3 vs. Netscape battle back in 1996.

Oddly enough, the premise of that historical conflict is actually very reflective of the conversations we are having today – What UI technology is best for the Web?  When Microsoft introduced Internet Explorer 3, the primary message about the browser and the technology packed within it was that it had a more sophisticated way for developers to add interactivity to boring, flat and static Web content. By creating ActiveX controls and using either “Jscript” and JavaScript, Web pages now had the promise of coming alive with video, screen transitions, and the negation of any need to navigate from page to page to view content or perform a task.  Microsoft also introduced style sheets to the web in the form of .CSS, which was really quite revolutionary for developers who struggled with how to build scalable, visually appealing Web sites.

Microsoft fought their way from a nominal browser market share to being the dominant Web browser in the marketplace with the release of IE4.  The new strategy was that Microsoft would provide a free version of their Browser on every version of Windows they shipped, and in doing so would heavily influence the way Web site UIs were developed, as most users relied on their software to view content.

 

Let’s fast forward…

When Steve Jobs announced Apple’s backing of HTML5 and his disdain for Adobe Flash for Web content on Apple iOS devices, it sent an undeniable message to designers and developers – the times are about to change, and you are going to need to change with them.  The media storm that ensued

Apple’s iPad devices dominate the tablet market. The demographics of iOS mobile phone users are hard to beat. Whether you are an Apple fan or not, you have to acknowledge that when your business builds a mobile or tablet-accessible application in today’s marketplace, you must do so in a way that it works properly on the iPad and iPhone.

With Jobs’ public call for a push towards HTML5 instead of Flash, just about every software company was forced into having the conversation. The HTML5 specification had been debated for quite some time already, and while far from being finalized, the necessity to push the Web another step forward was suddenly upon us.  The ensuing panic resulted in everyone from Chief Marketing Officers and Executive Board Members to Web site designers and developers asking the same question, “Do we need to migrate to HTML5?” (Or, as one less-than-savvy businessman I overheard in an airport put it “Should we HTML5 ourselves?”)

HTML5 doesn’t necessarily change the types of user experiences we can create on the Web. HTML5 doesn’t provide anything new from a design or interactivity level (from the perspective of end-users). HTML5 is a question of implementation and support for more interactive features on specific types of devices and provides better options to reach all users with a parity in experience regardless of what computing device they choose to use.

HTML5 doesn’t change the “What” of the Web. What it does do, however, is change the “How”.

HTML5 impacts the way that Web sites will be built and provides for yet another option to developers when implementing features on a Web site. Like any technology, HTML5 is a tool, and every tool makes sense in the right circumstance.  We’ve been seeking ways to create better user experiences and more engaging Web content for well over a decade, and until recently the only way to achieve those goals was to rely on plugin technologies, namely Adobe Flash or, more recently and less successfully, Microsoft Silverlight.

As these plugins become more robust, so did the capabilities of the browsers. The advances in HTML’s capabilities and the concept of Asynchonis JavaScript and XML (AJAX), combined with the increase in the power of computer processors meant that browser-based content could be rendered more efficiently. With the advent of modern Web browsers that are able to leverage graphics acceleration and other tie-ins to computer hardware, something that required a plugin in years past, it is now possible to provide much more compelling user interfaces and web-based interactions using standards-based technologies.

What does it mean to you and your efforts? Do you need to upgrade your Web site to HTML5? When? Why? Why Not?  How?

This is a question that our teams at Roundarch Isobar answer frequently for our clients. Whether they be a global travel services company, a major paid cable network, large financial or government institutions or fashion and lifestyle brands, they are all seeking advice on what direction to take, and how to best approach any transitions that may be necessary.

 

Top 5 Reasons why you should possibly consider moving to HTML5 in the near term

1) Your Web site has interactive features, including video, and you can’t shut out iPad and iPhone users:  This is the most obvious of all reasons to make a move to HTML5 sooner than later. You are in the business of providing content, and some of your most desirable users are being shut out because the plugins required to display content just won’t work on their devices.

2) You want to be able to create a Web application once and allow it to render across a variety of standards-compliant devices (Phones, Tablets, TVs, Computers): Long gone are the days of creating different sites for the myriad of different devices that access your content. Using responsive design tactics, it is possible to create an interactive, HTML, CSS and JavaScript Web site that displays properly across device channels, reducing the overall cost over time for development and maintenance of the site. When trying to reach as many users as possible, don’t forget that most every Internet connected computing device produced today can support HTML and JavaScript.

3) You are driving interactive experiences from a content management system and/or rely heavily on dynamically generated and rich user interfaces:  Your site is more than just static content display. You provide access to data or give users more functionality via Web based tools. Perhaps the only way to accomplish this in years past was to use a plugin like Flash or loads of JavaScript that your development team managed to make work using 3rd party JavaScript libraries.  HTML5 will likely provide you the ability to offer parity in user experience with a reduction in overall development effort and allow any savvy Web developer to make updates instead of leaning on someone with skills specific to any 3rd party tools or technologies.

4) You have a Web site that relies on a 3rd party plugin like Flash or Silverlight to render. Don’t feel bad – You didn’t make a mistake when you made the decision to put your entire Web site inside the plugin renderer. You aren’t alone in that you can’t see the future.  A couple of years ago, the best way to achieve a really robust user experience was to follow this model, and you couldn’t have predicted we’d end up where we are today. Without a plugin, your site doesn’t even render for users and instead of having a hybrid UI design that incorporates some Flash or Silverlight (or even Java Applet) features, the entire page is rendered inside the Plugin.  It may be time to make the move.

5) You are ready to completely overhaul your Web site:  Are you ready to reinvent your Web presence? Do you want easier coding, more powerful form controls, local storage, more robust scripting and general development techniques, better inclusion of metadata and lower cost maintenance of media (video)?  While sites created in HTML, CSS and JavaScript will render ok for your users, some of the real benefits of HTML5 are in the way things are implemented at a code level. You can do more with less, and that means less maintenance cost over time coupled with a better user experience.

 

Top 5 Reasons why you might consider holding off for a while 

1) Changing Standards mean what you create today might need to be updated going forward:  If you’ve been building Web or mobile applications for any amount of time, you’ve likely suffered the consequences of early adoption.  Breaking new ground doesn’t come without risk, and while the HTML5 specification’s primary features seem to be fairly solid and have agreement from members of the W3C committee responsible for oversight, that doesn’t mean that they can’t (or won’t) change, possibly breaking your early implementation.

2) HTML across browsers (old and new) can mean more investment towards development to reach your entire audience:  While the promise of all of HTML’s new features seems appealing, there is the reality that the tools used to create HTML and JavaScript are generally less robust than their plugin-based counterparts. This includes out-of-the-box and 3rd party UI components as well as debugging tools. In addition, you shouldn’t be naive and assume that the all browsers will work equally as well with your new HTML5 code. Remember, this is all a work in progress, and in order to ensure your Web site works in Chrome, Firefox, Safari, IE, Opera or other browsers means that you need to test in each, and then adjust your code as necessary. The beauty of Flash or Silverlight was the notion that the application you created would render the same in any browser (or even as a desktop application).  This can (and generally will) add additional time and expense to your Web site development and support efforts.

3) There is a learning curve related to HTML5: With any technology a poor implementation can lead to a buggy and annoying Web application that will drive users away.  Is there a learning curve? Yes indeed, and depending on your own level of experience (or that of the developers you work with) it can be challenging and time consuming.  In many cases you and your team are too busy trying to keep the lights on, and investing a lot of time learning something new isn’t always practical.

4) Your Web application might use Flash or Silverlight, but it’s not designed for mobile users and you’ve already got a lot invested in it: This goes back to being sane about your technology decisions. Just because you have the option to migrate an application to HTML from Flash or Silverlight, determine first whether or not the effort is worth it right now. If your application is intended to work primarily on big screens (aka desktops/laptops) and mobile and tablet users aren’t your intended users, then it might make sense to hold off and see what else emerges over the next year that might make a move like this a bit less painful.

5) Your Web site provides content not appropriate for HTML5 at this time. This could go in two different directions – More likely of the two, you’ve got a Web site that provides mostly text and image content, very few interactive features and no need for advanced processing of data or visual elements. In a less-likely, but equally applicable situation, your plugin-based application still can’t really be achieved using HTML5 at this time – you’ve designed and built something that performs really well inside Flash or Silverlight and even with HTML5 and CSS3’s next-generation features, would still be challenging to replicate.

Some tools, tips and tricks to ease the transition

Understand what HTML5 Is – And what HTML5 Isn’t: Knowledge is power and educating yourself on the differences between the HTML5 specification, JavaScript and CSS3 is a critical first step in making the decision on which route to take when advancing the technology used to enable your Web site’s user experience.  The attention the subject of HTML5 has received seems to have added quite a bit of confusion to the conversation – Not everything new is actually HTML5, and many of the experiential things that can be accomplished in user interfaces today don’t actually require an implementation of HTML5.

According to the W3C, “CSS is the language for describing the presentation of Web pages, including colors, layout and fonts”.   The W3C also adds, “The separation of HTML from CSS makes it easier to maintain sites, share style sheets across pages and tailor pages to different environments. This is referred to as the separation of structure  (or content) from presentation.”

The key word here is “separation”.  HTML is for structuring pages and CSS is for presentation of content. They aren’t the same, but they are equally important.  The news rules behind CSS give designers and developers a great deal of control over layout, UI animations and other cool features that might be mistaken as “HTML5” by the less informed.

As one of the UI gurus I work with on a daily basis put it, “The biggest wins with HTML5 are tooling and hardware acceleration.  CSS3 will get you some incredibly powerful user interfaces without causing your computer’s hardware to be used, forcing your CPU to get hot and kick on your fans”.

Before you proceed with your HTML5 journey, understand the differences between HTML5, JavaScript and CSS and how you might be able to accomplish a unique user experience by picking the right tool for the job.

Get Over the Learning Curve: If you do decide to take the dive, Start by reviewing the new HTML5 specification and working to understand what items are new, and what legacy items have been depreciated. Once you have a general idea, then get to work – Practice makes perfect and the only way to practice coding is to, well, write code. Follow tutorials, work to recreate aspects of your existing application in HTML5 and get some nice battle scars. The good news is that HTML5 is here to stay for the foreseeable future, so your efforts won’t be wasted like they could be on more proprietary technologies. http://dev.w3.org/html5/spec/semantics.html#semantics

Don’t get cut up by the bleeding edge: Design a user experience that works, and then determine what technology you need to use to enable it. Don’t think that everything you want to do must be accomplished using new HTML5 elements. JavaScript, HTML and CSS are pretty powerful tools in the right hands. Not everything “Rich” is HTML5 – study up and understand the specification and implement something that works best in your own situation. You don’t have to become a victim of buzzword bingo. Users won’t care what tools were used to create your application, but they will care if it doesn’t work well or meet their expectations.

If you need to move away from a plugin-based approach to content delivery like Flash or Silverlight, but you also aren’t ready to take the risks that HTML5 may bring with it, then you do have HTML4/JavaScript-based options.  Not only can you leverage existing HTML and JavaScript knowledge, older browsers will still support your Web site. That is especially important if you are in the business of enterprise Web development, as many companies still use IE6 or 7.

Instead of relying on the latest & greatest, lean on a more proven technologies that will give you the improvements you seek, but with less risk. Try leveraging JavaScript libraries like Google’s AngularJS (angularjs.org/), EXTJS and/or Touch from Sencha (http://www.sencha.com/), Backbone (http://backbonejs.org/), Twitter’s Bootstrap (http://twitter.github.com/bootstrap/), Mootools (http://mootools.net/), etc, etc.  You can still enable support for IOS devices, and reduce the frustration of users who can’t access your content without fully reinventing the wheel.

To further expand on this, you should also investigate the implementation of polyfills.  A polyfill is a piece of code that provided the technology that you might expect a browser to support natively, but doesn’t.  To support newer techniques and value added by HTML5 in older non-compliant browsers, you can turn to resources like “HTML5 please” (http://html5please.com/) or this collection on Github – a grouping of “shims, fallbacks and polyfills in order to implant HTML5 functionality in browsers that don’t natively support them (https://github.com/Modernizr/Modernizr/wiki/HTML5-Cross-Browser-Polyfills).

Or, pull out all the stops and try cross compiling:  Oh yes, cross compiling: The holy grail of software that never actually works the way you really hope it would. From a computer science perspective, it’s understandable – This is not that easy to pull off and you shouldn’t expect a magic in-out solution to convert your existing Flash, Flex or Silverlight app to HTML.  You might get a decent head start though.  While imperfect at best, you can always be daring and try leveraging tools like DartFlash (http://blog.dartflash.com/) which describes itself as “an implementation of the Flash API and is using the Dart programming language. This language is very similar to ActionScript 3 and avoids all of the hassle of JavaScript.”  While in it’s infancy, this could be promising. While Adobe themselves haven’t yet released a final version, they do offer a pre-release tool referred to as “Wallaby” (http://labs.adobe.com/technologies/wallaby/), which can translate basic Actionscript to HTML.

Remember the Fonts – With HTML5 comes CSS3’s @font-face feature, which allows developers to include custom typefaces on the web in an accessible, manipulable and scalable manner. The benefits include full searchability, accessibility to screen reading devices and much easier internationalization/multi-language support.  Just remember – those fonts your company uses in print aren’t free, and in order to use them within your Web site or application you will likely need to pay licensing fees. Make sure to work the cost of any custom fonts into your project scope and don’t let this fact catch you a week before you launch the site and have already blown your budget!

Know the limitations of a “build for everyone” approach – One of the benefits of using a plugin technology like Flash or Silverlight is that your application UI generally looks the same regardless of what device it is running on. Implementing that killer user experience using HTML techniques will give you the advantages of reaching a wider range of devices, but be sure that everyone involved in your project understands that some concessions will likely be necessary when comparing specifics of the UI across the various browsers that you intend to support.