Lego bricks

The Lego bricks are not Adobe’s fault, nor are they Apple’s. They are our fault. My fault. The developers and designers that use Flash. Haven’t we known for years that not every device has the Flash Player? Shouldn’t we have designs that fall back gracefully so we don’t just see a big white area with a Lego brick in the middle? As developers that use Flash to make rich experiences, it is our responsibility to provide a useful, well-designed fall back when the user does not have the Flash plug in installed.

Quite frankly, I don’t want the flash plugin running on mobile Safari on my iPhone. It’s bad enough that a majority of the web sites out there look awkward and are unusable on the small screen of the iPhone, to add Flash sites to that would just compound the problem. Have a graceful fall back. If the iPhone user is one of your intended users, then design a version of the experience that doesn’t require a lot of pinching and panning or Flash. This isn’t a Flash developer specific problem, this is a web designer specific problem.

On the iPad, sure it would be nice to have Flash in Safari, but we don’t. That fact doesn’t let us off the hook. We need graceful fall backs that the web designer actually thought about. I’m just as guilty of this as other Flash developers: a totally blank page with 10-point Times Roman stating “this site is for Flash” is clearly a fumble on the designer’s part. SWFObject puts that there so developers can remember to do their homework, not as the fallback users are supposed to see. C’mon folks, how long have we been doing this? We should know better!

While developers are mostly to blame here, they are also the ones trying to solve the problem – thats why tools like SWFObject exists in the first place. Adobe, you need to take responsibility for this and offer better ways for designers to create usable fallbacks on devices that don’t support Flash. Maybe incorporate SWFObject and offer a UI to add a static image, copy, etc. explaining to the user-without-Flash what the deal is.

HTML5 doesn’t change anything

I’ve already outlined what I think about the Flash vs HTML5 argument. There will be a lot of Flash experiences that do in fact get replaced by HTML5, but there are a lot that won’t, shouldn’t, and just can’t be replaced by nature of the richness of the experiences. This is just continuing the evolution we’ve been seeing for a while now, starting with Web 2.0 and standards based web development years ago. It should not be a shock to anyone. If your target audience use iPads, then you have to do the design work necessary to deal with that. Regardless of if we had the Flash in iPad Safari or not, this is still the case!

Apple, let the users decide!

Ok, so on the web side of things, I feel like there are pretty clear mistakes that we, as developers, have made and that we should have been better prepared for. But this whole developer agreement that Apple has changed, that is not so easy to write off.

As I outlined previously, HTML5 won’t replace Flash any time soon. It just won’t and can’t. Coming from a mobile background, I can understand why on these underpowered devices you might not want web pages full of Flash player instances bringing the poor processor to a halt. But thats the web. Html5 shouldn’t be a reason to not include Flash-built applications in the App Store.

We have some great user experiences designers that can create awesome experiences using Flash. If they create one that feels right on the iPad, who cares how it was developed? If users decide it’s good, then it’s good. Users shouldn’t (and mostly don’t) care what the technology of the experience is, especially when it’s a great experience. So let the user decide, by way of ratings and purchases, whether a flash-built app belongs in the store or not.

There are crashing, unstable apps built in Xcode that seem to make it to the store all the time, and users are vocal when they review them, and they review them negatively. There are apps that are really poorly designed, that don’t live up to the standard of some of the other great apps out there. Users have been able to make the choice of installing those apps or not. I see apps that use a “middle layer” all the time in app store apps, its called UIWebView, and sometimes it works and sometimes it doesnt. Users complain when it doesnt and those developers make changes to keep users. The users have (and should have) the power.

So why can’t it be the same with apps built by 3rd party development tools? Apple, I really believe you are missing out on many opportunities for great user experiences on your products by not allowing developers to develop using tools like those Adobe has already built. You are treating your users like mindless drones, incapable of deciding what’s good for themselves. Let users decide!

The right direction?

It seems like there is a user experience emerging here that is less than ideal, but I’ve outlined it in an earlier post and it bears reiterating in the midst of all of this name calling:

• User goes to a web site on their iPad
• It’s a rich, Flash built experience on the desktop computer, but on the iPad a nice static, branded image appears offering a button to tap and download the app from the App Store
• User taps, installs the Flash-built app and tries it out.

See, no Lego bricks, no Flash crashing Safari, no HTML5 vs Flash mumbo jumbo. A happy user is a happy user. Isn’t that what it’s all about?

Apple, Adobe, can you sort this out now so us developers can get back to creating great experiences using your products?

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

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

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

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

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.