Recently I very much wanted to find out the hours of a large video store. It was Sunday evening and my friend and I were already in the car and driving there in the optimistic hope of obtaining the last season's collection of Buffy the Vampire Slayer. Conveniently, my cell phone is equipped with a fairly useful Web browser capable of downloading data at just over 10 kilobits per second.

Unfortunately, we got to our destination long before I could successfully glean the store's hours from its Web site.The site was simply overrun with trivial, bloated pages. By the time I parsed through them all on my portable device I probably could have walked to the video store rather than driven.

At the very least I would like the essential information up front: phone number, location, and hours still do make a difference when running a business on physical time. At best I want to see that site, and others like it, pruned of the page bloat that made my Web search useless.

This month I'll explain the downsides of putting too much information on your Web pages and offer some tips to put a lid on page bloat.

Think mobile!

For anyone who builds a Web site, the first consideration is who will use it. If you build a site for a retailer, take it for granted that some users will scan its pages for a physical address; and some will do that on portable devices.

You might think a machine with a processor that runs solidly at over 100 MHz, and 32 MB of RAM can easily display a reasonably large page, but this isn't always the case. My cell phone's built-in browser frequently gets about 200 KB into a page before displaying the message "This page is too large to be displayed." Certainly, a more flexible browser would help -- I would happily sacrifice much of the phone's otherwise unused storage to display larger pages -- but the fundamental problem, in my opinion, lies with the page design. Why does the store locator page chew up 200 KB? What do I get for my trouble? An HTML form could give me the information I need with just 2 KB.

Back to top

Pretty equals pricey

A major component of page bloat is all the add-ons that supposedly make pages pretty. I learned this first-hand when an online community that I participated in developed a PDA version that stripped out all the tables, layout, graphics, rollover menus, and other extras that slowed down the Web version for mobile users. Even with a 3-GHz computer on broadband, I felt the performance difference. For page loads that took 10 or 20 seconds in the glitzy version, the time was cut in half.

The use of images for buttons is one of the consistent nuisances of the Web. Images are orders of magnitude larger than the text for most buttons, inaccessible to many users, either illegible or too big on small browsers, and require separate HTTP transactions to download. And frankly, I haven't seen many graphicly designed buttons that are worth all the trouble.

In general, the more code you put into making the page look a certain way, the more time a user spends wondering why the page hasn't loaded yet. For example, the store locator page that started me on this month's topic was packed with large menus carefully rendered in alternating color schemes. Every menu had a substantial chunk of extra code to change the way it looked, which I suppose someone thought made the Web site seem exciting and daring. The net result was a painful display of angry fruit salad.

Exercise caution when coding for effect. Remember the price you'll pay in download time and ask yourself whether the effect is really worth it.

Back to top

Animated annoyances

The more your page moves, the more annoying it is. Animated pop-up menus are consistently awful. Never mind that they don't work on devices (such as my phone) that don't handle JavaScript. They're just plain annoying. One nice thing about a well-designed Web page is to see what you're looking for because the page has been rendered. Having parts of the page render and disappear without warning is obnoxious.

With an actual HTML-form pop-up option object, I at least have some visual cue that there's to be a menu. JavaScript-based menus that pop up when the mouse comes near them, or even when I click on something, are less helpful. Worse, they always show up at exactly the wrong time. I am probably clicking on your menu because I thought it was a link to something I wanted. I want that page, the one I just tried to click on the link to, not the weird, animated menu on this page.

Animated menus also encourage the catastrophically bad behavior of including hundreds of links on a page. In a browser that doesn't bother to render the menus as pop-ups this can leave me with 10 screens full of menu items to scroll past on my way to a single line of text. Likewise, animated menus make a page much bigger than it appears. The unusable store locator's angry fruit salad effect came partially from a very large collection of menus that were probably not intended to all render at once.

Back to top

Server-side slowdown

