Why browser zoom shouldn’t kill flexible layouts

Zoe Gillenwater — Tue, 16 Jun 2009 14:24:38 +0000

Now that all the major browsers include the ability to zoom the entire page layout, rather than just increase text size, are liquid and elastic layouts obsolete? Can’t we just use fixed-width layouts and let the user zoom them if needed? The answer to that question depends on whether browser zoom solves all of the same problems than liquid and elastic layouts solve, and I don’t think it does.

Don’t get me wrong—it’s great that browsers have added this zoom ability. It’s yet another tool to give users more control to view web pages in a way that is most easy and enjoyable for them. But liquid and elastic layouts still offer a lot of benefits, as does plain old text resizing. Let’s go through the flexible layout benefits one by one and see if browser zooming on fixed-width layouts can deliver just as well.

Prevent horizontal scrolling

Liquid layouts get rid of the dreaded horizontal scrollbar (or crawlbar, as Jeremy Keith would have us say) for most users, since the layout adapts to whatever viewport size they’re currently using. This is a great boost to readability and overall usability. Browser zooming doesn’t do this automatically, and though it can be used to get rid of the horizontal scrollbar once it’s shown up, it produces unwanted side effects in the process.

Here’s an example from my own experience to illustrate what I mean. I usually keep my browser window at about 900 pixels wide, simply because that’s a width I find comfortable to read and visually pleasing, and because it fits well with the other windows I have open in my widescreen monitor. Browsing at 900 pixels means that most sites designed for a 1024 resolution produce a horizontal scrollbar for me. Now, I can zoom out of the page in order to make the whole layout smaller and make it fit in my window. But when I do this, the text size of the page gets smaller, since everything is smaller when you use browser zoom. Now I can’t read the page. All I wanted was the page to fit in my viewport, not for the text to change size. Liquid layouts are perfectly suited to this task, and browser zoom is not.

Take advantage of screen real estate

Liquid layouts allow you to make full use of the area available in the viewport, showing more or less content, depending on what will fit at any given moment. Browser zoom doesn’t do this. You can zoom in to fill up the viewport, but again, this just makes everything bigger, instead of showing more content to the user who has the space for it.

Allow users to choose their own line lengths

Liquid layouts essentially allow users to choose the line length, or number of text characters per line of text, that is most comfortable for them to read. Although most people will find the same, optimal line length easily readable (75 to 100 characters seems to be best for most people for on-screen reading), there are certain people who favor long or short lines of text, and those people who do make a conscious choice about their line lengths deserve to have this preference respected.

Browser zooming with fixed-width layouts doesn’t give users this ability to adjust the line length to fit their needs. Instead, the line length is fixed at a particular value that varies only based on the user’s text size. Users with large default text sizes may get much shorter line lengths than they prefer, for instance, and changing the zoom level will only preserve these un-ideal line lengths for them.

Set an optimal line length

Elastic layouts also don’t give users the ability to change the line length to suit their needs, but they do give the designer the ability to choose a line length that will be ideal for the majority of users. You might think you can do this with a fixed-width layout as well—and you could, if all your users had the same text size. If everyone kept the 16-pixel default text size, you could make your layout a fixed number of pixels and know exactly how many text characters would fit across each line. Then, if the users needed to zoom in to make the text bigger and easier for them to read, this same, optimal line length would be preserved, just with larger text characters.

But it doesn’t work this way in the real world. Not everyone uses the default text size. Some people make it bigger due to vision problems or other disabilities. Some people make it bigger because they have such a huge resolution on their huge monitor. Some people simply have the dpi on their machines set to 120 instead of 96, which makes all text throughout their system bigger. All of these users are going to have a different line length than the one you intended in your fixed-width layout. This won’t happen in an elastic layout, because its width will always be based on the user’s default or current text size, keeping line lengths constant.

But it doesn’t work this way in the real world. Not everyone uses the default text size, and those that don’t are going to have a different line length than the one you intended in your fixed-width layout. This won’t happen in an elastic layout, because its width will always be based on the user’s default or current text size, keeping line lengths constant.

Preserve design proportions

Elastic layouts give you more control over where text falls in relation to other design components on the page. No matter the text size, your design remains proportional and visually consistent (depending on if you choose to make the images scale too, of course). Again, you might think you can accomplish this with fixed-width layouts and browser zoom, but variable user text sizes make it impossible to know where a piece of text is going to fall on a fixed-width page.

