Flash vs. HTML5

HTML5 is hot.  The echo chamber is loud and everywhere you turn; blogs, social media, trade magazines, and corporations, are heralding it as the silver-bullet for everything—and more. It’s magical.

But what is the current reality of HTML5 for Advertising Agencies and their Digital Production partners? And what does it mean for those concepting and developing real client campaigns with real business goals? The question isn’t “Is Flash Dead?” But rather “What’s the best solution to this problem?” Both HTML5 and Flash are amazing solutions to our web executions, each with their own pros and cons.

Let’s Flash-back

It’s difficult to have this discussion without first looking at Flash and where it has fit into the picture for the past decade. After all, this is what HTML5 is slated to replace:

For the agency teams working on a digital concept for the next big campaign, targeting Flash as the development platform meant they could focus on the concept and creative rather than the technology.  Once Flash had matured, there was a solid track record of prior art showing that just about anything they could come up with was possible and could be built by the right production partner. And if there wasn’t a clear way, the best developers would come up with one. Papervision 3D was a great example of that. Flash did not have 3D capabilities built in, but the top developers in the community made it happen. And when they did, 3D in Flash was now possible in every browser on every operating system, immediately.

It was a great ecosystem for those involved.  Creatives could come up with big ideas and feel confident they were possible, without having to worry too much about the technology.  Developers were pushed to do some amazing work and often did amazing work on their own, which lead creatives to great new ideas.  One developer invents PaperVision 3D, another one figures out Augmented Reality Markers and next thing you know we have a live Big Foot interacting with you live on your webcam (www.livingsasquatch.com).

With any new project brief there are several things we want to look at to decide if it is a project we’d want to pursue. The core of which are:

1. How will we do it?
2. How much time will it take?
3. How do those two items compare to the available budget and timeline?

Budgets will vary, but timelines are rarely long enough.  Flash gave us the luxury of predicability.  We could predictably estimate the time a project would take and the development techniques used to achieve the end result were generally clear.  Rather than targeting and customizing a launch for a slew of unpredictable browsers, we are only targeting one platform: the Flash runtime, which will run with 99% consistency across all browsers.

And we knew that rarely would someone come to us with a crazy cool idea that wouldn’t be possible. Whether it involved 3D, user generated content, webcams, sound, microphones, interactive video, Facebook integration, or whatever other wild campaign ideas our partners or us dreamt up. It was rare that we felt limited by technology when targeting the Flash platform.

The HTML5 catalyst

Mobile has been the true driver of HTML5 on the desktop and elsewhere.  Without the success of the mobile platform, pioneered by Apple, then followed by Steve Jobs infamous words against Flash, the methodology of how sites should be built for the desktop would not have changed from 3 years ago.

Prior to mobile’s success, there have always been sites with requirements making them best suited for HTML.  They are easy to identify and usually are heavy on content, light on interactivity, animation, sound, and video.  Because these are generally simple sites, browser incompatibility tends to require minor work arounds and has limited impact on time and budget. On the flip side, for any site intended to be highly interactive, Flash was always the clear choice. Allowing you to develop freely, forgetting about browser compatibility.  However, now mobile is big and must be considered with most projects, and Flash usually isn’t an option on mobile browsers.

Is HTML5 the Flash Killer?

