Alternatives to the pixelated UI universe
Do you think the pixel is the only unit of measurement for building graphical displays? Come on, you can measure better than that! This month, the Cranky user offers tips for user-friendly HTML layout and interface design, and explains why pixels aren't always the best unit for the job.
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.
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.
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.
Graphics and text
Typical DPI range?
Ever wondered what the typical DPI range is? Well, there isn't one.The Mac Classic used 72 dots per inch, and as a result many users now refer to a point as a seventy-second of an inch. Programs developed for the original Mac used the 72 DPI assumption. The X Windows system comes with bitmapped fonts rendered for 75-DPI and 100-DPI screens.
My primary working desktop is actually a laptop. Depending on whether I'm using it with the built-in display or the larger monitor on my desk, or possibly some other display, its resolution runs between about 86 DPI and 133 DPI. Even when it's on the huge monitor, and running at 86 DPI, I still find that the default font sizes most people use give me a headache; and that's when I can read them at all. And of course that assumes the default 1600 x 1200 resolution. A program running at 800 x 600 is at 43 DPI on the large display!
It's a reasonably safe bet that most users will have a resolution somewhere over 25 DPI and under 250 DPI. But that's just for now. Some exceptions already exist.
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.
