4.2. 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. 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
32. visual framework Figure 4-9. From http://zipcar.com 
4.2.1.1. 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. 4.2.1.2. use when You've built a web site with multiple pages, or a UI with multiple windowsin 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. 4.2.1.3. why When a UI uses consistent color, font, and layout, and when titles and navigational aidssignpostsare 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 productthe pages become recognizable as yours. 4.2.1.4. 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 placesuch as a CSS stylesheet or a Java classit 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.) 4.2.1.5. 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 boxPage Setupand 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 consistentthe logo, the page title and subtitle ("Image Search" and "Groups"), and the other linksand the all-important search field always is in the same place! 
33. center stage Figure 4-12. Flax MX 
4.2.2.1. 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. 4.2.2.2. 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 Stagetables and spread-sheets, forms, web pages, and graphical editors all qualify. 4.2.2.3. 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. [1] The name of this pattern was first coined in 1998, by P.R. Warren and M. Viljoen, in their paper "Design patterns for user interfaces."
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 outwhat comes first? What's second? How does this relate to that? And so on. 4.2.2.4. 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 itthis 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 stagetop, 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 marginse.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. 4.2.2.5. 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 screenthe 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. 
34. titled sections Figure 4-16. http://adobe.com 
4.2.3.1. what Define separate sections of content by giving each one a visually strong title, and then laying them all out on the page together. 4.2.3.2. 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. 4.2.3.3. 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! 4.2.3.4. how First, get the information architecture rightsplit 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 contentbold, 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 lostand just become visual noiseif 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. 4.2.3.5. 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. 
35. card stack Figure 4-19. Internet Explorer properties dialog box 
4.2.4.1. 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. 4.2.4.2. 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. Finallyand this is importantusers don't need to see more than one section at one time. 4.2.4.3. 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. 4.2.4.4. 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. 4.2.4.5. 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. 
36. closable panels Figure 4-24. Dreamweaver MX 
4.2.5.1. what Put sections of content onto separate panels, and let the user open and close each of them separately from the others. 4.2.5.2. 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. 4.2.5.3. why You would Closable Panels in many places where you might use a Card Stackit'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 applicationsat 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 commonthey 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. 4.2.5.4. 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 linkdoing 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 panelseven with the twist-down arrowsfor its widget palettes. 4.2.5.5. 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 interfaceif 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 columnthe 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 outstrong 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?) 
37. movable panels Figure 4-29. MATLAB 
4.2.6.1. what Put different tools or sections of content onto separate panels, and let the user move them around to form a custom layout. 4.2.6.2. 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. 4.2.6.3. 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 runonce 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. 4.2.6.4. 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 droppedthis 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 movesa user who unintentionally drags a panel into an odd place may not know immediately what he did or how to undo it. 4.2.6.5. 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. 
38. right/left alignment Figure 4-32. Part of a dialog box from Macromedia Contribute 
4.2.7.1. what When designing a two-column form or table, right-align the labels on the left, and left-align the items on the right. 4.2.7.2. 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. 4.2.7.3. why When you put text right next to the thing it labels, you form a strong perceptual grouping of that pairmuch 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 sectionsall of these formats can ruin a right/left alignment (though not necessarily). Go with what works. 4.2.7.4. 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 edgethat'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-perfectif 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. 4.2.7.5. 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. 
39. diagonal balance Figure 4-35. Word's Graph Options dialog box 
4.2.8.1. what Arrange page elements in an asymmetric fashion, but balance it by putting visual weight into both the upper-left and lower-right corners. 4.2.8.2. use when You lay out a page or dialog box that has a title or header at the top, and some links or action buttonssuch as OK and Cancel, Submit, or Back and Nextat the bottom. The page is short enough to fit on the screen without scrolling. 4.2.8.3. 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 weightsthe 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 rightan 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. 4.2.8.4. 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 betterdon'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 centeredso 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. 4.2.8.5. 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 rightall 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. 
40. property sheet Figure 4-38. Visual Studio property sheet 
4.2.9.1. what Use a two-column or form-style layout to show the user that an object's properties are edited on this page. 4.2.9.2. use when The interface presents an editable object to the userperhaps 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. 4.2.9.3. why Most users of visual builders are familiar with the concept of a property sheeta 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 allthat 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.) 4.2.9.4. 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 tablesthey 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 controlssee 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 possiblefor 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 itit 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." 4.2.9.5. 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 selectedthis 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 fieldsindicating 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). 
41. responsive disclosure Figure 4-41. From http://turbotax.com 
4.2.10.1. 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. 4.2.10.2. 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 stepyou'd rather keep the whole interface on one single page. 4.2.10.3. 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 isand 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 UIyou'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. 4.2.10.4. 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 downit'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. [2] Johnson, J.A., et. al. "The Xerox Star: A Retrospective," IEEE Computer, September 1989, 22(9), pp. 1129. See also http://www.digibarn.com/friends/curbow/star/retrospect/.
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." [3] See http://foruse.com/articles/instructive.htm.
4.2.10.5. 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. 
42. responsive enabling Figure 4-44. MATLAB Curve-Fitting Tool 
4.2.11.1. 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. 4.2.11.2. 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 stepyou'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. 4.2.11.3. 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. 4.2.11.4. how In some applications, such as the GUI in Figure 4-44, most actions on the UI start off disabledonly 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. [4] See "Ten Most Wanted Design Bugs," at http://www.asktog.com/Bughouse/10MostWantedDesignBugs.html.
4.2.11.5. 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 toggledand 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 choicessee the Autocompletion pattern in Chapter 5.)
See http://lexus.com/models/rx_hybrid/interior.htmlthe source of these screenshotsfor a demo. 
43. liquid layout Figure 4-47. From http://wired.com 
4.2.12.1. what As the user resizes the window, resize the page contents along with it so the page is constantly "filled." 4.2.12.2. use when The user might want more spaceor lessin 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. 4.2.12.3. 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 usernone 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. 4.2.12.4. 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 elongateusers 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-widthsthat 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]) [5] See "Use Reading Performance or User Preference," at http://usability.gov/guidelines/.
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. 4.2.12.5. 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.) 
|
