designing layout of nature video

Get Designing Interfaces now with O'Reilly online learning.

O'Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.

Chapter 4. Organizing the Page:Layout of Page Elements

Page layout is the art of manipulating the user's attention on a page to convey meaning, sequence, and points of interaction.

If the word "manipulating" sounds unseemly to you, think about it this way. Film and television directors make their living by manipulating your attention on the movie or TV screen, and you are presumably a willing participant. Likewise for editors who arrange articles, headlines, and ads on a newspaper. If all this content were presented in a drab monotone, with no graphic emphasis to grab and move your attention, you would actually find it harder to extract meaning—what's supposed to be important, and what's not?

Even though it is ultimately an art, there might be more rationality to good page layout than you think. Some important ideas from graphic design are explained in this chapter introduction; each can guide you in the layout of pages, screens, and dialog boxes. We'll talk about visual hierarchy, visual flow and focal points, and grouping and alignment—all are predictable and rational approaches to page design. This chapter's patterns describe concrete ways to apply those high-level concepts to interface design.

But the changeable, interactive nature of computer displays makes layout easier in some ways, harder in others. We'll talk about why that's true. Some of these patterns work as well in print as they do onscreen, but most of them would be useless in print because they presume that the user will interact with the page.

THE BASICS OF PAGE LAYOUT

This section discusses five major elements of page layout: visual hierarchy, visual flow, grouping and alignment, how to put these three elements together, and how to use dynamic displays.

VISUAL HIERARCHY: WHAT'S IMPORTANT?

The concept of visual hierarchy plays a part in all forms of graphic design. Put simply, the most important content should stand out the most, and the least important should stand out the least. Titles ought to look like titles, and secondary content ought to look like secondary content—in other words, a reader should be able to deduce the informational structure of the page from its layout.

Examples explain this concept best. Figure 4-1 shows text that wasn't formatted with any visual hierarchy at all.

Figure 4-1. No visual hierarchy

Passable, but not great. What's the most important information in that paragraph? You can guess that the first sentence is the most important, but otherwise, it's hard to tell, since the whole block of text is visually monotonous. Once you've read it and realize it's an invitation, you can tell from context—but you had to read it first.

Now let's improve on this example. Whitespace is one of the best tools you have for organizing a visual hierarchy. It's a cheap and graceful way of pulling apart monotonous blocks of information.

Figure 4-2. With whitespace

In Figure 4-2, you can at least see distinct groups of information. And the headline at the top—"Zelda's 30th Birthday Party"—stands out a bit more because it has whitespace around it. So does the not-quite-as-important RSVP message at the bottom. But the text that your eye falls on first is probably "You're invited to". It's sitting up there by itself, at the upper left corner, where every speaker of left-to-right languages looks first. That alone gives it unwarranted importance.

You also have typography and positioning at your disposal, which Figure 4-3 applies to the same problem.

Figure 4-3. With typography and alignment

Big, bold fonts do the trick for importance, of course. Our eyes are drawn to dense, contrasted shapes with heavy "visual weight." The invitation's most important line is in a giant font; the second most important line is in a large font, but not as large; the body text is normal sized. Similarly, the tiny lightweight font used for the directions comment indicates "you may want to read this, but it's not that big a deal if you miss it."

Spatial positioning does something a little more complex here. It's being redundant with the whitespace by separating some blocks of text from others. It's also enhancing the apparent importance of the "When" and "Where" text—which are important—by making them stand on the almost-empty left margin, aligned with the headline.

The shapes of some page elements give you clues, too. The comment about directions is indented underneath the "Where" text in the example. You can guess that the directions comment relates to, but is not as important as, the text above it. The same logic applies to tree views, auxiliary text under links, input hints under text fields, and so forth. With these and other familiar structures, like tables, their visual shapes "telegraph" meaning immediately, before the user even starts to read what's in them.

In this chapter, the Center Stage pattern deals directly with visual hierarchy by encouraging you to establish a single large area of the UI to do the main task. Using the Titled Sections pattern helps define the visual hierarchy, too. And if you develop a Visual Framework (another pattern, which encodes how to do visual hierarchy within the whole UI), make sure it accommodates the different levels of hierarchy you need, such as titles, headlines, sub-heads, lists, navigation bars, and action buttons.

These mechanisms can help you lay out a visual hierarchy:

• Upper-left-corner preference

• Whitespace

• Contrasting fonts: the bigger and bolder, the more important the information

• Contrasting foreground and background colors: putting white text on a black background, for instance, makes a very strong statement on a white page

• Positioning, alignment, and indenting: indented text is subordinate to whatever's above it

• Graphics such as lines, boxes, and colored bars: things in a box or group go together