So here we are today where a belief has been manifested that HTML5 can do everything that Flash can do and it works the same across desktop and mobile. So Flash is dead?  An article on a popular blog was recently linked to in my twitter feed, it proposed a list of “7 Killer Flash sites that should be remade with HTML5 and CSS3.” (http://tnw.co/wJfrjm)

Unfortunately this isn’t a reality and articles such as this continue to spread a fallacy of HTML5 being the new answer for everything. It remains far more complex of an issue and HTML5 cannot do everything Flash can.  In reality trying to create these sites in HTML5 is more like “Mission Impossible” and most of them would need to be re-concepted from the ground up; with creative and user experience design that was tailored to HTML5′s capabilities.  Could the ’Ethan Hunt’ of HTML5 Development pull it off? Maybe in a few cases, but what would be the cost and what percentage of the target audience will be able to view the site?  I know that with Flash sites, most clients were unwilling to allow a site published in the latest version of the Flash player until it reaches higher that 95% penetration.  Will a WebGL site that 50% of your visitors can use really be acceptable?  And we’ll often get briefs for Flash projects that have as little as a two or three week development timeline. Good luck with that in HTML5.

Ironically, most of the cutting edge, Flash-like HTML5 sites you see these days don’t work on tablets or smart phones either.  They either use HTML5 features that aren’t available in mobile browsers (WebGL), offer poor performance (Canvas),  or the layout and user experience design does not work properly.  This is perplexing since the primary argument for dropping Flash is compatibility on Mobile.

The technology aside, there are other fundamental problems with trying to make one site fit all. Screen resolutions are all over the place. Can you really expect to design something for a  22″ desktop screen that will look good on a 10″ tablet (iPad), a 7″ tablet (Kindle fire) and 3.5″ screen (average smartphone)? You also may not want the same amount of content on your mobile site, as lots of people like to find necessary information quickly and prefer more immersive experiences on a large screen when they’re sitting comfortably.

Finally, you have the point-and-click world versus the touch-and-slide; this will affect everything from the size of a button (you’d make it larger for a finger than for a mouse cursor) to the user experience (sliding through a photo gallery on an iPad is a lot easier than clicking and sliding images with your mouse on a desktop site).

The best-case scenario would be to have the time and budget to create a specific site for each target. The best smartphone sites out there were designed specifically for the small form factor. That can be said about the best tablet sites (and apps), as well as the best desktop sites. This is rarely a realistic option for client budgets, though. We believe that right now when budget is a factor (and it almost always is), your best bet is to create 2 versions of a site. Target 2 platforms/devices with 1 version. Example: Make a HTML5 site that looks great on your desktop and works well on your tablet, then make a specific smartphone only site. Or, make a basic HTML site that works fine on tablets and smartphones, then make a specific desktop-only site that breaks the mould and delivers a unique experience. And in this case, why not use Flash?

The Graceful Degradation

We’ve noticed an interesting phenomenon as a side effect of the HTML5 buzz explosion.  Industry folk and the developer community seem to be expecting and accepting less from HTML5 sites than their Flash brethren.  Essentially, it takes far less robust of an end user experience for an HTML5 site to receive critical acclaim than with a Flash site; a sort of “HTML5 Affirmative Action.” You can see this in examples such as this: You have two “Graphic Novel” themed sites. The first an FWA award winning HTML5 site on January 30th, 2012 (http://www.soul-reaper.com/). The site features lovely illustration and a single auto scrolling page with some simple animations; continuing the “Single Scrolling Page” theme we are becoming accustomed to seeing day in and day out. To the non-techy end user, this is a nice looking site, but it doesn’t offer much in the way of an experience. Now compare that with the second “Graphic Novel” themed Flash site from 2009: Team Geist. Also an FWA award winning site, it features a uniquely concepted game that combines Live Action Cinema, 3D, Visual Effects, Game Strategy, Social Integration, all in a tightly woven package built in Flash. It required a large production and development team across multiple disciplines; as seen in the Behind the Scenes features here: http://www.northkingdom.com/case-studies/adidas-teamgeist/.

Truth be told, this has actually created a solid advantage for using HTML5 as a means of generating buzz in the developer communities. It takes far less of a commitment of time, resources, and innovative thinking to create a site deemed buzz and award-worthy (though a chunk of time will now need to be devoted to debugging and browser compatibility solves).  This, however, assumes your target audience are those in the community around you, who care mostly about the trends and the nitty gritty tech of how a site was built. If that is not your target audience, then you may not be meeting your client’s goals of reaching a larger non-tech savvy audience. How long this phenomenon will last is still uncertain.  If the innovation hits a ceiling due to technical limitations or continued browser limitations, we could see a shift back before the next 100 parallax scrolling single page HTML5 sites hit the web.

.NET magazine recently released an article about the “15 top web design development trends for 2012” in which seasoned designer Tom Muller predicts Flash will surely survive, certainly in the near-term. He explains that during 2011, he was involved in 3 major projects that relied on Flash, simply because it remains the best tool for interactive video, animation and 3D online. He added, “Web designers and developers sometimes lose sight of what works and is demanded by a larger audience, due to preferring what’s considered ‘cool’ in their bubble”, and that “More big brands will shift from Flash, testing the water with HTML5 and CSS3 for focussed campaigns. But for entertainment sites, Flash is – and will remain – the predominant tool of choice to create engaging experiences.”

One certainty in HTML5′s future is that the pace of innovation will be slower than anyone would like.  Instead of a situation where we rely on one company to innovate and release new features (in the way that Adobe does with Flash or Apple does with iOS), we are relying on a standards board to decide on features and then four browser manufactures to implement them.

Furthermore, once the browser manufacturers implement them, users of each browser need to get the latest upgrade. And finally, with each browser comes a new set of bugs that developers need to create work arounds for.  For an inside look at how convoluted the web standards process can be, have a look at the following excerpt from the book HTML5 For Web Designers – by Jeremy Keith.  The excerpt is from the opening of the book and details how HTML5 came to exist, it describes all the infighting going on behind the scenes. It is a true nerd war, including the big decision on whether it should be “HTML5″ or “HTML 5″ with a space.  Critical stuff.

For developers we have sites like http://html5please.us/ which tell us the features of HTML5 we can safely use and those that are broken or don’t work in specific browsers and need fallbacks. And while this site may be seen as a handy resource for developers, the fact that it exists at all should be a warning to anyone seeking to have a cutting edge HTML5 site developed. To look at this from another perspective:  Can you imagine if you wanted to build an iPhone application and as you dug in and referred to Apple’s documentation for various functions, you discovered that 80% of them didn’t work properly and you had to use work arounds, or did not work at all? That would be completely unacceptable. The reality is that closed development platforms such as iOS or Flash provide developers with an enjoyable and predictable experience.  If a bug arises with a feature of the platform, you only have to find a work around for one platform, not several browsers on two different operating systems.  Furthermore Apple and Adobe fix these bugs quickly in next release of their runtimes.  In HTML5 you rely on multiple browser manufacturers to fix bugs and broken features, and often this can take years. As in cases where Microsoft took as many as 10 years to fix a small issue.

The development community eventually comes up with work arounds as you can see on the html5please site, but what happens in the middle of a project when you discover a bug across multiple browsers that hasn’t been uncovered and solved by the development community?  Is everyone prepared to add weeks to a project timeline, and the correlating cost, to accommodate such scenarios?

A Hole In HTML5’s Video Armor

The HTML5 video tag is another good example of these headaches.  I’m going to single this out since so many of the award winning Flash sites of the past 5+ years have relied on video for the overall experience (Live Action and/or rendered video animations). And simply playing video in a self contained player is unarguably one of the core requirements of web sites, yet it is still extremely convoluted and time consuming to implement in HTML5.  Previously in Flash you simply rendered out one video file and loaded it in to play in your Flash video player.  It was guaranteed to work for 98% of desktop users.

Today with Mobile and HTML5 in the mix it is no longer so streamlined. Developer and author, Robert Reinhardt, recently wrote a blog post titled “The World of Pain that is HTML5 Video”  in which he discussed the issues with HTML5 video. At the core of it is the fact that the various browser vendors are pushing different encoding formats and there is no single format compatible with the current popular browsers; meaning you have to encode three different videos for desktop and then also mobile versions.

On a recent project we had roughly 30 different video animations in queue at any given time.  Having to encode three different versions of each, every time a creative revision came in, would have blown up our pipeline and caused us to miss deadlines.  You can just skim his blog post to get the idea of how complicated this issue is and in the end his conclusion is that currently the best strategy is Flash video on the desktop with fallback to HTML5, allowing you to encode in one format.  But this still relies on Flash to simplify things. If your site experience relies on using interactive or alpha channel video (pretty much anything other than playing video in a standard player), forget HTML5.  I personally know how complicated programming Flash video interactivity for a site can be, like our www.bankrungame.com site for example, and trying to do something like this in HTML5 will be 10 times more difficult; if not impossible in its current state.

In Closing

What we’ve tried to do is give a realistic look at what it will mean to target HTML5 for upcoming campaigns.  Based on the current buzz around it, people may not have a clear idea of the challenges involved with working around its limitations.  You want to make sure you chose the right tool for the job.

HTML5 is here to stay and often it will be the right tool, but if you try to force the technology on a project its not right for, it may come back to bite you.  Possibly via missed deadlines, budget overages, poor metrics due to limited compatibility, or a campaign that goes live full of bugs and a phone ringing off the hook with an upset client.

It may feel like overall tone of this article is negative on using HTML5.  That’s not the case, as we think it’s a great option for the majority of sites on the web. We simply aren’t excited about it as a definitive replacement for Flash.  HTML5 in its current state allows us to do less creatively with far more work, so we prefer the absolute creative freedom that platforms like Flash or iOS provide. We also don’t care about web standards.  Not to say they don’t have importance, but it is not what we are focused on. We are focused on concept, execution, and doing work that is motivating and enjoyable. Strategically we’ll continue to develop our HTML5 portfolio and use it when it makes business sense for our clients. Though we would be more excited about it if it allowed us to create end-user experiences that hadn’t already been possible at some time in the last decade.

Finally, here are a few logical guidelines when considering a strategy for new campaigns:

• Don’t decide on the technology until you figure out your audience. Is the primary target mobile or desktop? What percent of your audience is on HTML5 compatible browsers?
• Figure out your clients goals. Are they ok with you targeting a smaller audience for the sake of industry buzz and awards? Or are they more concerned with overall reach to consumers.
• Creatives concepting HTML5 sites need to learn more about the technology and limitations.  You can’t assume everything you would have concepted for a Flash targeted site will be possible in HTML5.  Especially if it is running on tablets and smart phones.
• If the goal is a highly interactive site on the desktop that will reach a maximum audience, use Flash.
• If a site uses interactive video and/or alpha channel video, use Flash and don’t expect the same type of experience to be possible on mobile.
• If the site only requires basic animations (think animating layers of a photoshop document) and video in contained players, use HTML5.
• Deep content/copy heavy portals, corporate sites, and blogs should be HTML. This has always been a good rule.
• If the same site needs to work on the desktop and tablet expect less (in terms of interactivity, animation, and innovative UX).
• If the same site needs to work on the desktop, tablet, and smart phones, expect a lot less.
• Be careful not to expect a robust HTML5 site to be built on a tight timeline. Extra time will be needed for build and more importantly QA/bug fixes. i.e. Don’t plan on approving creative two weeks before a site needs to go live.
• Understand that not all HTML5 features are created equal. Some work on mobile, but not desktop. Some work on desktop, but not mobile.  WebGL is a good example.  Currently it is not enabled in mobile browsers and Internet Explorer on the desktop.

Source:http://aarra.com/