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.
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.
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.
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.
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.
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.
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
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”.
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
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).
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.