I sometimes wonder whether graphics wouldn't be better off if graphics designers and developers had stayed with vector-based graphics. For all that pixels are wonderful (I have nearly two million of them in front of me right now), they sometimes make Web designers do really stupid things.

For example, most designers calculate the size of images in pixels, even though the size of a reasonably clear word (for example) is a function of multiple factors -- distance to monitor, the user's eyesight, display size, and more. Displays alone vary so much that specifying size in pixels leads to graphical images that are too big to be useful or too small to be easily read. In fact, in Web design, I would say that the one thing you can count on is that you cannot calculate the size of your image in pixels. So why do so many designers do it that way?

I think I can explain the drawbacks of over-reliance on pixels and suggest some design techniques for getting around them.

Variable text size

Different browsers offer different levels of control over graphical display. A few browsers allow the user to set a minimum font size, such that absolutely no text will be rendered below the set size. It's a great feature, although in a perfect world it wouldn't be necessary.

Apple's Safari browser was one of the first to add size control to its main-browser toolbar. Firefox lets users specify a display resolution and renders all text accordingly. On many pages, features like these yield beautiful, clear text that is easy on the eyes. Wonderful, but hardly a fix-all.

For example, consider what happens when a page's layout becomes entirely unusable given a different font size. If you're lucky the main text column will simply become too narrow to be easily read. If you're not so lucky the text might extend under or over another part of the display, resulting in overlapping or invisible text.

A browser that gives users more control over the display is a great idea, but it's no solution for poor design.

Back to top

Graphics and text

Attempts that use graphical backdrops to make text render correctly are a major source of pixel problems. For instance, the Web site for Movable Type blog software (see Resources) uses a graphical backdrop for one of its menus. If you change the size of text, the menu no longer lines up as intended with the backdrop and some menu items become invisible.

Attempts to line up graphical elements with text, or even with each other, almost invariably fail at some point -- namely when the page's rendering changes.

Some designers use pictures of text as a way to control the layout of words. Don't do it: it's a bad idea. First, it introduces bloat. Second, it makes your page less accessible to people who can't see the pictures. And finally, it makes your page harder to read. Frankly, it's unlikely that you can do a better job of rendering text clearly for the user than a browser can; don't waste your time (or mine) trying.

Back to top

Pixels, points, and ems

Many Web designers do all page layout in pixels. That works great if everyone coming to your site has the same display size. It's not so good for the rest of us, however. Users with large displays may not appreciate the 6-inch margins your site uses to ensure that your 640-pixel-wide main content section renders correctly.

Think I'm exaggerating? I'm not. Right now, the front page of my browser fills nearly half of the 17-inch horizontal size of my display. That's an 8.5-inch margin. In fact, I tested it: I put a piece of standard US letter paper on the right side of the display. The only text covered by the paper was the "About Us" menu item. That's a lot of space wasted; I ended up with smaller, harder to read, text crammed into half of my display area.

Next time you're thinking pixels, try thinking points and ems instead. Points are good for general-purpose use since they will scale to any display size. Better yet, a browser can reasonably scale to points, unlike pixels. For anything that will hold text, ems are the correct unit since they will scale up and down with the user's choice of text size. You can rest easy with the assurance that "60 ems wide" is an acceptable width for a paragraph of text, rather than having to speculate on what font size the user will choose.

Points and ems are better than pixels for arranging layout. With these units, your page elements are of reasonable size no matter what the user's settings are. On the other hand, points and ems won't let you align images next to each other -- but this is probably a good thing. Hopefully it will discourage you from creating one of those horrible pages that depends on a large collection of disconnected images all lining up together to form, well, an even larger and uglier image.

Back to top

About HTML

Let's be honest. For all that everyone likes to remind you that HTML is not a layout language, it has acquired enough layout hints that, in practice, it really is a layout language. That doesn't mean HTML is a good layout language, though. In fact, doing layout in HTML is pretty close to crazy.

If you do your layout in HTML, the user can -- and often should -- override your layout suggestions. You have no way to know the capabilities of the target display. You won't know how large it is, either in pixels or in inches. You won't know how well the user can see it.

The key to successful HTML layout is to acknowledge these limitations and work with them. Go ahead and specify that a given <DIV> is intended to render on the left side of the display beside your body text; just don't try to force it. Don't build a page that will be completely unusable if you don't get what you asked for.

And seriously, don't specify widths in pixels. If you must specify a width, specify it in points or ems.

Back to top

The to-do list

I'll wrap up this month with a checklist for avoiding pixel problems and creating pages flexible enough to work with a variety of user preferences, browser renderings, and display sizes.

Avoid the use of images for text.

Rendering text as a fixed image is counterproductive and will annoy the user.

Build your layout so that it expands to fill available space.

Use CSS hints freely, but remember that they will sometimes be ignored or overridden by browser or display limitations, or even just user caprice.

Test your page on at least a few of the boundary conditions.

Look at your page on a full-screen 25-inch display. Look at it on a 15-inch laptop display with 1600 x 1200 resolution. Pull it up on a cell phone's tiny little browser.

Don't worry about whether your page looks "good" on every display.

Worry about whether all the content is visible. Look for paragraphs where every line is cut off three words early, or for overlapping text. Overlapping text is annoying at any time, but overlapping links are absolutely unacceptable; the user will probably be unable to select one or another of the overlapping links.

Don't waste time working around the limitations of HTML.

Remember that the best can be the enemy of the good: a page of such beauty that grown men weep openly with joy, when it is displayed on a 1024 x 768 display in Internet Explorer on a 75DPI screen, will make grown men weep openly with despair on any other display. Settle for a page that users won't even notice -- so quickly and easily do they find the content they are looking for -- regardless of what browser or display size they're using.

This week's action item: Grab a copy of Firefox and set the display resolution higher or lower than usual. How do the pages look? Now go into Safari, click the larger 'A' font-size button three times and then go explore the Web. Marvel at the illegibility of many pages you encounter.

Resources

• Peter further riffs on the failures of Web design in the article "How not to make your site accessible" (developerWorks, March 2001).
  
  
• In "The design of everyday things," Peter discusses the impact of human factors (as conceived by Donald Norman) on user interface design (developerWorks, September 2002).
  
  
• For a more technical, in-depth discussion of cross-browser design and development, see Doron Rosenberg's "Migrate apps from Internet Explorer to Mozilla" (developerWorks, July 2005).
  
  
• Check out Movable Type, a Weblog publishing platform that provides an example of what can go wrong when one uses graphical backdrops for page menus.
  
  
• Find out how IBM's Global Services Usability Engineering team can help you improve your products and make them easier to use.
  
  
• The Web Architecture zone specializes in articles covering various Web-based solutions.
  
  

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.

Rate this article

Comments

Back to top

Table of contents

• Variable text size
• Graphics and text
• Pixels, points, and ems
• About HTML
• The to-do list
• Resources
• About the author
• Comments