Part Three

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.

        CHris

Chris MacGregor, UI Interaction Designer with Intuitive Homes in Houston, Texas, is a leading proponent of using Flash to improve user experience on theweb. 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.