The Second Edition is out!
Visit designinginterfaces.com to read excerpts and learn more.

Liquid Layout


From http://wired.com

What:

As the user resizes the window, resize the page contents along with it so the page is constantly "filled."

Use when:

The user might want more space -- or less -- in which to show the content of a window, dialog box, or page. This is likely to happen whenever a page contains a lot of text (as in a web page), or a high-information control like a table or tree, or a graphic editor. It doesn't work as well when the visual design requires a certain amount of screen real estate, and no more or less.

Why:

Unless you're designing a "closed" UI like a kiosk, a handheld, or a full-screen video game, you can't predict the conditions under which the user views your UI. Screen size, font preferences, other windows on the screen, or the importance of any particular page to the user -- none of this is under your control. How, then, can you decide the one optimal page size for all users?

Giving the user a little control over the layout of the page makes your UI more flexible under changing conditions. It may also make the user feel less antagonistic towards the UI, since he can bend it to fit his immediate needs and contexts.

If you need more convincing, consider what happens to a fixed-layout, "non-liquid" UI when the language or font size changes. Do columns still line up? Do pages suddenly become too wide, or even clipped at the margins? If not, great; you have a simple and robust design. But pages engineered to work nicely with window size changes generally also accommodate language or font size changes.

How:

Make the page contents continuously "fill" the window as it changes size. Multiline text should wrap at the right margin, until it becomes ten to twelve words wide (more on that later). Trees, tables, editors, etc. at Center Stage should enlarge generously while their margins stay compact. If the page has anything form-like on it, horizontal stretching should cause text fields to elongate -- users will appreciate this if they need to type in anything longer than the text field's normal length. Likewise, anything scrolled (lists, tables, etc.) should lengthen, and usually widen too.

Web pages and similar UIs should allow the body content to fill the new space, while keeping navigational devices and signposts anchored to the top and left margins. Background colors and patterns should always fill the new space, even if the content itself cannot.

What happens when the window gets too small for its content? You could put scrollbars around it. Otherwise, white space should shrink as necessary; outright clipping may occur when the window gets really tiny, but the most important content hangs in there to the end.

If you deal with paragraphs of text, remember that they become nearly illegible when they're too wide. Graphic designers target an optimal line length for easy reading of text; one metric is 10 to 12 average English words per line. Another metric is 30 to 35 em-widths -- that is, the width of your font's lowercase "m". When your text gets much wider than that, users' eyes have to travel too far from the end of one line to the beginning of the next one; if it gets much narrower, it's too choppy to read easily.

(That said, there is evidence that text with a longer line length, such as 100 characters per line, is faster to read than shorter lines, even though users prefer to read lines fewer than 55 characters long. See the guidelines at http://usability.gov, especially "Use Reading Performance or User Preference.")

A well-behaved Liquid Layout can be difficult to implement in complex web pages, especially if you want to dispense with tables and use straight CSS. It's also hard in Visual Basic and Visual C++ (or was, at least, for a long time). However, Java provides several layout managers you can use to implement it.

Examples:


From a file-open dialog in Mac OS X.

Mac OS X allows you to resize the standard "Open" dialog box, which uses a liquid layout. This is good because users can see as much of the filesystem hierarchy as they want, rather than being constrained to a tiny predetermined space. (The Cascading Lists pattern is used in this dialog, too.)