Chris Heisel

There’s a layout battle brewing in the blogosphere that’s sure to ripple out to the rest of the Web design community.

Several prominent bloggers have begun switching to fixed-width layouts for their site. Whitespace makes several points about legibility and optimum line length being reasons to switch to fixed, as opposed to liquid, layouts.

The problem with fixed layouts in an era of font-resizing (you are using ems aren’t you?), is that optimum line length is a moving target. In the print world, optimum line length is based on the size of the typeface being used.

But if you’ve got a site that allows for font-resizing (which you should) or even if you don’t and your visitors are using browser like Mozilla, which will resize type no matter how you specify it, then all the work put into a fixed layout is blown out of the water by the user — who, rightfully so, has resized the type to fit their needs.

The only answer to the problem, and design is about solving problems, is to use a liquid layout.

If the user wnats big type and narrow columns — they can have it. If the user wants small type and wide columns — they can have it.

The legibility experts may say that goes against years of research (and they’d be right), but research is ultimately about averages — the average user wants x point size in columns y picas wide.

But on the Web we have the chance, and the ability, to easily let users take ownership of any site they want. So even if the user is a statistical outlier they can still be happy with your site.

This just in (12:16 p.m.): Stopdesign’s change is an experiment. He has a good discussion of the various factors involved, and brings up a good point about ems-based designs:

To solve the line-length issue, some have suggested setting column widths in “ems” so they will expand and shrink with text size. However, em-width columns can quickly extend beyond the width of the browser window after just a few increments of text-resizing, resulting in the awkward horizontal scroll bar. And even though this solves the line-length problem, we still have a “fixed width object inside liquid container” problem.

Flyout menus: I don’t like ’em. I don’t want ’em.

Recently, my employer, AJC.com, switched to using flyout menus, and many other Web sites and Web applications use them.

I understand the need. As a designer, you have to constantly make choices about how much information to present — what to hide, what to show. For a very deep site, it can be overwhelming to present all of the sections and sub-sections of site.

I personally tend to favor an approach that does some good top-level factoring so you can present the user with a decent number of choices that is not too over- or under-whelming.

Some designers turn to fly-out menus, which I can’t stand.

Why?

The fundamental user-interface on the Web is a click.

It’s a click on a link that takes a user to another page, a click on a submit button that activates a form, a click on the home button in the browser lets the user escape.

All fundamental change on the Web is started by a click.

Flyouts annoy me because they introduce a fundamental change — the layout changes, content and/or navigation may be covered up by the flyout — on hover.

Users may have to move their mouse across a page to access in-page navigation, browser navigation, scrollbars, other applications, etc. What I’m saying is, there’s a whole lot of moving going on, when it comes to the mouse.

Users may even move their mouse over link choices — expecting to see the URL in the status bar, or a title if its provided. They may move the mouse over the link as a virtual equivalent of running your hand over a shelf of books while looking for the right one.

Any way you slice it, it can be very disruptive to have a menu come flying out of nowhere.

If you have to obfuscate menu choices, then I think the better way to do it is with the Mac twister style.

What’s the Mac twist, well it goes like this:

If you’ve used the Mac Finder in “list mode” you can drill down to sub-folders within a window by clicking on the arrow next to a folder. Screenshots: Closed, Open.

One site that I use often, my Web host‘s control panel, uses Javascript to create a similar experience. Screenshots: Closed, Open.

For those with Javascript disabled, you’re taken to the first sub-menu option when you click on a top-level option, and on the page you’re taken to the menu has been expanded…

So, though I think having more options visable to start with can avoid a user jumping back and forth, if you’ve got to do DHTML menus, please let’s do the twist.