You'll find that many UIs and printed graphics use several of these mechanisms at once. Web pages frequently use both color and fonts to differentiate headlines from body text; many UIs use both group boxes and whitespace to form visual groups. That's okay. Having all these "variables" to choose from gives you a lot of design freedom, especially since they each have a dual role: to show how the UI is organized, and to communicate branding, emotion, and other non-rational attributes. (I'll return to this fascinating topic in Chapter 9.)

Meanwhile, let's look more deeply at visual organization.

VISUAL FLOW: WHAT SHOULD I LOOK AT NEXT?

Visual flow deals with the tracks that readers' eyes tend to follow as they scan the page. It's intimately related to visual hierarchy, of course—a well-designed visual hierarchy sets up focal points on the page wherever you need to draw attention to the most important elements, and visual flow leads the eyes from those points into the less-important information. As a designer, you should be able to control visual flow on a page so people follow it in approximately the right sequence.

Several forces can work against each other when you try to set up a visual flow. One is our tendency to read top-to-bottom and left-to-right. When faced with a monotonous page of text, that's what you'll do naturally; but any visual focal points on the page can distract you from the usual progression, for better or worse.

"Focal points" are the spots your eyes can't resist going to. You tend to follow them from strongest to weakest, and the better pages have only a few—having too many focal points dilutes the importance of each one. You can set them up in many different ways, such as by using whitespace, high contrast, big chunky fonts, spots of "interesting" color, converging lines, hard edges, faces, and motion. (Yes, this list resembles the one above for visual hierarchy. Titles, logos, and critical sections of text or images use these properties to become focal points.)

The next time you pick up a magazine, look at some well-designed ads and notice what your eyes gravitate toward. The best commercial graphic artists are masters at setting up focal points to manipulate what you see first.

However, if you've ever brought up an ad-filled web page and pointedly ignored the brightly-colored moving ads (so you could read the monotonous blocks of text that you went there to read), then you know that we're not merely slaves to our hardwired visual systems! We can choose to ignore what we think we don't need to look at, and zero in on what we think is the important part of the page. Thus meaning and context also play a big part in visual flow.

If you build a UI in which sequence makes a difference—like a Wizard, or a dialog box in which early choices affect later choices—then think about visual flow. (Even if your UI does not depend upon sequence, you should think about it anyway, since a good visual flow is easier on your users' eyes.) It's not hard to set up a layout that flows well, but be on your guard against layout choices that work against it. Place your controls and buttons along a straightforward visual path. At the end of that path, put the link or button that finishes the task ("Submit," "Return to main page," or "OK") and brings the user somewhere else.

Figure 4-4 shows a dialog box with a nice visual flow. Notice how your eyes start at the top, move straight down the column of text fields (perhaps slowing down at the horizontal lines), and "land" at the four icons. After pausing there to take them in, perhaps, your eyes may hop down to either the Help or the OK and Cancel buttons.

Figure 4-4. Macromedia Contribute's "Insert Table" dialog box

Now, at some point you'll probably take the time to read the labels, but they're so visually lightweight that they likely didn't catch your eye first. The text fields probably did, because they're focal points—white (contrasting against gray), strongly aligned, and semantically important.

In summary:

• Top-to-bottom and left-to-right is the default visual flow.

• Strong focal points will draw the eyes first, followed by weaker ones.

• The perceived meaning of the page content will change where the user chooses to look.

GROUPING AND ALIGNMENT: WHAT GOES WITH WHAT?

You knew this already, but I'll say it anyway because it's so important: by grouping things together visually, you state that they are related. Conversely, if you put two things far away from each other, such as the last field of a form and the form's "Submit" button, then you state that they're not related to each other. If visual flow doesn't step in and lead the user's eyes to the button by some other means, the user may not see it.

Like focal points, grouping and alignment are necessary to forming a clear visual hierarchy. They also help with visual flow, by guiding the viewer's eyes from group to group.

The human visual system craves order. We're wired to see larger forms made from smaller ones, like words from letters or tables from grids of cells. You can take advantage of this need for order by "clustering" related things together, and by separating those clusters with enough whitespace to keep them unambiguously separate. (Whitespace again! It's really okay to use it, even in small spaces. It's better to display less information with more clarity than to crowd a page too much.) This is how you associate a text field with its label, an image with its caption, or a graph with the slider that controls it.

Group boxes can help here, but don't expect them to carry the entire burden of visual grouping; give them "room to breathe" on a crowded page. If you squint your eyes so you can't see the group box's edges, is there enough whitespace that you can still make out the groups? If so, you're doing fine. Also, be careful about nesting group boxes two or more levels deep, since it gets really hard to make out what's what. Try a different approach to designing the visual hierarchy.

Alignment is another, more subtle way to associate things with one another. For instance, if you have two sets of buttons far away from each other on a dialog box, but they do somewhat similar things, you can line up one group under the other and make them the same width to emphasize the similarity. Or if you have two forms on a page, separated by blocks of text, then line up the forms' left edges against one invisible line and the texts' left edges against another.

The theory behind grouping and alignment was developed early in the 20th century by the Gestalt psychologists. They described several layout properties that seem to be hardwired into our visual systems. Among them are the following:

Proximity

Put things close together, and viewers will associate them with one another. This is the basis for strong grouping of content and controls on a UI.

Similarity

If two things are the same shape, size, color, or orientation, then viewers will also associate them with each other.

Continuity

Our eyes want to see continuous lines and curves formed by the alignment of smaller elements.

Closure

We also want to see simple closed forms, like rectangles and blobs of whitespace, that aren't explicitly drawn for us. Groups of things often appear to be closed forms.

Figure 4-5 depicts each property and how you can combine them to create an effective overall design.

Figure 4-5. Four of the Gestalt principles

As important as they are individually, they're best used in combination with one another. Once again, redundancy is not always bad; the fifth grouping looks more like an actual page layout than a retro-styled mosaic.

Continuity and closure, then, explain alignment. When you align things, you form a continuous line with their edges, and the users follow that line and (perhaps subconsciously) assume a relationship. If the aligned items are coherent enough to form a shape—or to form one out of the whitespace or "negative space" around it—then closure is also at work, adding to the effect.

PUTTING IT ALL TOGETHER

On the web page shown in Figure 4-6, the text is blurred so that you can't read it easily. But I bet you can understand a lot of the page structure.

In your first glance, you just perceived many of the things we just talked about. Let's deconstruct that first glance. First, what path did your eyes follow? Probably one of those in Figure 4-7, or some variation thereof.

Figure 4-7. Possible visual flows on alistapart.com

The logo is obviously a focal point—it sits where web page headers always sit, and it's a heavy font with high white-on-dark contrast. The headlines draw attention because of their color, size, and whitespace separation. The column on the right looks dense, orange, and visually interesting, so you may have looked at it too.

Note that the third visual-flow variation doesn't start at the logo. Readers who visit a page with single-minded interest in the content may simply ignore the header and start at the upper left of the "white part" of the page—there's no perceived benefit in looking at the page trappings.

Now what about the Gestalt principles we just covered? The page presents three main groups, each of which has big red text, smaller red text, and blocks of body text. Similarity and proximity form these perceptual groups; whitespace sets them apart. The column on the right is set off by a very strong edge—actually, two of them; note the subcolumn along its left side—and its density and color give this strong coherence. The dark background of the header comprises another visual form, does the gray footer, with its single continuous line of text. Figure 4-8 shows the groupings on this page.

Figure 4-8. Grouping on the ALA web page

All this formatting contributes to the visual hierarchy. Context and higher-level mental processing kick in as you start to parse what you see and apply what you already know about web sites.

You can easily distinguish the header, footer, main content, and auxiliary information. Within the main content, there are three points of interest—probably linked articles—each with its header, subheaders (bylines?), and body text. Within the auxiliary information, there's a mini-form (search?), two tables (probably containing links, since they're not black), and other text. The header contains five texts that are aligned and look similar, probably top-level navigation. You can safely ignore the footer, as you probably do on most web pages.

USING DYNAMIC DISPLAYS

Everything I've discussed so far applies equally to UIs, web sites, posters, billboards, and magazine pages. They deal with static aspects of layout. Ah, but you have a dynamic computer display to work with—and suddenly time becomes another dimension of design! Just as importantly, computers permit user interaction with the layout to an extent that most printed things can't.

There are many, many ways you can take advantage of the dynamic nature of computer displays. You can concentrate on space usage, for example—even the biggest consumer-grade computer screens have less usable space than, say, a poster or a newspaper page. That's life. If you work with PDAs or cell phones, you've got an especially tiny space to work in. There are many techniques for using that space to present more content than you can show at one time.

Using scrollbars is one common way of presenting a small "viewport" onto a large thing, like text, an image, or a table. Scrollbars let the user move around at will, in one or two dimensions. (But refrain from using horizontal scrolling with text, please).

Or, if you can carve up the content into coherent sections, you have several options— Card Stacks, Closable Panels , and Movable Panels all put some layout control into the user's hands, unlike the more static Titled Sections . (You also can split up content over multiple virtual pages and let the user navigate between them; see Chapter 3, Navigation .) They invoke time by letting the user see various content at different times of their choosing.

If you want to direct the user through a sequence of steps, Responsive Enabling and Responsive Disclosure are two well-known, dynamic ways of doing so.

THE PATTERNS

This chapter's patterns give you specific ways to put all these layout concepts into play.

The first two, Visual Framework and Center Stage , address the visual hierarchy of the whole page, screen, or window, regardless of the type of content you put into that page. You should consider Visual Framework early in a project, since it affects all the major pages and windows in an interface.

• Visual Framework

• Center Stage

The next group of patterns represents four alternative ways of "chunking" content on a page or window. They're useful when you have a lot of stuff to show on the page at once. Once you've made a decision to break up your content into thematic sections, you need to choose how to present them. Should they all be visible at once, or can they (or should they) be viewed independently? Is it okay for users to manipulate those sections on the page? These patterns deal with visual hierarchy, but they also involve interactivity, and will help you choose among the specific mechanisms available in UI toolkits.

• Titled Sections

• Card Stack

• Closable Panels

• Movable Panels

Right/Left Alignment and Diagonal Balance draw on the concepts of visual flow, alignment, and other things discussed in this introduction. They deal with the spatial relationships among smaller, more static elements on a page, like text and controls.

• Right/Left Alignment

• Diagonal Balance

The Property Sheet pattern is a little unusual. It too talks about spatial relationships among smaller page elements, but it's as much about content and interaction as it is about layout. It's here because when a knowledgeable user recognizes that a page has a Property Sheet on it, their expectations are set quite strongly. The layout tells the user precisely how they should interact with the page.

• Property Sheet

The last three patterns deal with the dynamic aspects of content layout. Responsive Disclosure and Responsive Enabling are two ways of directing a user through a series of steps or a set of options; they indicate what can be done at any point in time, while preventing the user from straying into areas that will get them into trouble. Liquid Layout is a technique for arranging a page that can change size and shape at the user's whim.

• Responsive Disclosure

• Responsive Enabling

• Liquid Layout

visual framework

what

Design each page to use the same basic layout, colors, and stylistic elements, but give the design enough flexibility to handle varying page content.

use when

You've built a web site with multiple pages, or a UI with multiple windows—in other words, almost any complex software. You want it to "hang together" and look like one thing, deliberately designed; it should be easy to use and navigate.

why

When a UI uses consistent color, font, and layout, and when titles and navigational aids—signposts—are in the same place every time, users know where they are and where to find things. They don't have to figure out a new layout each time they switch context from one page or window to another.

Have you ever seen a book in which the page numbers and headings were in a different place on each page?

A strong visual framework, repeated on each page, helps the page content stand out more. That which is constant fades into the background of the user's awareness; that which changes is noticed. Further-more, adding character to the design of the visual framework helps with the branding of your web site or product—the pages become recognizable as yours.

how

Draw up an overall look-and-feel for each page or window in the thing you build. Home pages and main windows are "special" and are usually laid out a little differently from subsidiary pages, but they still should share certain characteristics with the rest of the artifact. For example:

• Color: backgrounds, text colors, and accent colors

• Fonts: for titles, subtitles, ordinary text, and minor text

• Writing style and grammar: titles, names, content, short descriptions, any long blocks of text, anything that uses language

All other pages or windows should also share the following, as appropriate.

• "You are here" signposts: titles, logos, breadcrumb trails, and Card Stack indexes such as tabs or link columns

• Navigational devices: sets of standard links, OK/Cancel buttons, back buttons, "quit" or "exit" buttons, and navigational patterns Global Navigation, Sequence Map and Breadcrumbs (all Chapter 3)

• Techniques used to define Titled Sections

• Spacing and alignment: page margins, line spacing, the gaps between labels and their associated controls, and text and label justification

• Overall layout grid: the placement of things on the page, in columns and/or rows, taking into account the margins and spacing issues listed earlier

If you're familiar with graphic design concepts, you may recognize some of these techniques as comprising a layout grid. A layout grid is a structural template for a set of pages or layouts. Each individual page is different, but all pages use specified margins and align their contents along invisible gridlines. A good Visual Framework does indeed include a layout grid, but it also includes other aspects of look-and-feel, such as colors, visual details, and writing style.

Implementation Visual Framework force you to separate stylistic aspects of the UI from the content. This isn't a bad thing. If you define the framework in only one place—such as a CSS stylesheet or a Java class—it lets you change the framework independently from the content, which means you can tweak it and get it right more easily. (It's software practice.)