Strictly speaking, server-side processing isn't bloat to the end-user. It's not my problem whether I'm getting a static page or one generated through a couple thousand database accesses. But, in fact, dynamic pages tend to be slower to load because they're slower to generate. The server can't cache the page and just throw it out over the wire.

Even if a page must be dynamically generated (say, if it contains search results), it's still beneficial to limit the scope of dynamic content. Every database lookup or external program run is a bit more system load on every single page view. Worse, every database lookup or external program run is a potential point of failure. The only thing more frustrating than a page that fails to load due to an error in a database lookup is a page that fails to load due to an error in a totally unnecessary database lookup.

Back to top

False consensus effect

It may seem that most users have browsers that can easily handle all these large pages I'm complaining about. That's true; most users do. However, I suggest a couple of good reasons to not casually dismiss the exceptions.

The first issue is that users who have limited capabilities are among those most likely to be in a hurry or under stress. If I'm using my cell phone's Web browser, it's because I'm out of the house trying to get something done; this is the time when it matters most to me that a page be accessible and responsive. The second issue is the question of bandwidth. Even with bandwidth as cheap as it is, many companies are concerned about the difficulty of keeping their servers up under load. Reducing the amount of load is a good start on keeping up with it, don't you think?

At the heart of the problem is the tendency of Web developers to test on high-end workstations with Ethernet connections to unloaded test Web servers. This is unrealistic at best. Often, even developers making an effort to test with less powerful systems are still subject to the false consensus effect, tending to see broadband and powerful computers as much more common than they are. It's easy to think of a small machine as one with only a 1.8-GHz processor, 512 MB of RAM, and a 1024 x 768 true-color display (after all, those specs are all worse than the ones on a laptop I got two and a half years ago!) but the fact is that many users -- especially mobile ones -- are still working with far less.

Back to top

In conclusion

Page bloat hurts both developers and users. It will continue to cause problems until developers firmly weigh the benefits of proposed page enhancements.

Even if you must code for effect, at least decide up front which pages absolutely must work well and code them for simplicity. Keep pages, such as contact information and retail store locators, small and simple enough to render cleanly on any browser. The sanity you save may be your own.

This week's action item: Try a few common tasks (order pizza or check for store locations and hours) on a restricted browser; turn off your browser's JavaScript, use a cell phone, whatever it takes. For extra fun, try it on dial-up. Are these tasks as easy and convenient as you think they should be? Why, or why not?

Resources

• After you've done this week's action item (that is, tried a typical Web lookup with JavaScript disabled) you might want to read the author's column on "Curbing JavaScript dependency" (developerWorks, March 2001).
  
  
• The two-part "Designing a Palm user interface" is a good case study in the differences between GUI design for the Web versus for mobile devices (developerWorks, September 2001).
  
  
• Paul Smith is a human-computer interaction specialist who discusses the common fallacies of GUI design in his article "Debunking the myths of UI design" (developerWorks, February 2002).
  
  
• The unloved HTML button is a misnomer -- and Peter loves it!
  
  
• The Wikipedia entry on false consensus effect is full of interesting tidbits about why people think they're more typical than they are.
  
  
• The Jargon File provides a canonical explanation of angry fruit salad.
  
  
• Find out how IBM's Global Services Usability Engineering team can help you improve your products and make them easier to use.
  
  
• Visit these valuable resources on developerWorks:
  • The Web Architecture zone specializes in articles covering various Web-based solutions.
    
    
  • Browse for books on these and other technical topics.
  
  
  

About the author

Peter Seebach has been using computers for years and is gradually becoming acclimated. He still doesn't know why mice need to be cleaned so often, though. Contact Peter at crankyuser@seebs.plethora.net

Rate this article

Comments

Back to top

Table of contents

• Think mobile!
• Pretty equals pricey
• Animated annoyances
• Server-side slowdown
• False consensus effect
• In conclusion
• Resources
• About the author
• Comments