As the user resizes the window, resize the page contents along with it so that the page is constantly “filled.”
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), a high-information control such as a table or tree, or a graphic editor. This pattern doesn’t work as well when the visual design requires a certain amount of screen real estate, neither more nor less.
Unless you’re designing a “closed” UI such as a kiosk or a full-screen video game, you can’t predict the conditions under which users will view 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 toward 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 “nonliquid” 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 therefore robust design. But pages engineered to work nicely with window size changes generally also accommodate language or font size changes.
Make the page contents continuously “fill” the window as it changes size. Multiline text should wrap at the right margin until it becomes 10 to 12 words wide (more on that later). Text, trees, tables, graphs, and editors 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 (such as lists or tables) should lengthen, and possibly 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 scroll bars around it. Otherwise, whitespace should shrink as necessary; outright clipping may occur when the window gets really tiny, but the most important content should hang in there to the end.
If the interface shows 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 narrower, it’s too choppy to read easily.
(That being 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 Chapter 6 of the Usability.gov guidelines, in the section “Choose Appropriate Line Lengths.”)
Finally, there’s one more consideration that might sway you in favor of a liquid design: the iPad. Its browser cannot be wider than 768 pixels when the device is oriented vertically. If you’re designing a web page, can your content fit nicely in those 768 pixels? If not, how will your page look to iPad viewers? Mobile Safari does handle wide pages gracefully — they can be zoomed, and users can pan side-to-side easily — but for most text-heavy pages, the ideal layout would fit the viewport without needing that.
Mac OS allows you to resize the standard Open dialog box, which uses a Liquid Layout. This is good because the user can see as much of the filesystem hierarchy as he wants, rather than being constrained to a tiny predetermined space. See the example at the top of the pattern.
When a Liquid Layout is used on text in a browser, the floated elements should handle the resize gracefully, as in the Drupal.org example shown below. Note also that the text in this article never gets so wide as to be unreadable, even when the window itself is very wide.
Google Docs allows the user to shrink the window to a very narrow size. Though it places long toolbars across the top of the document, those toolbars wrap around and collapse gracefully as the window shrinks. (The user can’t resize it to be smaller than the smallest size shown here.)
In other libraries
Liquid Layout at Welie.com
Liquid Layout at Quince
Expanding Screen Width at Design of Sites