examples

Figure 4-10. The Windows and Mac OS look-and-feels help to implement a visual framework, since colors, fonts, and controls are fairly standard. But you need to add the higher-level structure, like the layout grid and language. These Excel screenshots both come from the same dialog box—Page Setup—and they illustrate the concept well. All these characteristics are consistent from page to page: location of action buttons in the upper and lower right; margin size, indenting, and vertical distance between text fields; extension of text fields to the right edge; the use of labeled separators (such as "Print titles" and "Orientation") to delimit Titled Sections; and capitalization and grammar.

Figure 4-11. Web page designers know how to apply this concept well. Google's pages are simple and unfussy, but very, very recognizable. All signposts are clear and consistent—the logo, the page title and subtitle ("Image Search" and "Groups"), and the other links—and the all-important search field always is in the same place!

center stage

Figure 4-12. Flax MX

what

Put the most important part of the UI into the largest subsection of the page or window; cluster secondary tools and content around it in smaller panels.

use when

The page's primary ob is to show coherent information to the user, let him edit document, or enable him to perform a certain task. Most applications can use Center Stage—tables and spread-sheets, forms, web pages, and graphical editors all qualify.

why

You should guide the user's eyes immediately to the start of the most important information (or task), rather than letting them wander over the page in confusion. An unambiguous central entity anchors their attention. Just as the lead sentence in a news article establishes the subject matter and purpose of the article, so the entity in Center Stage^[1] establishes the purpose of the UI.

Once that's done, the user will assess the items in the periphery in terms of how they relate to what's in the center. This is easier for the user than repeatedly scanning the page, trying to figure out—what comes first? What's second? How does this relate to that? And so on.

how

Establish a visual hierarchy, with the "center stage" dominating everything else. (See the chapter introduction for discussion of visual hierarchy.) When designing a Center Stage, consider these factors, are absolutely required:

Size

The Center Stage content should be at least twice as wide as whatever is in its side margins, and twice as tall as its top and bottom margins. (The user may change its size, but this is how it should be when the user first sees it.)

Color

Use a color that contrasts with the information in the margins. In desktop UIs, white works well against Windows gray, especially for tables and trees. As it happens, white often works in web pages too, since ads and navigation bars usually use other colors as their backgrounds; also, web users are "trained" by convention to look for the plain text on a white background.

Headlines

Big headlines are focal points, and can draw the user's eye to the top of the Center Stage. That happens in print media too, of course. See the chapter introduction and Titled Sections for more on headlines and focal points.

Context

What does the user expect to see when she opens up the page? A graphic editor? A long text article? A map? A filesystem tree? Work with her preconceptions; put that in center stage and make it recognizable. The user will look for it—this trumps all other rules about visual perception. (But it doesn't mean you can frustrate her by hiding what she's looking for! Some web sites put their main content so far down the page that it's "below the fold" in short windows, requiring the user to scroll down to find it. That's just sadistic.)

Notice that I did not mention one traditional layout variable: position. It doesn't much matter where you put the center stage—top, left, right, bottom, center, all of them can be made to work. If it's big enough, it'll end up more or less in the center anyway. Keep in mind that well-established genres have conventions about what into margins—e.g., toolbars on top of graphic editors, or navigation bars on the left sides of web pages. Be creative, but with your eyes open.

If you're in doubt, take a screenshot of the layout, shrink it down, blur it, and ask someone where on the page they think the main content should start. Again, see the chapter introduction for an example.

examples

Figure 4-13. Most blogs tend to have cluttered layouts; it's a rare blog that sets its main content into a strong center stage. Take a look at this screenshot from http://boingboing.net. The ads and other marginal content do attract attention, but the middle column, containing the blog entry, is very wide in comparison. It also starts close to the top of the screen—the header is blessedly short. The eye is drawn easily to the top article.

Figure 4-14. To drive home the point, look what happens when the major page sections are abstracted out as plain rectangles. It may not look very wide in the screenshot, but that center column is over three times as wide as the lefthand column of ads. It needs that much width to compete with the ads' flashy colors and contrast.

Figure 4-15. Google Maps is a clean, uncluttered interface. The map easily takes center stage by using size and color: it occupies most of the window, and it's colorful, in contrast to the white-background tools at the top and right.

titled sections

what

Define separate sections of content by giving each one a visually strong title, and then laying them all out on the page together.

use when

There's a lot of content on the page, but you want to make the page easy to scan and understand. You can group the content into thematic or task-based sections that make sense to the user.

why

Well-defined and well-named sections structure the content into easily digestible chunks, each of which is now understandable at a glance. It makes information architecture obvious. chapter's introduction for a discussion of visual hierarchy, which is basically about rendering content in a way that communicates its actual structure. See also Chapter 2 for a definition of information architecture.)

When the user sees a page sectioned neatly into chunks like this, it guides her eye along the page more comfortably. The human visual system always looks for bigger patterns, whether they're deliberate or not. So put them in deliberately!

how

First, get the information architecture right—split up the content into coherent chunks, and give them short, memorable names (one or two words, if possible). Next, choose a presentation:

• For titles, use a font that stands out from the rest of the content—bold, wider, larger point size, stronger color, etc. (Remember that nothing's stronger than black, not even red.)

• Try reversing the title against a strip of contrasting color. White on dark can make it look like a Windows titlebar.

• Use whitespace to separate sections.

• Putting sections on different background colors works well on web pages and interfaces that want to look like web pages, though it's unusual on desktop UIs.

• Boxes made from etched, beveled, or raised lines are familiar on desktop UIs. They can get lost—and just become visual noise—if they're too big, too close to each other, or deeply nested. It can be done well when combined with the title; see the examples.

If the page is still too hard to read, try using Card StackTwo-Panel Selector , or Extras on Demand to manage it all. You can combine some of these patterns with Titled Sections, too. Elsewhere in this chapter, Closable Panels and Movable Panels are alternative ways of presenting "chunked" content.

If you're having trouble giving reasonable titles to these chunks of content, that may be a sign that the grouping isn't a natural fit for the content. Consider reorganizing it into different chunks that are easier to name and remember. "Miscellaneous" categories may also be a sign of not-quite-right organization, though sometimes they're genuinely necessary.

examples

Figure 4-17. Typical usage of Titled Sections in desktop applications. In Eudora's preferences dialog, the boxes look good around the grids of checkboxes, the bold titles stand out clearly, and there is sufficient whitespace between the sections to give them visual "breathing room." (In fact, this example would work even if the boxes were erased.)

Figure 4-18. This screenshot came from a long page full of Java documentation. Each section is labeled with the blue bars, which are very easy to find and read as the user scrolls rapidly down the page. Notice the use of visual hierarchy here: the main sections are marked with large fonts and darker color, while the minor section at the bottom uses a smaller font and lighter color. At the next level down the hierarchy, the names of classes and methods stand out because they're green and outdented; finally, the body text is small and black, as body text usually is.

card stack

Figure 4-19. Internet Explorer properties dialog box

what

Put sections of content onto separate panels or "cards," and stack them up so only one is visible at a time; use tabs or other devices to give users access to them.

use when

There's too much material on the page. A lot of controls or texts are spread across the UI, without the benefit of a very rigid structure (like a Property Sheet ); the user's attention becomes distracted. You can group the content into Titled Sections , but they would be too big to fit on the page all at once. Finally—and this is important—users don't need to see more than one section at one time.

why

The labeled "cards" structure content into easily-digestible chunks, each of which is now understandable at glance. Also, tabs, the most common form of Card Stack, are very familiar to users.

how

First, get the information architecture right. Split up the content into coherent chunks, and give them short, memorable titles (one or two words, if possible). Remember that if you split the content up wrong, users must switch back and forth between cards as they enter information or compare things. Be kind to your users and test the way you've organized it.

Then choose a presentation:

• Tabs are great, but they usually require six or fewer cards. Don't "double-row" them, since double rowing is almost never easy to use; scroll them horizontally if they won't fit in one row all at once.

• Vertical tabs let you force a Card Stack into a narrow, tall space that can't accommodate normal tab pages.

• A lefthand column of names works well on many web pages and dialog boxes. You can fit a lot of cards into a column. It lets you organize cards into a hierarchy, too, which you really can't do with tabs. (At some point it becomes more like a Two-Panel Selector ; there's really no clear boundary between them.)

• Some UIs have a drop-down list at the top of the page, which takes less space than a link column, but at the cost of clarity: drop-down lists usually behave like controls, and a user might not recognize it as a navigational device. It can work if the containment is very obvious; see the OS X example in Figure 4-23. But the user still can't see all the card titles at once.

