Running from Bears - (The DevCon 2002 Presentation)Introduction
This past month at Macromedia's DevCon 2002 I presented a talk based on my article "What would Wal-Mart Do?" While the beginning and end of the presentation are straight from the article, I updated the middle. The new content takes another look at what Flash developers can learn by looking at the success of Wal-Mart, the most successful company in America. How can we learn from Wal-Mart and turn that into more usable Flash content with a better experience for our users.
This article is the result of that thought process. It serves as a compliment to the original Wal-Mart article and offers my latest thoughts on one of the most pressing questions that we need to ask ourselves about using Flash; when is it best for the user?
Good, Fast or Cheap
When I started working on computers creating interactive content back in 1990, I worked in a service bureau. When business was slow, my boss would often share his insight into the world of business with me. In addition to insight on how to deal with our customers my boss would often tell me that in the service industry there was an old saying that said "good, fast or cheap; pick two." What the saying means was that you could expect a service to be fast and cheap but not good, or good and fast but not cheap or cheap and good, but never fast. That was the way things worked before the Internet, but things have changed a great deal in the past 12 years.
In today's world of hyper-consumerism the old saying of my former boss has been turned on its ear by Wal-Mart. Not satisfied with merely offering two of those three options to their customers, Wal-Mart offers all three.
Wal-Mart is good (well, for their customers at least); their stores offer a large selection of products organized so that it is easy to find the things you need. The staff at Wal-Mart is generally friendly and the stores are usually pretty clean. All told, it's a good experience shopping there from the moment you are greeted on entry to the store.
Wal-Mart is fast; you can get in, find what you need and get out. In the Wal-Mart near my house there are 46 check-out lanes. During peak shopping times the majority of those lanes are open. Everything about their stores is designed to make the customer feel like they are not waiting.
Wal-Mart is cheap; everything is lower in price at Wal-Mart. If Kmart has something for $1.99 then Wal-Mart sells something identical for $1.96.
By offering their customers the trifectea of service, Wal-Mart has grown to become the largest company in America knocking oil giant ExxonMobil to the number two slot on the Fortune 500 in 2002. Wal-Mart has found success because for their customers, shopping at a Wal-Mart is better, faster and cheaper than shopping at Wal-Mart's competition.
This service model that Wal-Mart has employed is the same model that we've seen being successful on the web. If there is anything that the Internet has shown, it is that the user's experience with the online offerings of companies is a very big factor in their success. Take Amazon.com for example. Like Wal-Mart they offer their users a better experience. Their web site is possibly one of the best shopping experiences on the web, these days the site does a better job selling to its visitors than anyone else in the ecommerce arena. The Amazon.com site is fast and designed for slow-connection users. Finally, Amazon.com offers discounts on just about everything they sell, making them cheaper than their competition.
A good experience can be a very valuable asset
What do Wal-Mart and Amazon.com know that eludes their competition? They both know that the experience of their customers is critical to the success of their brand. Other companies who pay attention to the total experience in their products have also either done very well, or carved out a loyal user base who they can sell to at a premium. Companies like Apple Computer, BMW, OXO Kitchenware, Volkswagen and a host of others consciously seek to own the 'experience' niche in their fields.
During Rob Burgess's keynote at DevCon he spoke about this shift to marketing experience as a sign that we are entering the 'experience economy.' The experience economy being an economic system that sees the experience of the product or service as an essential part of the product or service's brand. As Burgess put it in his keynote we've gone from selling a cup of 25 cent coffee at the corner store to selling the experience of drinking a $3 coffee at Starbucks.
A bad experience will drive people away
Where there can be benefit in economic gain from offering the user a better experience than the competition, there is always the opposite effect when the experience is poor. Nothing angers the consumer more than the feeling that their experience is not important to the company they are dealing with. In California this week, SBC Communications is under fire for attempting to lay-off customer service reps. The issue is not that the customer service reps want to keep their jobs (and I am sure they do) but that the customers of SBC do not want to get worse service from the already consumer-unfriendly industry.
If you have ever had bad service with a waiter/waitress at a restaurant then you will understand what bad service can mean to a company. If your waiter is everything a waiter should not be, mixing up orders, never bringing drinks, interrupting conversation and so on, then chances are no matter how good the food and the atmosphere of the restaurant are you are likely to think twice when considering the restaurant in the future. Your bad experience has affected the economic gain of the restaurant.
In the experience economy the quality of use breeds loyalty from the consumer, and brand-loyalty is money in the bank.
I thought this article was about Flash?
- an experience that is better than HTML
- an experience that is faster than HTML
- an experience that is cheaper than HTML
At this point you may be wondering to yourself just what is an article about economies and brand-loyalty and Wal-Mart doing on a site about Flash. Well, it is simple; like Wal-Mart and Amazon.com we now know that the experience of our users, the consumers of the services and information on the web, is central to the success of our clients. To that end, with the release of Flash MX, Flash Remoting and the Flash Communications Server we can offer users:
Better than HTML!?!
"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.
The interactions available within the framework of an HTML page, and I'm including DHTML, XHTML and other variants of HTML, are just not that robust (or they are robust but too unstable). When developers look to using CSS and JavaScript to provide a little more control over the interaction on their pages then there are all kinds of compatibility issues. Frequently web developers have to jump through the hoops of browser and platform compatibility and server connections just to be able to get a round peg through a square hole. One of the biggest issues with the overall usability of the web is that there are too many non-standard interactions out there. Some menus pop up, some pull down, some fly out and some expand down the page. Buttons may activate on a click or a roll-over or not seem to work at all. The end result is that users are completely confused as to what they might be able to expect on a web page.
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 the Broadmoor hotel's Flash registration page. 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.
Free refills forever*
At this point we've covered how Flash can offer a better experience than HTML through a user-centric development process. We've also talked about how Flash can offer the user a faster experience than HTML through dynamically updating content on the screen. Ten years ago this would have been enough to make my boss happy, but the Internet arrived and now businesses must strive to go the extra mile in terms of the experience they offer their users. So, how can Flash content be cheaper than HTML?
As with my first statement on Flash being easier than HTML, I'd like to clarify what I mean when I say 'cheaper than HTML.' I am not talking about the costs associated with creating and maintaining Flash content. Remember, we are not talking about the clients or the developers - we're talking about Flash from the user's perspective. To the user the cost of the interaction is time. Time is the only commodity that we can not get back once we have spent it, and staring at the 'blink' can get frustrating. Flash content, when designed to make the most of small file sizes, can significantly reduce the amount of data that needs to go down the pipe to the user.
Every web page consists of two separate parts; the content and the container. The content portion of the page is the information that people get from the page. The Container portion of the page is all the HTML and CSS instructions that format the page. When an HTML page is downloaded into the browser there is a lot that happens on the browser side of the equation that takes place before you see the content. The browser has to start building the structure of the page before it can flow in the content so the user can see it. The container portion of the code is a glass for the content, the water, to be poured into. Pages with nested, complex tables take longer to display because they are a more complex glass that the browser has to build. The browser has to download the glass before it can fill it with water.
Each time you access a HTML page on the web your browser is building a container and displaying the content, but what happens to the container between pages? Well, browsers are pretty wasteful in this regard. The 'blink' part of the HTML interaction is actually the browser throwing away the last page's container and content so it has room to build a new container for the new content. Sure the cache saves some of the images and code, but the container still needs to be built each time a page is displayed. This is fine when the user is bouncing from site to site, but when moving from page to page within the same web site 90% of the structural code is likely to be identical, yet the browser still tosses it away.
Flash content also has information that makes up the container for the content, but as we have discussed Flash can refill the content without needing to throw out the container. Developers can build interfaces within Flash that are robust enough to accept a variety of content, and still keep the file sizes small. With the use of reusable components like the UI components from Macromedia or custom interface elements that developers create, we can effectively create a container that can continually be refilled without needing to build a new container each time. A Flash built glass can offer the user free refills*.
This ability to provide free refills of content within one container can improve the overall content to container ratio. Let's look at two nearly identical pages on Yahoo.com to see how much of the file is structural and how much is content. According to Adrian Holovaty's GetContentSize tool, the home page for Yahoo! Entertainment consists of 7107 bytes of HTML and only 14.44% of that is content. The remaining 85.56% of the HTML code is structural. The home page for Yahoo! Education is 7520 bytes of HTML with 84.63% of that being structural. If you were to look at these two pages side by side you would see that outside of their different content, the two pages are nearly identical. Each time that a user views a page like this on Yahoo.com approximately 85% of the HTML file is just used to build a container that will be thrown out as soon as the user moves on. That's 6k per page that Flash would not need to download once the interface has been loaded.
The real trick is to be able to build an interface that is small enough for this all to matter. If the container portion of your Flash content was 100k then it would take 16 Yahoo pages to make it worth it for the user (at an average of 6.3k of container per page). A Flash interface that weighs in at 30k would start showing benefits after only five Yahoo-like pages.
Yahoo is an extreme example of HTML container to content ratios. Most sites have much higher ratios of container to content; eBay, for example, has 92.21% of its 53k HTML file being structural. With higher ratios, using Flash to develop a small container for the content makes even more sense. A 100k Flash interface would offer benefits in terms of download time to the user after only two 53k eBay pages.
Even with the benefit of being able to maintain our container while accessing multiple types of content, we still need to pay attention to file sizes. There is nothing that makes Flash content a bad experience like a long download. Fortunately with the release of Flash MX and the drawing API within Flash it is now possible to develop interfaces entirely in code that will download even faster than the already streamlined vector format.
Think of what you can do with less than 100k in Flash. David Doull, my co-author on The Flash Usability Guide, created a Flash application called smallblueprinter that allows users to design a floor plan and then interact with it via a 3D walkthrough and print out a blueprint with less than 76k. The annual 5k competition, where developers are challenged to see how much they can do with 5k worth of data has been attracting more and more Flash entries. In 2002 a Flash file took top honors in 5 categories of the competition. The Flash Communications Server includes components that allow developers to build a chat room in under 20k.
If you'd like to look into making low-bandwidth interface than I suggest that you take a look at the Macromedia Pet Market Blueprint application. The developers created a very smart interface that reuses multiple elements to keep file sizes small.
*Free refills onsite only, valid this URL and this view only.
You don't have to outrun the bear.
There is one more element that Flash developers need to think about when working to create the best possible experience for their users; whether they should use Flash at all. I get asked about this decision more than any other question at conferences and in email. How do we make the decision if Flash is the best tool for the job?
Once again, we need to look at how the decision that we make affects the user. Will Flash enable our user, or are we inflicting Flash on them? To answer this issue, I like to share this joke:
So, there are these two guys camping in the woods. Late one night they are woken by a noise outside their tent. The first camper peeks outside the tent to see a large grizzly bear sifting through their supplies. With horror he turns to his fellow camper and explains the situation. Obviously the bear is hungry, and once it is finished with the supplies it will surly turn on the two campers.
"What are we going to do?" asks the second camper.
"We can make a run for the car." whispers the first camper.
With that the second camper begins to put on his running shoes.
"What are you doing?" asks the first camper frantically "You can't outrun a bear!"
"I know," replies the second camper, "I don't have to outrun the bear - I have to outrun you."
This joke illustrates the effect that Flash can have on the user. We've got two choices for deploying our content; Flash and HTML. One of those choices is going to help the user get to where they need to be faster than the other. As developers we need to think about our users as the campers and the bear as a poor user experience. In many cases HTML is going to be the better choice for the user, allowing them to complete their tasks faster than a comparable Flash version. In some cases, like the Broadmoor Hotel reservation system, Flash can offer a better solution for the user - allowing them to complete their tasks far easier and faster than the HTML version.
The bear of poor experience is always lurking behind every task a user needs to complete. As Flash developers we need to create faster running shoes for our users. We don't have to solve every usability issue on the web with the Flash interfaces that we build; we just have to make sure that the Flash interfaces we create allow our user to interact more easily and intuitively than an HTML solution.
Join the discussion, add your comments about this article here http://www.flazoom.com/cooler/1037810140,82966,.shtml
Chris MacGregor, UI Interaction Designer with Intuitive Homes in Houston, Texas, is a leading proponent of using Flash to improve user experience on the web. MacGregor's 10 year history in interactive communication began with HyperCard, moved to HTML and now focuses on Flash Applications on the web.
As a leader in the field of Flash usability, Chris has consulted on and built projects including online product catalogs, eLearning systems, retail kiosks and web based applications in Flash for clients including ExxonMobil, Halliburton, BMC Software, Shell Chemical, CMS Energy, SmithBits, Dynergy, Emeril Lagasse and Compaq.
In addition to his award-winning interaction work, Chris is the publisher of Flazoom.com, a popular Flash critique site, and is lead author of the book, "The Flash Usability Guide" from Friends of Ed.