Better than HTML!?!
Click here for a
Printer Friendly Version
"Better than HTML?" Did I just write that? Yes I did, but let me clarify exactly what I mean by that. First off, I am not saying that Flash content should replace HTML on the web. If you'll take a look at any page on Flazoom.com you will see that delivering content with HTML still my format of choice for this site. What I mean is that there are a number of cases when Flash can be better than HTML for the user (we'll get to those cases later). Flash content can offer a better experience for the user, an experience that is easier.
Interactions built in Flash can fail for the same reasons as HTML, but because Flash allows developers control over how the interactions actually work we can develop better interactions for the specific tasks we need to address. The interactions we build can step away from the limitations of HTML and provide a more task-specific interaction to the user. This ability, which only comes as a result of user testing and iterative design, can make a complex task easier to accomplish within a Flash interface for the user.
Good Flash interactions don't just build them selves, we Flash developers have to make a commitment to using Flash's abilities to make the user's experience better. Better doesn't mean richer. Flash content with a looping soundtrack is not going to provide a better experience for the user. Better doesn't mean more interactive either. Flash content with an interface filled with interactivity is frequently more likely to confuse and distract the user instead of helping to make their tasks easier. Better certainly does not mean more intrusive; launching in full screen windows, forcing wasteful content (like intro movies), or generally acting unlike anything the user has experienced before is not better than HTML at all.
What better does mean is content that is easier for the user to use. Content that has been created with the user in mind, making the things that the user does easier. Content that gets tested with users to find out if it works well before it is launched to the web. Content that has been improved through a user-centric development process.
That's all that usability really is, a part of the user-centric design process. Usability is finding out what people find easy to use. If you were under the impression that usability was creating interfaces and programming buttons then you are thinking about interaction design. It is the job of the Interaction designer to create the interfaces and systems that the usability people test. It is our job as Interaction designers to take complex tasks and build simpler methods of accomplishing them; to look for familiar conventions and apply them to the interactions we build.
The HTML Post Office
Still not convinced that Flash can offer the user a better experience than HTML? That's OK; we haven't covered to the big issue yet. The biggest issue with the user experience of HTML for interactivity is the blink. Not the blink tag, that's been run out town on a rail years ago. What we are talking about is the blink that happens every time your browser has to refresh the page. The transition between pressing a button and what comes next makes the experience with HTML based interactions abrupt and jarring. That instance of time when the browser goes white, just before the page rebuilds; that's the blink.
Imagine if you will that your browser is actually a postal clerk at the counter at your local post office. Every time you asked a question to the postal clerk they would have to walk away from the counter, ask a supervisor, and return to give you the reply. Even the most basic questions require that the clerk leave you staring at an empty counter while they get the answer to your question.
That's what the world of HTML interactions is like. Each time you ask a question you have to wait while the browser goes and talks to the server before you get a reply. How would this 'blink' between every interaction affect the way you feel about going to the post office?
For users on a slow modem, the blink can last for a while, depending on the user's computer and the speed of the server on the other side of the connection. The blink is an inescapable part of HTML based sites. Even the super-usable Amazon.com can not avoid the blink.
Flash doesn't need to blink.
The reason that HTML has to blink between every page is due to a very basic limitation of HTML interactions; HTML can not dynamically update the page with new information by itself. Sure you can add a Java Applet or shockwave content or ActiveX controls or non-cross-browser code but none of these implementations are going to be cross-browser, cross-platform compatible. Using the latest HTML tricks requires a recent browser and at last check the two major browsers were both multi-megabyte downloads and even then the trickery is not guaranteed to work everywhere.
The only way to get an HTML page to dynamically update information on the screen without resorting to refreshing the page in a user friendly manner is to use Flash content on the page. Even if the user doesn't have the latest plug-in, the Flash player is still only a fraction of the file size of downloading a browser. The Flash plug-in has also historically been proven to be the most frequently upgraded software on the user's computer. Flash gets upgraded more often than browsers, operating systems and applications and it's no wonder - any browser equipped with the latest Flash plug-in can view the latest Flash content, even Netscape 3. Why update the browser at all? If the user wants the latest cool features of the web like streaming, video, audio, interactivity and communications they need just install Flash Player 6.
By being able to dynamically update the content of the screen we can provide a more direct interaction with the user. Take for example . I know you've probably seen this example a thousand times, but that doesn't detract from its value - it is simply an excellent use of Flash that deserves our attention. In comparison to an HTML based form, the Broadmoor's interface allows the user to accomplish all their needed tasks on one page. There is no blink as the browser requests information and waits for it from the server. Each entry by the user is checked through Flash's direct server connection abilities or by Flash's powerful client side scripting abilities.
Even if the user is on a slow connection, or the server is slow, Flash content allows the user to accomplish other steps while waiting for information from the server. Our users don't get the feeling like they are waiting each time they click a button. On a fast connection the exchange of information is almost instant. Flash can truly offer a faster experience to the user than HTML, when it is built well.
The Flash Post Office
We've visited the HTML post office with its disjointed, somewhat abrupt interaction of browser talking to server, then talking to the user. A post office with an interaction style similar to what we can build in Flash would be more like a conversation. When you ask the postal clerk a question, they are able to answer you directly. There is no walking off to the back room to find the answer; no blink.
Running from Bears continues with:
Part Three: Free Refills Forever!*
or return to
Part One: Good, Fast or Cheap
Join the discussion, add your comments about this article.