If you want an alternative to Card Stack that lets people view two or more cards at one time, look at Closable Panels . They don't have the metaphoric power of tabs, but they can be quite effective for users who are motivated to learn how to use them.

examples

Figure 4-20. You can draw tabs in any number of ways, and they don't have to start on the left side. This is from the Theban Mapping Project web application. See http://thebanmappingproject.org.

Figure 4-21. Netscape imposes different physical constraints. The "tab" buttons in this sidebar are stacked vertically, and they move from top to bottom as the user clicks them, so now the selected page always has its button directly above it. This is an interesting solution for a constrained, vertically oriented space. (It originally was seen in early versions of Visio.)

Figure 4-22. Here's another implementation of a vertical Card Stack, one that doesn't even pretend to use tabs. This Nike web application has you click on the orange horizontal bars to show one pane at a time.

Figure 4-23. Sometimes applications use dropdown lists where tabs might have been used. This is the "Copies & Pages" page in OS X Internet Explorer's print dialog box. Dropdowns are space conserving, and allow long and numerous page names, but the user can't see what other pages are available until she opens the drop-down list. Note the two separators above and below the controls; a user needs this kind of containment to understand what the dropdown does. Otherwise, it just looks like another control, not a navigational device. It's not as easy to use as tabs.

closable panels

Figure 4-24. Dreamweaver MX

what

Put sections of content onto separate panels, and let the user open and close each of them separately from the others.

use when

There's too much stuff to present on the page, but you want it all only one click away. The content is divisible into clearly named sections, as with Titled Sections and Card Stack . The user may want to see two or more at a time.

Specifically, this is a useful concrete implementation of Extras on Demand. If you've organized your content using Extras on Demand, you may want to use some form of Closable Panel to hold those extras.

why

You would Closable Panels in many places where you might use a Card Stack —it's a space-saving device that depends on a user clicking it to get at it. However, Closable Panels gives you a little more flexibility:

• It can contain sections of wildly differing sizes. If you used a Card Stack with sections of various sizes, the smaller sections would have large areas of whitespace, which is awkward.

• The user can open several sections at once. That's especially nice in authoring tools, and for "power users" of all kinds of complex applications—at the user's discretion, they can simultaneously open many panels and keep them in view all the time.

• If you create only one closable panel and embed it in a larger page or dialog box, that panel looks less important than the content it's embedded in. If you put both sections into two tab pages, however, they appear to be of equal importance.

There is a cost to using these panels. Tab pages are well understood by most people, but Closable Panels are not as common—they won't be familiar to everyone at first. Usability testing is recommended. Furthermore, the ability to open many sections at once may backfire by making the environment too cluttered and unusable.

how

Divide your content into sections, name them appropriately, and put them into panels that appear and disappear when you click a button or link. Put an arrow, plus sign, triangle, or chevron (">>") on that button or link—doing so hints to the user that something will open or close. In many applications, the triangle points down to the open panel when open, and to the right when closed; these are sometimes termed "twist-downs."

In most applications where you use this device, the window containing the Closable Panel(s) grows and shrinks as the panel is opened and closed. You might also (or additionally) put it in a scrolling panel, or into resizable panes, as in the Dreamweaver example at the top of this pattern.

Also note the use of a Card Stack nested inside a Closable Panel. You can use it if you have a very large number of sections to deal with, and if they fit into a two-level hierarchical organization (e.g., the "Design" section contains subsections named "CSS Styles," "HTML Styles," and "Behaviors").

This technique has existed since at least 1993, and possibly earlier. The Motif-based GUI builder called UIM/X used closable panels—even with the twist-down arrows—for its widget palettes.

examples

Figure 4-25. Thinkmap's Visual Thesaurus is a web application that uses Closable Panels. The colored titlebars delineate four sections that you can turn on and off at will, via the On/Off radio buttons. You also can drag the titlebars to resize the sections. The user gets more control over what he sees on the interface—if the four sections make it too cluttered, he can turn off the least relevant ones. See http://visualthesaurus.com.

Figure 4-26. Visual Studio's property sheets use Closable Panels to categorize its numerous properties by topic. A user who isn't interested in the Accessibility or Appearance properties, for instance, can close them up while she concentrates on the other properties. Instead of a triangle, Visual Studio uses pluses-in-squares, just like the Windows treeview control. Even though this isn't a treeview, it takes advantage of what users already know: you click on the plus to open something, and click on the minus to close it.

Figure 4-27. Here's an example of this pattern used in a web page. Flickr displays small, delicate closable panels with each image, showing related images or other images in a sequence. You can open and close them with buttons labeled with "+" or "-".

Figure 4-28. This screenshot of A9, Amazon's multidimensional search facility, shows three out of a possible nine (!) panels. Each panel is a resizable vertical column—the bars between them are draggable, so the user can widen or narrow the panels as needed. The button column on the right acts as a control center of sorts, letting the user show and hide various panels; but for local maximizing and closing of the panels, two button-like links beside each panel's titlebar read "[close]" and "[full]." They're redundant with the check-button column, but that's okay. Notice that the titles of the A9 panels don't really stand out much. There is a visual hierarchy on this page, but it's hard to make out—strong titles would have helped define the three panels. Bolder fonts, horizontal rules below the titles, or colored backgrounds would do the trick. (But consider this: if those titles had been put against stripes of contrasting color, for example, they'd look like actual titlebars. Wouldn't users try to grab and move those titlebars? Would that be a bad thing, if it worked?)

movable panels

Figure 4-29. MATLAB

what

Put different tools or sections of content onto separate panels, and let the user move them around to form a custom layout.

use when

The page has several coherent interface "pieces" that don't really need to be laid out in one single configuration; their meanings are self-evident to users, regardless of their location on the page. You may want users to feel some sense of ownership of the software, or at least have fun playing with it.

why

When they are working on something for a while, people like to rearrange their environment to suit their working style. They can place needed tools close to where they work; hide things they don't need; and use Spatial Memory (Chapter 1) to remember where they put things. Rationally speaking, Movable Panels helps users get things done more efficiently and comfortably (in the long run—once they've spent time rearranging it to the way they like it!).

But this kind of personalization seems to appeal to people on some other level, too. They may personalize infrequently visited web sites that provide entertainment, for instance.

how

Let the user move the UI pieces around the page at will. Save the layout for the next time the user resumes using the software, especially if it's an important part of his daily life.

Depending upon the design you've chosen, you may want to give the user freedom to place these pieces anywhere, even if they overlap. Or you may want a prescribed layout grid with "slots" where pieces can be dropped—this lets the page maintain alignment (and some sense of dignity!) without making the user spend too much time fiddling with windows.

