Opinion: Flash, HTML5, Browsers vs. The User

I was reading through some Flash vs. HTML5 related stories and one of the more recent was Mashable’s poll asking that now tired question: HTML5 or Flash?

While I’m not really that interested in which technology comes out on top with this kind of poll, I do find the responses interesting. Why are so many readers of these blogs so vehemently opposed to one technology when it seems pretty apparent that these readers don’t really fully understand what the technology is used for?

The Clueless User

And that there is a problem. Users should’t have to know or care whether the sites they go to are in Flash, HTML5, Silverlight, etc. The only impact a choice of technology should have on the user is improving their experience. Users know when the product they are using isn’t up to snuff, they feel it, and once the user knows the brand of technology under the hood, they now have a target.

I was talking to a coworker recently about the NBC site for the 2010 Olympic games and she expressed her dissatisfaction with Silverlight. The site wasn’t functioning well on her MacBook (I’ve seen Flash and HTML sites also perform poorly on that machine) but because this site had Silverlight logos prominently displayed and a right-click menu with mention of Silverlight, she suddenly had a target.

It must be Silverlight that was crappy.

I looked at the site on my machine, and had little trouble with the site, but i did have some general nitpicks about the user experience – but it wasn’t really Silverlight causing the problem at all. If this identical experience was built in Flash (and i would imagine many users assume it is – n fact i did until i noticed all the Silverlight branding), then most likely Flash would have been the reason for the user-experience pain-points.

So, who do you blame when the crappy experience is HTML driven? Who’s fault is it then? There is no right-click menu or logo in the bottom right attributing HTML technology to some company we’ve all heard some vague mention of before, so we dont really have anyone to pin the blame on, excpt maybe the actual brand who’s product we happen to be using.

So we blame Flash. Or Silverlight. Or Quicktime.

When technology is marketed to be on the tip of every consumer’s tongue, you risk being the target for their rage when something, even loosely involving that technology, goes wrong. Hence the sticky wicket for Adobe and other creators of content plug-ins – in an effort to be popular, you also become infamous.

Plug-ins are critical

Of course, user’s have a reason to be pissed off at these content plug-ins, and i would suggest most of that should be re-directed at designers like us; we’re the ones that develop the sites using the tools. We’ve developed our fair share of sites where Flash may not have been totally necessary, or created some really fun, interactive engagement that was only fun and engaging on the latest hardware and left the general public with something stutteringly slow. Those were decisions we, on the production side, made along with the client and felt that a risk was worth taking. In the end, we’ve ended up giving one of the most liberating and powerful of the content plug-ins the scarlet letter.

Over the last 10 years, plug-ins like Flash have felt the heat a few times, by way of usability experts, open source evangelists, or net savvy bloggers. But the reality of the situation is that in almost every case, it’s our work that casts a poor light on what is still the only game in town for rich experiences on the web. Yes, yes, HTML can do a lot and we use it when it’s right for the job, but when HTML isn’t right for that rich, immersive job, plug-ins like Flash is are default choice.

A quick glance at the FWA site if the year list shows some great examples of this. Imagine trying to wrangle HTML and JavaScript with videos and audio to create a site like the We Choose the Moon site? It would be horrible impractical if not completely impossible.

We Choose the Moon by The Martin Agency and Domani Studios

We Choose the Moon by The Martin Agency and Domani Studios

What about the Get the Glass site for Milk? From a visual design standpoint, I can go to that site in almost any desktop or laptop browser, regardless of operating system, and see and feel exactly the same thing. As a developer, I’m not left coding a ton of css hacks trying to get all my positioning right in the various browsers and never achieving pixel perfection. I’m not trying to find a range of fonts that look somewhat similar to the ones in the design i have, or close to the client’s brand typeface, but fall well short of of what is truly needed. Every pixel can be in its place and is pretty much guaranteed to be there on every machine with the plug-in.

Milk's Get the Glass

Milk's Get the Glass

From the interactive standpoint, there is a lushness and immediacy of feedback we can give the user, a level of detail we can go that is much harder to achieve using straight HTML with JavaScript. We can do what we feel is necessary for the user experience without limitation – be it audio feedback for mouse movements, smooth animations to introduce new content, and seamless integration with video and other types of assets.

On the technical side, we get a powerful set of coding tools and languages that are more robust and scalable than JavaScript and, most importantly, logically organized when we get into projects built on hundreds of thousands of lines of code.

One can try to re-create much of this in HTML and JavaScript, but it is just not practical or possible. Tools like Flash and Silverlight let visual designers create these experiences in visual ways and work with developers that can add code using amazing coding tools and we can be confident that over 90% of people are going to see what we design and build the way we intended it.

It would be ridiculous to propose building these projects in HTML and Javascript, HTML was just not meant for it. That’s not to say HTML cant be used to build great experiences, but it wont be replacing these plug-ins, that shouldn’t be the point.

A plug-in less web

There are a ton of great examples of HTML-based experiences, rich and not so rich. They offer amazing utility and flexibility in situations where you aren’t so worried about things being so pixel perfect or every little tool tip fading and spinning on. You aren’t worried about the typography matching a particular typeface, meticulously kerned and tweaked to visual perfection.You aren’t looking for that from the user experience, you and your client have other goals.

Basecamp by 37 Signals

Basecamp by 37 Signals

Sites like Basecamp, Flickr, Mint – the list goes on and on. We don’t need, nor want Flash-like plug-ins to drive these experiences because we aren’t worried about all of the same experience details. Layout is more editorial, structured, and utilitarian. We can have something visually engaging, but not in the We Choose the Moon type of way.

Mint

Mint