Make text more readable

All of the benefits of liquid and elastic layouts that I’ve gone over have to do with respecting user preferences and making text easier to read. It seems to me that this is the goal of browser zoom as well, and in many cases it does make text easier for the user to read. But browser zoom also scales images. In some cases, this is probably desirable, as the user may want to get a better look at an image as well as the text. But, images scaled through zooming are going to be pixellated and blurry, so zooming may not help the user at all. And, I’m willing to bet that in most cases, users have no need or desire to view your logo or sidebar ad at three times its original size, and that the now-huge images are just getting in their way. (That’s why I reset Firefox, my default browser, to just scale text instead of zooming.)

If you have images that you think the user will want to get a closer look at, you can choose to scale only these images using easy CSS tricks. You can set up your images and CSS in such a way that the images will have little distortion or blurriness when scaled dynamically by the browser. The other images can all remain a constant size, so that they don’t get in the way of users with very large text and contribute to horizontal scrollbars, float drops, or other nasty things that can happen when you put huge images into web pages. And of couse, if a user does want to scale one of the non-scalable images, they can always use the browser zoom function as a backup method.

Conclusion

Again, I have to stress that zooming is a great function for browsers to include. Also, fixed-width layouts are not evil—they are ideal in certain situations. But liquid and elastic layouts have a lot of benefits that fixed-width layouts in combination with browser zoom can’t necessarily match. Luckily, I’m not the only one who recognizes this. Don’t use browser zooming as a reason to stop—or never start—making flexible layouts.

If you want more detail on all these benefits of flexible layouts, check out the free sample of Chapter 1 of my book, Flexible Web Design: Creating Liquid and Elastic Layouts with CSS.

Two usability tips: mean what you say, and use form labels

Zoe Gillenwater — Sat, 09 May 2009 17:08:44 +0000

On Thursday, while I was entering the Babies R Us Mother’s Day Sweepstakes, I had to choose between two grand prize packages to win. There was a radio button for each package, as well as a link right below each radio button reading “See All Prizes.”

The "See All Prizes" links below each grand prize package radio button.

I was happy to see this “See All Prizes” link, since I didn’t know what the difference between the BOB Revolution Stroller and Maclaren Stroller was. So I clicked on the link and got a popup window listing the prizes in each package. But that was it. I didn’t actually get to see any of the prizes. Nor did I get a description of each item. Nor did I get links to the pages on the Babies R Us site where I could view each item and learn more about it.

The popup listing the prizes.

I was left still not knowing what the difference between the two strollers was, and thus still didn’t know what choice I should make. Sure, I could go search for these strollers myself on the Babies R Us site. But I wish they hadn’t of gotten my hopes up by saying “See All Prizes,” when saying “See List of Prizes” would have been more accurate and left me less annoyed. (Plus, how hard would it have been to link each prize to its associated product page?)

The lesson here: language does matter. Mean what you say so your users get what they expect to from you.

Back on the form, I randomly picked the second prize package—or at least I tried to. When I clicked on its radio button, the prize lising popup window appeared again. The clickable area of the prize link was overlapping the clickable area of the radio button. I see why they did this—that prize link text is dang small. Expanding its clickable area (via padding in the CSS) helped me select it without having to be terribly precise. But when it came time to actually select a radio button, it made things worse.

The clickable area of the link overlaps the radio button, so clicking in the middle of the radio button selects the link, not the button.

I closed the popup and tried clicking on the label text “Maclaren Stroller & JJ Cole Package” right above the radio button. Alas, this did nothing, because this text was not actually marked up as a label element in the HTML. Finally, I was forced to very slowly and precisely move my cursor over the top half of the radio button, where I could finally click to select it.

Moving your cursor to the very top of the radio button finally lets you select it instead of the link below.

Radio buttons are small enough targets to hit as it is. Reducing their clickable area by half because you’ve overlapped them with the clickable area of an adjacent link makes using them ridiculously difficult. If the label text had been marked up as an actual label, I could have just clicked on this text to select its associated radio button. This helps people with mobility impairments, but as you can see from this example, it helps people without disabilities as well when space is tight and there are lots of little competing things to click on.

The lesson here: use label elements on form fields. Always. It really does matter.

zomigi.com » usability