If the movable panels react to mouse drags, such as for text selection, consider putting a "handle" on each piece that the user can grab to move the piece around. Titlebars are good for this. In fact, if you put an "X" on the handle, some users will conclude that that is how they get rid of a piece entirely. (If you implement this, of course, offer a way to recreate the pieces that are gone!).

Your users might appreciate a "Revert to Default Layout" action somewhere on the UI, if they get completely tangled up and just want to start over. When you usability-test Movable Panels, watch especially for accidental panel moves—a user who unintentionally drags a panel into an odd place may not know immediately what he did or how to undo it.

examples

Figure 4-30. The three pieces that make up Winamp can be hidden, shown, rearranged, even separated completely from each other and moved independently. The user can move a piece by dragging its titlebar; that titlebar also has Minimize and Hide buttons. You can bring back hidden pieces via pop up menu items. In this screenshot, you can see Winamp's default configuration.

Figure 4-31. Here, Winamp is disassembled and rearranged.

right/left alignment

Figure 4-32. Part of a dialog box from Macromedia Contribute

what

When designing a two-column form or table, right-align the labels on the left, and left-align the items on the right.

use when

You're laying out a form, or any other set of items that have text labels in front of them. This also could apply to the internal structure of tables, or any other two-column structure in which the rows should be read left-to-right.

why

When you put text right next to the thing it labels, you form a strong perceptual grouping of that pair—much more so than if they were separated by a large amount of space. If you align variable-length labels along their left sides, the short labels won't be close enough to their controls, and the side-to-side grouping is broken. (This is the Gestalt principle of proximity at work.) In short, people more easily connect each label to its associated control when they see right/left alignment.

Meanwhile, you should always left-align controls. When combined with the right-aligned labels and a uniform spacing between them, they help form a nice strong double edge down the middle of the whole thing (taking advantage of continuity , another Gestalt principle). This powerful edge guides the viewer's eyes smoothly down the page, supporting a good visual flow.

In some layouts, right-aligning the labels just doesn't look good. The labels might have widely varying widths, a column of icons might stand to the left of the labels, or perhaps left-aligned titles separate the form's sections—all of these formats can ruin a right/left alignment (though not necessarily). Go with what works.

how

Instead of left-aligning each text label, right-align it. Bring it up close to its control, separated by only a few pixels. The net effect probably will be a ragged (unaligned) left edge—that's usually OK. If some labels are too long to make this work, try breaking them into multiple lines, or resort to putting the labels above the control, in which case this pattern becomes irrelevant.

Then left-align the controls against an imaginary line a few pixels away from the right edges of the labels. Make them precisely aligned, pixel-perfect—if they're not, the controls will look messy. (The human visual system is really good at picking out slight misalignments!)

Again, the other edge of the control column may be ragged. That's not so good if you're dealing with text fields, combo boxes, and other visually "heavy" objects, as in Figure 4-32. Try to stretch them so their right edges are aligned, too, to whatever extent you can. You also can try to align the short ones with one another, and the long ones with one another.

examples

Figure 4-33. This pattern also works with layouts that have no input controls at all. This Mac OS X address-book entry has very little whitespace between the two columns, but the difference in color helps to separate them visually. Notice that the label "home page" is much longer than the others; this would have made a lefthand label alignment less pleasing to the eye, and harder to read.

Figure 4-34. Again, the widely varying label lengths mean that a lefthand label alignment would put the labels far, far away from their referents. This is easier to read.

diagonal balance

Figure 4-35. Word's Graph Options dialog box

what

Arrange page elements in an asymmetric fashion, but balance it by putting visual weight into both the upper-left and lower-right corners.

use when

You lay out a page or dialog box that has a title or header at the top, and some links or action buttons—such as OK and Cancel, Submit, or Back and Next—at the bottom. The page is short enough to fit on the screen without scrolling.

why

Visually prominent features such as titles, tabs, and buttons should contribute to a balanced composition on the screen. They're already at opposite ends of the page; when you put them on opposite sides too, they often balance one another out. (Think of them as weights—the bigger or more "contrasty" the features are, the heavier they are; the closer to the edge they get, the more you need to put on the other side to compensate.)

Besides being nicer to look at, a diagonal balance also sets up the page so that the user's eye moves easily from the top left to the bottom right—an ideal visual flow for users who speak left-to-right languages. (See the chapter introduction for a discussion of visual flow.) The rest of the page should support this visual flow, too. The eye finally comes to rest on elements representing what the user might do last, like close this UI or go somewhere else.

how

Place the title, tabs, or some other strong element at the upper left of the page; place the button(s) at the lower right. Content of any width goes in between. If the content itself contributes to the balance of the page, so much the better—don't put too much whitespace on only one side, for instance.

Consider what the color dialog box above would look like if you pushed the OK and Cancel buttons to the left edge instead of the right edge. The whole dialog would feel left-weighted and precarious.

In Windows, the placement of the title in the upper left and the conventional placement of buttons in the lower right do this for you automatically. In Mac OS X, many elements, such as title bars, tabs, and action buttons, are centered—so Diagonal Balance is much less common there.

Kevin Mullet's and Darrell Sano's classic pre-Web book Designing Visual Interfaces (Sun Microsystems) describes the idea of diagonal balance: "Symmetrical layouts provide…visual equilibrium automatically. Asymmetrical layouts can achieve equilibrium as well, but their tenser, more dramatic form of balance depends on careful manipulation to compensate visually for differences in the size, position, and value of major elements." See below for examples of how you can achieve this balance.

examples