HTML is great for these and many other experiences where a plug-in just isn’t necessary. But we will always need plug-ins like Flash for experiences that demand that rich engagement that touches all the senses. In fact, even these great examples of HTML use plug-ins (Flash) to display animated, interactive graphs and other elements – plug-ins are sometimes still necessary for a good user experience. When HTML5 finally arrives for everyone, this wont change.

HTML 5 wont magically let us craft beautiful transitions and audio synced experiences, immediate, precisely designed feedback, pixel perfection and typeface congruency across all hardware and browser platforms. Sites like We Choose the Moon aren’t suddenly gong to be built in HTML5. Or HTML 6 for that matter. Probably not any version of HTML, because that isn’t the point of that technology. This is the reason we have plug-ins, so we don’t have to try and cram timeline-synchronized animation, seamless and pixel-perfect typography and other media assets into the HTML spec in a way that makes sense for a markup language intended for documents. Plug-ins offload that work, do it better, and don’t have to wait for every browser to support a spec in their own interpretation of it which leaves users and developers wanting more.

Better plug-ins, smarter designs

We’ve had plug-ins for ages, but people expect more – a user experience without all the headaches involved with waiting for a particular plug-in to load, or the performance issues related to particular plug-ins. I know this is in the works for some, but it seems like all plug-in and browser developers need to realize that the more that plug-ins blend seamlessly into the browser experience, the better the experience for users.

Developers have been told for years it’s up to them to design the best user experience for their users, but the current pickle we are in is that we can only take it so far without the help of the plug-in. For many projects, Flash or Silverlight are the best (and only) tools for the job, it’s up to the browser developers, OS developers, and plug-in developers to work together better so we can create experiences where the users don’t know or care what technology is at work – it just works great.

34 Responses to “Flash, HTML5, Browsers vs. The User”

  1. Gitamba Saila-Ngita says: This is spot on FLASH will always have a place for creating interactions and expierences we can’t produce even with the nimbleness of xhtml/css/ajax etc. But simple everyday use of things like video should be standardize under something like HTML 5 so devices across the board can play it back. This peace was super spot on man.

  2. michelangelo says: thanks for the reply gitamba. great points too!

  10. robmcm says: If an HTML app is running badly then the browser is to blame (aside the developer), just as with Flash you would blame Adobe. This means it’s up to the browsers to out perform each other and push performance forward. This is something adobe hasn’t really bothered with until now, as there was no competition.

    As for HTML being used for animated sites, then no HTML isn’t designed for that, but the canvas tag and JavaScript are. They are a drawing API and scripting language just like in Flash. Remember at the end of the day, they are both just rendering engines…

    Flash has a lot of API’s and functionality that make doing things a lot easier, but the ground work is now there in HTML5 and surrounding specs to cover this at a low level. There are lots of examples here: http://www.chromeexperiments.com/

    I would start dabbling and having a play, there is nothing to be afraid of 😉

  11. Mike Kerr says: What a GREAT overview…. Seriously VERY well Written. This article should be the shut up fuel to anyone who thinks HTML5 is going to Kill Flash.

    I never hated HTML5 and before Steve Jobs came out and boycotted Flash I was embracing both technologies. I said Great here’s a worthwhile update to HTML so I can do some simple things without having to built an entire site in Flash when it’s not necessary.

    I never had this opinion that HTML5 was going to replace Flash and I am still looking forward to developing in both.

    The People who think HTML5 is just going to replace Flash are people who have bought an iPad and want a reason to validate it. Or weak developers who fell off the Flash bandwagon back in MX2004 and have since then felt it’s too hard and too complicated. They’d be happy to see it go away because they think HTML5 will be a fresh start for them. Sorry… it’s not going anywhere.

    Mike
    theBrokenApple.com

  26. michelangelo says: @robmcm thanks for the comment! certainly not afraid of the canvas, i love it in fact. at the moment its like the early days of flash coding where the coders get access to making the really cool stuff but the visual designers are still left waiting for good visual tools to deal with it. also, no support in IE is a bummer for sure. when we get tools and support from our biggest segment of online users (IE), flash will probably have evolved to a format that doesn’t require a plug-in 😉

    great link by the way, thanks!

  27. michelangelo says: @Mike Kerr: thanks for the comment! yeah, HTML5 will be great and reduce a lot of what we hate to use Flash for: the inadequacies of our current HTML spec. But yeah, Flash (and its future replacement) will always have a place.

  28. robmcm says: Thanks Michaelangelo.

    Getting the browsers out there is a key part of any technology. Don’t forget however that IE users can already use HTML5 thanks to Google’s chrome frame. Effectively an HTML5 plugin for IE, bringing it to a par with flash (minus the install base). Also don’t forget you can program your code to degrade gracefully in some cases, check out Gmail’s drag and drop attachments in Chrome, Firefox and Opera (http://gmailblog.blogspot.com/2010/04/drag-and-drop-attachments-onto-messages.html).

    Flash will always be able to evolve faster thank open standards because there is no committee and fewer implementations to bring up to speed. This however is a double edged sword, as it means we are stuck with what Adobe thinks we need and feels like implementing.

    HTML5 also means there is a lot of cool stuff that flash developers can now use in their projects, such as GeoLocation, desktop drag and drop, threading with web workers etc, in just the same way HTML programmers can continue use Flash to replace limitations with web standards.

    One thing is for sure, a fanboy/flamer attitude never helps, and those on both sides are just as bad and ill-informed as each other. Learn and use them both, you’ll have nothing to lose 🙂

  29. michelangelo says: @robmcm: “Learn and use them both, you’ll have nothing to lose” i couldn’t agree more!