Figure 4-36. A diagonal balance can work with text-only interfaces, too. In this blog entry, the eye goes first to the upper left, reads the content, and then comes to rest on the links at the bottom right. These links are the "next things" the user might want to do with this posting. (The blog is at http://eleganthack.com.)

Figure 4-37. Likewise with heavily graphic UIs. The focal points in the site shown here are the logo, the moving car, the "Let's Motor" tag line, and the dealer-locator text field at bottom right—all in a diagonal line (approximately). The motion of the photograph pushes the eye down and right even more forcefully than the other examples. Undoubtedly, the designers of the site wanted to encourage people to use the text field. If it were at the bottom left instead, the page would lose much of its punch, and the text field might get lost in the page. See http://miniusa.com.

property sheet

Figure 4-38. Visual Studio property sheet

what

Use a two-column or form-style layout to show the user that an object's properties are edited on this page.

use when

The interface presents an editable object to the user—perhaps something built in a graphical editor, a database record or query, or some domain-specific item (like a car or a stock purchase). The user needs to change the properties or attributes of the object.

why

Most users of visual builders are familiar with the concept of a property sheet—a list of object properties or settings, set forth in a prescribed order, editable via controls appropriate for the property types (such as text fields for strings or dropdowns for one-of-many choices). Well-designed property sheets are generally easy to use, simply because they follow well-understood conventions.

Property sheets can also help the user build a correct mental model of the objects in the UI. A property sheet tells the user what the object's properties are, and what values are available for each of them, especially in applications that mix WYSIWYG editing with programming (such as GUI builders, web page builders, and time-based scripting and animation tools). Property editors thus help the user learn how to use the system.

Alternatives to property sheets might include menus and direct manipulation. A menu can provide access to a small handful of simple boolean or one-of-many properties. If users only need to edit a few properties for an object, then a property sheet may be too heavyweight a solution. A user would need to bring it up, look at it for a fraction of a second, figure out which property to edit, edit it, and maybe close the property sheet again. That's a lot of work, but the advantage is that it scales up well. If the user changes a lot of properties in succession, then that property sheet can stay up and available. They also permit access to vast numbers of properties at once, unlike menus, which stop being usable when they get longer than about eight properties.

Direct manipulation is a different animal entirely. For instance, you can drag, resize, rotate, or layer graphic objects on a canvas with no help from auxiliary windows at all—that covers a lot of properties. Anything that fits into a nice visual metaphor can escape the need for a property sheet. But if it doesn't, property sheets become necessary. (They may also be necessary if some users want the precision of typed numbers for movement, rotation, and similar properties.)

how

The only commonality here is that the various edit controls are labeled with the names of the properties they edit. When the user finishes filling in values, the new property values are written out to the object.

These issues usually come up when designing property sheets:

Layout

Some systems use a two-column table, with controls that appear when the user clicks the values shown in the righthand column. (Visual Basic seems to be the de facto standard for this approach.) Others look more like forms or dialog boxes than tables—they might have text fields sitting next to other controls or editors that are several lines tall. Use your judgment. Tables might be more recognizable as property sheets, but forms can be far more flexible in their presentation of the property-editing controls—see the Illustrator example in Figure 4-39 for an extreme example. With a form-style layout, for instance, you're not constrained to using a single table row for each control. (For many layout variations, consider using Right/Left Alignment .)

Property order

Alphabetical, categorized, or an easy-to-read order that places the most commonly edited properties at the top? They all have advantages. Short property sheets (say, 10 or fewer properties) usually are best with the most common properties listed first. The longer the list gets, the more important it is to categorize them; but if a user looks for one particular property by name, they may want to sort them alphabetically. As always, it's best to give users a choice. However, you're still responsible for picking the right default order, so "let the user choose" still doesn't get you off the hook!

Labels

Visual Studio and other programming environments often use short, cryptic names for the edited properties. That may be acceptable when the properties represent names that users might use later in programs or scripts (though more descriptive names are always better), but when that's not the case, devise better labels! Use terminology familiar to average users, not argon. Use multiple words to describe complex things. Tie the whole property sheet into help system, such as one that shows description of property whenever the user starts editing that property.

Control choice

I could write 50 pages about this. The short version: make sure the property's current value is always visible; choose controls to constrain the input as much as possible—for example, by using non-editable drop-down lists for one-of-many choices; use platform-supplied standard editors for specialized types like colors, fonts, and filenames. See Chapter 7 for more information about control choice.

When to commit the new property values

Many UIs simply update the object with the new value as soon as the user finishes typing or selecting a value. The more form-like property sheets may wait until the user deliberately commits the whole thing, such as by clicking on an "OK" button. However, if your software can deal well with instant update, go for it—it gives the user more immediate feedback about the change he just made. If you can, provide an undo mechanism. That will help users back out of accidental or unwanted changes, which is especially important with instant update.

"Mixed" values for multiply-selected objects

Some UIs solve this problem by showing no value at all, which can be dangerously mis-leading if the property actually can have no value (or null, or the empty string). Others show it with a sentinel value, like an asterisk (*), or the word "mixed."

examples

Figure 4-39. Illustrator and Photoshop take the "form-style" layout approach to its logical extreme. This figure shows the property sheet for Illustrator (twice, actually). It is broken up into several Movable Panels that float separately on top of the work windows; each panel contains one or more tab pages that group the properties by category. You can hide, rearrange, or drag the tabs from panel to panel. For power users, this dense, flexible, user-configurable approach works well; but it's not something you would use in a casual application, nor with users who aren't already comfortable with software tools this complex. The first column is a snapshot of the property sheets when a single lightblue rectangle was selected in the work window. In the second column, multiple diverse objects were selected—this shows a few ways of dealing with "mixed" values. Compare them side-by-side. Notice that no attempt is made to show Stroke and Fill in the second column, since those properties aren't even available on all the selected objects! Color does apply to all of them, however, and gets rendered with question marks and blank text fields—indicating that the source objects have different fill and edge colors. Blank combo boxes also indicate mixed values for transparency, opacity, and text leading (vertical space between letters).

Figure 4-40. This screenshot from the Xerox Star shows a very early property sheet. Some things haven't changed a whole lot: note the two-column layout, the right/left alignment, the use of controls like text fields and radio buttons, and even Responsive Disclosure (though you can't see it here).

responsive disclosure

what

Starting with a very minimal UI, guide a user through a series of steps by showing more of the UI as he completes each step.

use when

The user should be walked through a complex task step-by-step, perhaps because he is computer-naive or because the task is novel or rarely done (as in a Wizard ). But you don't want to force the user to go page-by-page at each step—you'd rather keep the whole interface on one single page.

why

In this pattern, the interface actually appears to be "created" in front of the user, one step at a time. At first, the user sees only elements that are necessary for the first step. When the user takes that step, the next set of elements is displayed in addition to the first ones, then the next, etc.

As the user sees the task unfolding directly in front of him via a dynamically growing UI, he can form a correct mental model of the task more quickly and easily. None of the awkward context switches that separate wizard screens impose exist here: the users aren't yanked out of their workflow into a rigid set of modal screens shown one at a time.

Furthermore, since the UI is kept together on one page, the user can easily go back and change his mind about earlier choices. As each step is redone, he immediately sees the effect on subsequent steps. This is better than jumping from one content-starved wizard screen to another.

For occasional tasks, this device can work better than presenting a complex and interlinked set of controls all at once, because it's always obvious what the first step is—and the next. The user never has to think too hard.

How should you choose between this pattern and Responsive Enabling ? If you use Responsive Enabling , you will put all the controls for all choices on the UI—you'll just disable the irrelevant ones until they become relevant (again, in response to the user's choices). Sometimes that can make the UI too cluttered or complicated-looking. It's a judgment call: if you need to fit the UI into a very small space, or if you think too many controls on the UI might look bad or make users nervous, use Responsive Disclosure instead.

how

Start by showing the controls and text for only the first step. When the user completes that step, show the controls for the next step. Leave the previous steps' controls visible, to let the user go backward if necessary. Keep it all on one page or dialog box, so the user isn't abruptly pushed into a separate "UI space."

In many such step-by-step designs, the choices the user makes at one step alters the rest of the task (i.e., the task is branched, not linear). For instance, an online order form asks whether the billing address is the same as the shipping address. If the user says yes, the UI doesn't even bother showing entry fields for it. Otherwise, there's one more step in the process, and the UI shows the second set of entry fields when appropriate.

This technique is less successful when used to radically change a preexisting UI, instead of adding UI controls to a blank space. Restructuring a UI from under a user can turn his sense of space upside down—it's very disruptive! But when done in an orderly and predictable manner, it provides a compact, space-sensitive way to present a wizard to a user.

The concept of responsive disclosure isn't new. It was used in 1981 in the first commercial WIMP interface, the Xerox Star. Its designers considered "progressive disclosure," a more general concept that includes responsive disclosure, to be a major design principle: "Progressive disclosure dictates that detail be hidden from users until they ask or need to see it. Thus, Star not only provides default settings, it hides settings that users are unlikely to indicate that they want to change them. "^[2] indeed.

In the Star's Property Sheets , for instance, blank space was reserved for controls that would appear as needed, in response to user choices. When a user chose from a set of values including the word "Other," for instance, an extra text field would appear for the user to enter a number.

"Instructive Interaction: Making Innovative Interfaces Self-Teaching,"^[3] by Larry Constantine and Lucy Lockwood, discusses this pattern under the name "Progressive Disclosure."

examples

Figure 4-42. This example comes from an internal application at Northwestern Mutual. The user first selects "TSO" for Request Type; the application then shows a new box, asking for TSO Information. When the user then selects "Delete ID," a third box appears. The history of this user's choices remains visible on the page.

Figure 4-43. Now here's an example of doing exactly what I said wasn't a great idea: changing a preexisting interface, rather than adding things to it. However, this example seems small-scale enough to work. It's from Mapblast's UI for entering the spot to be located on a map. It shows two configurations: first for a specific address, and second for a place name without an address. Each is chosen with a radio button. This design might have benefited from first showing no radio button selected, and no address or place name controls at all; when the user then clicks on a radio button, the appropriate controls are shown.

responsive enabling

Figure 4-44. MATLAB Curve-Fitting Tool

what

Starting with a UI that's mostly disabled, guide a user through a series of steps by enabling more of the UI as each step is done.

use when

The UI walks the through complex step-by-step, perhaps because he is computer-naive, or because the task is rarely done (as in a Wizard ). But you don't want to force the user to go page by page at each step—you'd like to keep the whole interface page. Furthermore, you want to keep the interface stable; you'd rather not dynamically reconfigure the page at each step, as you would with Responsive Disclosure .

why

Like Responsive Disclosure , this pattern takes advantage of the malleability of computer displays to guide the user through the interface interactively. The user thus gets a chance to form a correct mental model about cause and effect. The UI itself tells him the possible consequences of some choices: if I turn this checkbox on, then I have to fill in these four text fields that just got enabled.

Furthermore, the user can't do things that would get him into trouble, as the UI has "locked out" those actions by disabling them. Unnecessary error messages are thus avoided.

how

In some applications, such as the GUI in Figure 4-44, most actions on the UI start off disabled—only the actions relevant to the user's first step are available. As the user makes choices and performs actions, more disabled items should be enabled and brought into play. In this respect it's remarkably like Responsive Disclosure , since the machine specifies a particular sequence through the interface.

A similar, less sequence-based technique is much more common in desktop UIs. As the user does things on the interface, certain actions or settings become irrelevant or impossible, and those actions get disabled until the user does whatever is necessary to re-enable them. Overall sequence isn't as important. See Figure 4-45 for an example.

Whenever possible, put the disabled items in close proximity to whatever enables them. That helps users find the magic enabling operation and understand the relationship between it and the disabled items. Two of this pattern's examples place that button (or checkbox, respectively) at the top and left of the disabled items, which follows the natural top-to-bottom and left-to-right "flow" of the interface.

When you design an interface that uses Responsive Enabling or Responsive Disclosure , be sure to disable only things that really can't or shouldn't be used. Be wary of overconstraining the user's experience attempt to make interface friendlier or easier to understand. When you decide what to disable, carefully consider each device: is it disabled for a really good reason? Can you offer that functionality all the time? As usual, usability testing gives users a chance to tell you that you've done it wrong.

Another usability problem to avoid is what Bruce Tognazzini calls the "Mysteriously Dimmed Menu Items"^[4]—when the design offers no clue as to why a given device is disabled. Again, minimize the set of things that have to be disabled, especially when they're far away from whatever operation turns them on. Also, somewhere on the interface or in its help system, tell the user what causes a feature to be unavailable. Again, this whole problem can be avoided more easily when the disabled controls aren't menus on a menu bar, but instead sit out on the main UI, colocated with whatever switches them on. Spatial proximity is an important clue.

examples

Figure 4-45. The Mac OS X System Preferences provide a typical example of disabling based on a binary choice: should OS X show the date and time on the menu bar, or not? If the user chooses to show it, then she gets a panoply of choices about how it ought to be shown. If not, the choices are irrelevant, so they're disabled. This behavior (plus the indenting of the options under the checkbox) tells the user that these choices affect the date/time display which the checkbox toggled—and nothing else.

Figure 4-46. You also can reverse the sense of this pattern and do "responsive disabling." The navigation system used in Toyota's Prius and Lexus cars employs this technique when a user enters a destination address. Knowing what streets exist in a given search area, the system narrows down the possible street names with each successive letter entered by the user. It then disables the letters that can't possibly follow the currently typed string; the user has fewer buttons to think about, plus some assurance that the system "knows" what they're trying to type. Address entry is thus made easier and more pleasant. (When only a few remaining streets match, the system takes away the keyboard altogether and shows the streets as a list of choices—see the Autocompletion pattern in Chapter 5.) See http://lexus.com/models/rx_hybrid/interior.html—the source of these screenshots—for a demo.

liquid layout

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 screen, the importance 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 also may 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, 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 enter anything longer than the text field's normal length. Likewise, anything scrolled (such as lists and tables) 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 always should 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, whitespace 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.^[5])

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

Figure 4-48. 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 in this dialog box, too.)

Get Designing Interfaces now with O'Reilly online learning.

O'Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.

designing layout of nature video

Source: https://www.oreilly.com/library/view/designing-interfaces/0596008031/ch04.html

Posted by: monsourguideare.blogspot.com

Share this post