Put two side-by-side panels on the interface. In the first one, show a list of items that the user can select at will; in the second one, show the content of the selected item.

You have a list of items to show. Each item has interesting content associated with it, such as the text of an email message, a long article, a full-sized image, contained items (if the list is a set of categories or folders), or details about a file’s size or date.

You want the user to see the overall structure of the list and keep that list in view all the time, but you also want him to be able to browse through the items easily and quickly. People won’t need to see the details or content of more than one item at a time.

Physically, the display you’re working with is large enough to show two separate panels at once. Very small cell phone displays cannot cope with this pattern, but many larger mobile devices can.

This is a learned convention, but it’s an extremely common and powerful one. People quickly learn that they’re supposed to select an item in one panel to see its contents in the other. They might learn it from their email clients, or from Windows Explorer, or from websites; whatever the case, they apply the concept to other applications that look similar.

When both panels are visible side by side, users can quickly shift their attention back and forth, looking now at the overall structure of the list (“How many more unread email messages do I have?”), and now at an object’s details (“What does this email say?”). This tight integration has several advantages over other physical structures, such as two separate windows or One-Window Drilldown:

Place the selectable list on the top or left panel, and the details panel below it or to its right. This takes advantage of the visual flow that most users who read left-to-right languages will expect (so try reversing it for right-to-left language readers).

When the user selects an item, immediately show its contents or details in the second panel. Selection should be done with a single click. But while you’re at it, give the user a way to change his selection from the keyboard, particularly with the arrow keys—this helps reduce both the physical effort and the time required for browsing, and contributes to keyboard-only usability (see Keyboard Only in Chapter 1).

Make the selected item visually obvious. Most GUI toolkits have a particular way of showing selection (e.g., reversing the foreground and background of the selected list item). If that doesn’t look good, or if you’re not using a GUI toolkit with this feature, try to make the selected item a different color and brightness than the unselected ones—that helps it stand out.

What should the selectable list look like? It depends—on the inherent structure of the content, or perhaps on the task to be performed. For instance, most filesystem viewers show the directory hierarchy, since that’s how filesystems are structured. Animation and video editing software use interactive timelines. A GUI builder may simply use the layout canvas itself; selected objects on it then show their properties in a property editor next to the canvas.

A Two-Panel Selector has identical semantics to tabs: one area for the selectors, and one area next to it for the content of the selected thing. Likewise, a List Inlay is like an Accordion (Chapter 4), and One-Window Drilldown is like a Menu Page (Chapter 3).

When the select-and-show concept is extended through multiple panels to facilitate navigation through a hierarchical information architecture, you get the Cascading Lists pattern.

Many email clients use this pattern to show a list of email messages next to the currently selected message (see Figure 5-2). Such listings benefit from being nearly as wide as the whole window, so it makes sense to put the listing on top of the second panel, not to its left. (Also, this example shows the use of a third selector panel on the left that lets the user choose which mailbox to work in.)

Figure 5-2. Mac Mail on a desktop

Like many other Picture Manager, Picasa (Figure 5-3) lists the various image folders and categories in its Two-Panel Selector. The result is a second list, of images. When the user selects an image, the whole window is replaced; see One-Window Drilldown.

Figure 5-3. Picasa

http://quince.infragistics.com/Patterns/Two-Panel%20Selector.aspx

http://www.welie.com/patterns/showPattern.php?patternID=overview-detail

Show a list or menu of items in a single window. When the user selects an item from the list, show the details or contents of that item in the window, replacing the list.

You have a list of items to show. Each item has interesting content associated with it, such as the text of an email message, a long article, a full-size image, or details about a file’s size or date.

You have very little space to work with—not enough for a Two-Panel Selector or a List Inlay. For instance, the design might be intended for a very small mobile screen, or for a self-contained web page sidebar or widget.

Alternatively, the list items and contents might just be large. You might need the entire screen or window to show the list, and again to show the contents of an item. Online forums tend to work this way, requiring the whole width of the page to list conversation topics and a separate scrolled page to show the conversations themselves.

In a very constrained space, this may be the only reasonable option for presenting a list and item details. It gives each view the entire available space to “spread out” on the page.

Like Menu Page in Chapter 3, however, this pattern has the benefit of simplicity. A list of items (or links) is easy to understand: to see more of an item, you click or tap on it and thus “drill down” one level. Then you can come back up to the main list or menu to go to another item.

Create the list using whatever layout or format you find best—simple text names, multiline “fat rows” with text formatting, trees or outlines, and Thumbnail Grid all work fine, as do other formats. Vertically scroll it if necessary to fit it into the available space.

When the user clicks, taps, or otherwise selects one of the list items, replace the list display with a display of the item details or contents. On it, place a Back or Cancel button that brings the user back to the list screen (unless the platform supplies hardware buttons for such).

The item screen may offer additional navigational possibilities, such as drilling down further into the item details, stepping down into an item contained within that item (as in a hierarchy), or going “sideways” to the previous or next item in the list (as discussed in the next paragraph). In each case, replace the previous screen with the new one, and make sure the user can easily step back to the previous screen.

One disadvantage of this pattern is that to go from item to item, the user must “pogo-stick” between the list page and the item page. It takes a lot of clicks or taps to see more than a few items, and the user certainly can’t flick between them quickly (as with Two-Panel Selector) or compare them easily (as with List Inlay). You can mitigate this problem by using Back and Next links to connect the user directly to the previous and next items in the list—see the Pyramid pattern in Chapter 3.

Examples abound in mobile designs, as shown in Figure 5-4. Contrast this mobile version of a mail client with its desktop counterpart shown in the Two-Panel Selector pattern. For instance, the One-Window Drilldown approach requires more text to be shown in the list, so the user has enough context to identify messages and triage them.

You can find One-Window Drilldown in full-size applications and web pages, too. Forums and communities tend to use it a lot—topics are listed on one page, and discussion threads are on their own pages. Ravelry demonstrates this approach, as do about six million other online forums (see Figure 5-5).

Figure 5-5. Ravelry forums

The Picasa desktop application, a Picture Manager uses a Two-Panel Selector beside a Thumbnail Grid for its browsing interface (see Figure 5-6). But once the user clicks a photo, Picasa replaces the entire contents of the window (except the bottom toolbar) with a new layout—one that shows the photo itself in Center Stage, with a set of tools next to it.

Figure 5-6. Picasa

http://quince.infragistics.com/Patterns/One-Window%20Drilldown.aspx

Show a list of items as rows in a column. When the user selects an item, open that item’s details in place, within the list itself. Allow items to be opened and closed independently of each other.

You have a list of items to show. Each item has interesting content associated with it, such as the text of an email message, a long article, a full-size image, or details about a file’s size or date. The item details don’t take up a large amount of space, but they’re not so small that you can fit them all in the list itself.

You want the user to see the overall structure of the list and keep that list in view all the time, but you also want her to browse through the items easily and quickly. Users may want to see two or more item contents at a time, for comparison.

The list of items has a vertically oriented, columnar structure.

A List Inlay shows an item’s details within the context of the list itself. The user can see the surrounding items, which might help in understanding and using the item contents.

Also, a user can see the details of multiple items at once. This is not possible in Two-Panel Selector, One-Window Drilldown, rollover windows, or most other ways of displaying item details. If your use cases call for frequent comparison of two or more items, this might be the best option.

Because a List Inlay is neatly contained within a vertical column, it can be combined well with a Two-Panel Selector to present a three-level containment hierarchy. Consider an email client or RSS reader, for instance—the messages or articles might be viewed in a List Inlay, while the item containers (mailboxes, groupings, filters, etc.) are shown next to it in a Two-Panel Selector structure.

Show list items in a column. When the user clicks on one, open the item in place to show the details of that item. A similar gesture should close the item back up again.

When an item is opened, enlarge the item’s space downward, pushing the subsequent items down the page. Other items do the same when opened. A scrolled area should be used to contain this ever-changing vertical structure, since it could get very tall indeed!

To close the details panel, use a control that clearly indicates its purpose (e.g., “Close” or “X”). Some implementations of List Inlay only put that control at the end of the details panel, but users may need it at the top if the panel is long and they don’t want to move down the whole thing. Put a closing control very near the original “open” control (or replace one with the other). This at least ensures that the user’s pointer won’t move very far if she wants to open an item, glance at it, close it, and move on.

Use an Animated Transition as the item opens and closes, to keep the user oriented and to focus attention on the newly opened item.

If your application permits the user to edit items, you could use a List Inlay to open an editor instead of item details (or in addition to them).

A list that uses List Inlay works the same way as an Accordion: everything lies in a single column, with panels opening and closing in situ within it. Likewise, a Two-Panel Selector works like a set of tabs, and One-Window Drilldown is like a Menu Page (Chapter 3).

Google Reader (Figure 5-8) uses a List Inlay within the context of a Two-Panel Selector. It has a multi-level hierarchy of containers to present; the containers are shown in the tree selector on the left, but the list of articles takes up Center Stage and the user can then open them in place to read them.

Figure 5-8. Google Reader

Rather than forcing the user to pogo-stick back and forth from the list of book reviews to the actual text of each review, Amazon’s mobile site lets users read them in a List Inlay. The list of items on the left tempts the user with short teasers from each review, and when a user is interested enough to keep reading, she can tap the title to read the whole thing (Figure 5-9). The existence of plus and minus controls signals to the user that these items expand.

Figure 5-9. Amazon reviews on the iPhone

http://www.patternry.com/p=inline-expand/

Bill Scott and Theresa Neil identified this technique in their book, Designing Web Interfaces (O’Reilly, http://oreilly.com/catalog/9780596516253/). List Inlay are one of a set of inlay techniques that includes Dialog Inlays and Detail Inlays.

The Accordion pattern exists in many pattern libraries, including this one. Much of the design advice proffered for Accordion can apply equally well to List Inlay. (There really isn’t a huge practical difference between them.)

Arrange a list of visually interesting items into a “small multiples” grid of thumbnail images. Let the user select one or more thumbnails to view or manage those items.

The list items have small visual representations that uniquely identify them: images, logos, screen captures, reduced photos, and so forth. These tend to be similar in size and style. The list may be long, and it may be divided into Titled Sections (Chapter 4).

You want to show a little bit of metadata (information about the item) with each one, such as its name and date, but you don’t need to show a lot of that—the picture should take up most of the space devoted to the item.

Users will want an overview of the whole list, and they may need to scan it quickly to find a particular item of interest. Users may also need to select one or more items at a time for moving, deleting, or viewing.

A Thumbnail Grid is a dense, attractive presentation of large numbers of items. Related to Grid of Equals (Chapter 4), this pattern creates a visual hierarchy that shows the list items as peers, and a strong grid tends to draw the eye to that part of the page.

It might be easier to show the list items in text form, but sometimes pictures can be recognized and differentiated more easily than text.

Thumbnails that are roughly square make easy targets for fingertips (on touch screens) and for indirect pointing devices as well. This pattern works well on mobile devices with relatively high-resolution touch screens, such as iPhones.

Arrange the item thumbnails into a 2D grid. Scale the thumbnails so that they’re approximately the same size, to keep the grid tidy. Place the text metadata close to the thumbnail, but in small print in order to maintain the thumbnail’s visual prominence.

Some Thumbnail Grid look much nicer when the thumbnails all have similar width and height. If you’re working with graphics that come in different sizes or aspect ratios (the ratio of width to height), or if they’re large, some image processing will need to be done to construct thumbnails. Try to find a size and aspect ratio that works reasonably well with all of them, even if some images will be cropped to fit it. (Reducing image size is easy; cropping appropriately is not. Be careful to preserve the image’s integrity by choosing the most relevant piece of the image to show, when possible.)

An exception is if you’re dealing with images whose size and proportion are useful information to the viewer. For instance, a set of personal photos will contain some that are in a landscape format and some in a portrait (vertical) format. There’s no need to crop these to match an idealized thumbnail—the user will want to see which photos are which!

On the other hand, a thumbnail gallery of products (such as shoes or shirts) should all have the same height and width, with the products presented consistently within those photos.

Mac OS Finder displays a variety of thumbnail types for a file directory listing (see Figure 5-11). When a file is an image, a shrunken version of that image is shown; for directories, a simple folder; for files without an available visual, just the file type (e.g., “DOC”) over a generic icon. The thumbnail grid is not at all uniform, so it doesn’t look as clean as the others in this pattern, but the size and style variations communicate useful information to the user.

Figure 5-11. Mac OS Finder

AIGA’s design archives (Figure 5-12) and YouTube (Figure 5-13) are two Picture Manager that show no text information and lots of text information, respectively.

Figure 5-12. AIGA design archives

Figure 5-13. YouTube

Zappos (Figure 5-14) and Hanna Andersson (Figure 5-10, at the top of the pattern) demonstrate nicely designed Thumbnail Grid for product galleries. Uniformity is beautiful here—the similarities and differences between products show up with stunning clarity, and a strong visual rhythm exists on the page.

Figure 5-14. Zappos

Mobile devices need Thumbnail Grid in many contexts: to show applications, features, and images themselves. Note the relative sizes of the thumbnails in Figure 5-15; the Google Images and iPhone home screen examples are just big enough to be touched easily by human fingertips. The Facebook example is more relaxed, with more space around each item.

Figure 5-15. Thumbnail Grids on the iPhone: Facebook, Google Images, and the home screen

http://ui-patterns.com/patterns/Thumbnail

Arrange a list of visually interesting items into a horizontal strip or arc, and let the user scroll or swipe the image thumbnails back and forth to view them. Enlarge the center item, if appropriate.

The list items have visual representations that uniquely identify them: images, logos, screen captures, reduced photos, and so forth. These tend to be similar in size and style. The list is flat (i.e., not divided into categories or containers).

You want to show a little bit of metadata (information about the item) with each one, such as its name and date, but you don’t need to show a lot of that—the picture should take up most of the space devoted to the item.

Each item is potentially of interest. Users will browse the items casually; they won’t normally search for a specific item, or need to get an overall look at the entire list at once. If someone does look for a specific item, he won’t mind moving past many items before finding the one he’s looking for. You may be able to order the items with the most interesting ones first, or in chronological order.

You don’t have enough vertical space for a Thumbnail Grid, and you may not have a lot of horizontal space either, but you need to make this list look interesting and attractive.

A Carousel offers an engaging interface for browsing visual items, encouraging the user to inspect the items that are in view and to see what’s next. A user can’t easily jump to a certain point deep in the list, so he has to scroll through everything—this pattern thus encourages browsing and serendipity.

Carousel are compact vertically, so they may be a better solution than a Thumbnail Grid for a small space. Horizontally, they can be either compact or spread out.

If a particular implementation focuses attention on a central item or selection, such as by enlarging it, this pattern delivers “focus plus context”—users get a detailed view of one item, while also seeing the ones immediately around it. See Chapter 7 for more discussion of this principle.

First, create thumbnails for each item shown in the Carousel. See the Thumbnail Grid pattern for issues related to thumbnail size and proportion (keeping in mind that Carousel impose even stricter restraints—thumbnails of different size or aspect ratio tend to look more awkward in Carousel than in Thumbnail Grid). Place the text metadata close to the thumbnail, but in small print in order to maintain the thumbnail’s visual prominence.

In a horizontal scrolling widget, arrange the thumbnails horizontally, either randomly or in an order that makes obvious sense to the user (such as by date). Show a small number of them—fewer than 10—and hide the rest on either side. Put large arrows on the left and right for paging through the Carousel; each click on an arrow should move more than one item. Animate this scrolling for extra visual interest.

If users will want to move quickly through a long list, as though they are looking for something in particular, put a scrollbar below the Carousel in addition to the arrows. You may find that users do this a lot; if so, consider restructuring the list as a more conventional vertical list, and add a “find” capability.

You may choose to enlarge the central item in the Carousel to draw attention to it. This gives the Carousel single-selection semantics—the enlarged item is clearly the selected one, and you can then do dynamic things based on that selection, such as showing text details about it, or offering video controls if the items are video thumbnails.

Some Carousel are straight; some are curved or circular. These usually use the trick of a 3D perspective, in which items shrink and are partially obscured as they drift farther away from the center.

In the mobile design space, the Filmstrip pattern (Chapter 10) is a variant on a Carousel. Only one item at a time is shown on the small screen, and the user swipes or scrolls back and forth to see other items.

Many websites use a basic, linear Carousel for browsing products. Amazon and Google Books show book covers this way (see Figure 5-17); note the different amounts of text metadata and the implications for design. How much information should be provided with each book? How tightly packed should the book covers be?

Figure 5-17. Amazon and Google Books

Apple and Flickr (Figures Figure 5-18 and Figure 5-19) provide horizontal scrollbars along with their Carousel. These may contain a lot of items, so a scrollbar is needed for fast progress through them. Note that Apple’s Carousel uses an Annotated Scrollbar (Chapter 3) to help users find product categories. The horizontal aspect of this list makes for a graceful presentation of the product names, but it wouldn’t scale much beyond a small handful of categories—it’s quite unusual to present a categorized list in a Carousel. Flat lists usually work better.

Figure 5-18. Apple product carousel

Figure 5-19. Flickr organizational tools

Figure 5-20 (Figure 5-20) is essentially a media Carousel that enlarges the central, selected item. Compare it to a curved Carousel in an Android app (Figure 5-21); these are similar in behavior, but very different in visual styling.

Figure 5-20. Cover Flow in iTunes

Figure 5-21. Sherpa for Android (image courtesy of http://www.androidtapp.com/sherpa-discover-your-world/sherpa-nearest-dining-on-carousel/)

The New York Times presents some of its feature articles in a Carousel (see Figure 5-22). These are the kinds of articles that may tempt a user to look at each one and browse slowly; it wouldn’t work for all of the Times’ countless daily articles, since people mostly skim the headlines and cherry-pick articles of interest. Features are different, however.

Figure 5-22. New York Times feature articles

http://developer.yahoo.com/ypatterns/selection/carousel.html

http://ui-patterns.com/patterns/Carousel

http://welie.com/patterns/showPattern.php?patternID=carrousel

Use two similar shades to alternately color the backgrounds of the table rows.

Your interface presents data in a large multicolumn table, but the table’s rows are difficult to separate visually. Users will need to look up specific data items in the table.

Blocks of gentle color define and delineate the information contained inside them, even when you can’t use whitespace to separate the data into “chunks.” Cartographers and graphic designers have known this color-block technique for ages. (Remember that colored backgrounds are also effective for defining page sections and articulating a visual hierarchy. See Chapter 4 for more information.)

When someone looks at a large data table with a single background color, she will tend to see the columns as coherent objects due to proximity—the table entries in a column are closer to one another than they are to the other entries in their rows. But you want the viewer to read the table “row-wise” as well as column-wise. By coloring adjacent rows differently, you turn the rows into coherent visual objects, too. (This takes advantage of the Gestalt principles of continuity and closure; again, see Chapter 4.)

Specifically, Row Striping helps a user:

However, Row Striping introduces more visual noise into the page. Some users in some contexts may find that it slows them down or that it makes the table harder to use.

Two studies on Row Striping, also known as zebra striping, indicate that it has a small but noticeable benefit for lookup speed and accuracy—under some conditions. The tables for which lookup improved were fairly large, with many rows and several widely spaced columns; a smaller table showed no benefit one way or the other. The researchers also noted that when asked about it, users said they preferred Row Striping! See the two articles at the following URLs for discussions of these studies, and for links to the original research performed by Formulate Information Design:

Pick a pair of quiet, low-saturation colors that are similar in value but not identical. (In other words, one needs to be a wee bit darker than the other.) Good choices are light blue and white, beige and white, or two similar shades of gray—assuming the text on top of them is dark. Generally, one of the colors is your page’s background color.

Alternate the color from row to row. If the rows are thin, you could also experiment with grouping the rows—the first three are white, the next three are blue, and so on—but the research described a few paragraphs up found that users preferred single-line striping.

This pattern virtually eliminates the need for horizontal lines between the rows (though you could use them if they are very thin and inconspicuous). If your columns are aligned with one another, you don’t need vertical lines between them, nor a heavy border around the table—the viewer’s sense of visual closure will kick in, and the row colors will define the edges of the table for you. However, if row striping isn’t working well for your users, you might try very thin horizontal lines instead, since they have a similar effect of forcing the eye to see horizontal groups instead of vertical groups.

The JetBlue example at the top of the pattern (Figure 5-23) shows several lines per row. The data itself is multiline and carefully formatted; some row separation other than whitespace was needed here. Lightweight horizontal rules may have worked too, but Row Striping makes coherent shapes out of the rows.

Single-row striping is more common. iTunes uses it to good effect, as shown in Figure 5-24.

Figure 5-24. iTunes

The Excel ledger spreadsheet shown in Figure 5-25 permits the user to change gridline styles, and Row Striping is among the possibilities. This sheet makes it fairly easy to follow the lines from left to right and back again.

Figure 5-25. Excel ledger, with stripes

But look what happens when the gray row backgrounds are stripped away, as shown in Figure 5-26. The columns suddenly become much stronger visually, and each row is harder to read from left to right. Some designers, however, find this design to be cleaner and more pleasing. There’s no absolutely correct answer about whether to use Row Striping or not.

Figure 5-26. Excel ledger, without stripes

This technique is also known in many places as “alternating row colors” or “zebra striping.” Descriptions abound on the Web:

http://ui-patterns.com/patterns/AlternatingRowColors

http://www.welie.com/patterns/showPattern.php?patternID=zebra-table

http://quince.infragistics.com/Patterns/Alternating%20Row%20Colors.aspx

Break up a very long list into pages, and load them one at a time. Provide controls for the user to navigate the list—next, previous, first, and last pages.

You’re showing a list that might be very, very long. Most users will either look for a particular item or browse the top of the list for relevant items (e.g., with search results); in any case, they won’t really want to see the entire list.

The technology you’re using doesn’t support loading the entire list into a single page or scrolled area, for any of the following reasons:

Pagination breaks a list into chunks that a user can easily take in without being overwhelmed. Furthermore, it puts the choice to see more into the user’s hands—do you want to load more items from the list, or is this page of items enough for you?

This pattern also has the advantage of being very common on the Web, especially (though not exclusively) for search results. It’s easy to implement, and may come prebuilt in some systems.

First, you’ll need to decide how many items will be in each page. Base this on the amount of space each item takes up, the screen sizes users are likely to have (don’t forget to consider mobile platforms), the time it takes to load or show the items, and the likelihood that the user will find one or more desired items in the first page.

This is fairly important: the first page should be enough! The odds are good that most users won’t go beyond that first page of items, so if they can’t find what they’re looking for in that first page, they may get discouraged. (If you’re dealing with a search facility, make sure that it returns high-quality results at the top of that first page.)

On pages that users may linger over, such as lists of products or videos, consider letting the user set the number of items per page. Some people are irritated by having to page back and forth to see all the items of interest.

Next, you’ll need to decide how to present the pagination controls. They’re usually found at the bottom of the page, but some designs also have them at the top—if a user really does need to go to a subsequent page of items, there’s no need to make him scroll all the way down the page.

Consider these elements in the pagination control:

Digg and Google both do an excellent job of including all the elements and cues from the preceding list. The screenshots in Figure 5-28 show the most interesting pagination control states: first and last pages for only a small number of items, and the first, middle, and last pages for a very large number of items. Note that Digg uses ellipses to manage large numbers, and Google simply omits the beginning and end of the range. Digg knows exactly how many pages of items there are, whereas Google’s list is sometimes bottomless. (The last Google example shows the last page of a search that wasn’t bottomless—it only returned 21 pages of results.)

Figure 5-28. Digg and Google examples

Figure 5-29 shows a gallery of examples from all over the Web. Notice which ones are easier to parse visually—Which link is which? Where should I click next?—and which ones give you sufficient information about your location and the total number of pages. Also note the size of the click targets. How accurate does the user have to be with her mouse or fingertip?

Figure 5-29. Counterclockwise from top: Kayak, Drupal.org, Flickr, Target, Last.fm, Mothering.com, Amazon, eBay, YouTube, and Hulu

http://www.welie.com/patterns/showPattern.php?patternID=paging

http://ui-patterns.com/patterns/Pagination

http://www.patternry.com/p=search-pagination/

http://quince.infragistics.com/Patterns/Paging.aspx

The Yahoo! pattern library has two versions of the Pagination pattern, one for search and one for other types of items:

http://developer.yahoo.com/ypatterns/navigation/pagination/item.html

http://developer.yahoo.com/ypatterns/navigation/pagination/search.html

When the user types the name of an item into a table or tree, jump straight to that item and select it.

The interface uses a scrolling list, table, drop down, combo box, or tree to present a long list of items. These items are sorted, either alphabetically or numerically. The user wants to select one particular item quickly and accurately, and preferably with the keyboard.

This pattern is often used in file finders, long lists of names, and drop-down boxes for state or country selection. You can also use it for numbers—such as years or dollar amounts—or even calendar time, such as months or days of the week.

People aren’t good at scanning down long lists of words or numbers for a particular item. But computers are. Let them do what they’re good at!

Another nice thing about this technique is that it lets the user keep her hands on the keyboard. As she moves through a form or dialog box, she might find it nice to select from a list simply by typing the first few characters of the item she wants—the system then picks the item for her, and she can continue on to the next thing. No scrolling or clicking is necessary; the user’s hand never has to move from the keyboard to the mouse.

When the user types the first letter or number of the item she’s looking for, jump to the first item that matches what the user typed: automatically scroll the list so that the item is visible, and select it.

As the user types more characters in rapid succession, keep changing the selection to the first exact match for the whole user-typed string. If there is no match, stay put at the nearest match, and don’t scroll back to the top of the list. You may want to beep at the user to tell her that there’s no match—some applications do, some don’t.

A variant of Jump to Item is used by GNU Emacs’ incremental-search facility (see Figure 5-31). After the user enters i-search mode via Ctrl-S, each character typed brings the user to the first instance of that cumulative string in the document. It doesn’t matter that the original material wasn’t sorted.

Figure 5-31. Emacs

Once an occurrence of the string has been found, the user can find subsequent ones by pressing Ctrl-S repeatedly. In some ways, this incremental search is more convenient—and certainly faster—than typical desktop “Find” dialog boxes, which don’t update continuously as you type the search string.

Furthermore, Emacs can highlight all other instances of that string in the document in addition to scrolling to the first one. This gives the user lots of extra contextual information about the search she’s conducting. Is it a common string, or not? Are they clustered together, or scattered?

Show the letters of the alphabet arrayed along the scrollbar of an alphabetized list.

Users will be searching for very specific items in a long list, which is usually rendered as a scrolled list, table, or tree. You want to make item finding as easy and quick to achieve as possible.

Alphabet scrollers are not common, but their use is self-explanatory. They provide an interactive map to the list content, in much the same way as an Annotated Scrollbar (Chapter 3). They’re closely related to Jump to Item—both enable immediate jumping to a point in an ordered list.

This pattern probably arose from physical books (such as dictionaries) and notebooks (such as address books) that use tabs to mark points in the alphabet.

Place a long alphabetized list into a scrolled area. Along the scrollbar, show the letters of the alphabet; when the user clicks on a letter, scroll the list to that point (see Figure 5-32, at the top of the pattern).

There are multiple operational examples of alphabetized lists working this way, but there is no reason why another ordering—by number or by date, for example—couldn’t also work well. Consider expanding this pattern beyond the alphabet!

The iPhone offers what is probably the best-known example of this pattern. Figure 5-33 shows its built-in Contacts app.

Figure 5-33. iPhone contacts list

Express a hierarchy by showing selectable lists of the items in each hierarchy level. Selection of any item shows that item’s children in the next list.

The list items are arranged in a hierarchy. The hierarchy might be deep, and it might have many items on each level. A tree (outline) would work, but the user would have to scroll up and down a lot to see all the items, and he wouldn’t get a good overview of the items at higher levels in the hierarchy.

The hierarchy may be a literal one, such as a filesystem, or a conceptual one—this pattern is often used to let a user navigate and choose items within categories or make a series of interdependent choices, as with the fonts in the example in Figure 5-34 at the top of the pattern.

By spreading the hierarchy out across several scrolled lists, you show more of it at once. It’s that simple. Visibility is helpful when you’re dealing with complex information structures. Also, laying the items out in lists organizes them nicely—a user can more easily keep track of what level he’s dealing with than he could with an outline format, since the hierarchy levels are in nice, predictable, fixed-position lists.

Put the first level of the hierarchy in the leftmost list (which should use single-selection semantics). When the user selects an item in it, show that item’s children in the next list to the right. Do the same with the child items in this second list; show its selected item’s children in the third list. And so on.

Once the user reaches items with no children—the “leaf” items, as opposed to “branches”—you might want to show the details of the last-selected item at the far right. An image file typically displays a thumbnail; you might instead offer a UI for editing an item, reading its content, or whatever is appropriate for your particular application.

A nice thing about this pattern is that you can easily associate buttons with each list: delete the current item, move up, move down, and so on. Many toolkits will let you do this in tree controls via direct manipulation, but for those that don’t have built-in tree controls, this is a viable alternative.

The Mac OS Finder screenshot shown in Figure 5-35 is an extreme example, with seven levels. But it shows that the pattern scales well, letting the user drill down into deep filesystem hierarchies while staying oriented. (Warning: this can be confusing for people who aren’t familiar with this pattern and the concept of a hierarchy.)

Figure 5-35. Mac OS Finder

NeXTSTEP originally used this technique in its own File Viewer, circa 1990 or so. The example in Figure 5-36 is from http://www120.pair.com/mccarthy/nextstep/intro.htmld/Workspace.html.

Figure 5-36. NeXTSTEP File Viewer

http://quince.infragistics.com/Patterns/Cascading%20Lists.aspx

Put item fields in table-like columns, but use an indented outline structure in the first column to illustrate the tree structure.

The items in a list are highly structured, with specific attributes that are of interest to users. You can show them in a multicolumn list or table. But the items are primarily organized as a hierarchy, so you also want a tree to display them most of the time.

Your users are relatively sophisticated with respect to interface usage; this is not an easy pattern for naive computer users to understand (and the same can be said about most hierarchical views, including trees and Cascading Lists).

Combining the two data-viewing approaches into one view gives you the best of both worlds, at the cost of some visual and programming complexity. You can show the hierarchy of items, plus a matrix of additional data or item attributes, in one unified structure.

The examples show what you need to do: put the tree (really an outline) in the first column, and the item attributes in the subsequent columns. The rows—one item per row—are usually selectable. Naturally, this can be combined with Sortable Table to produce a more browsable, interactive structure. Sorting on the columns disrupts the tree ordering, so you’ll need to provide an extra button or some other affordance to re-sort the table into the order required by the tree.

This technique seems to have found a home in email clients and news readers, where threads of discussion form tree-like structures.

The Firefox browser once used a distinctive-looking Tree Table in one of its dialog boxes. The separators—horizontal lines—help to visually group the items in different categories, which isn’t a bad idea at all (see Figure 5-38).

Figure 5-38. Firefox Bookmarks Manager, from an early version of the browser

http://quince.infragistics.com/Patterns/Tree-Table.aspx

Use the last or first row in the list or table to create a new item in place.

The interface contains a table, list, tree view, or any other vertical presentation of a set of items (one item per row). At some point, the user needs to add new items to it. But you don’t have a lot of room to spare on the UI for extra buttons or options, and you want to make item creation very efficient and easy for the user.

By letting the user type directly into the end (or the beginning) of the table, you put the act of creation into the same place where the item will ultimately “live.” It’s conceptually more coherent than putting it in some other part of the UI. Also, it makes the interface more elegant than having an entirely different UI for item creation—it uses less screen real estate, it reduces the amount of navigation that needs to be done (thus eliminating a “jump” to another window), and it’s less work for your users.

Give the user an easy and obvious way to initiate a new object from the first empty table row. A single mouse click in that row might start editing, for instance, or the row might contain a “New Whatever” pushbutton, or it might contain a dummy item as shown at the top of the pattern in Figure 5-39.

At that point, the UI should create the new item and put it in that row. Each column in the table (if it’s a multicolumn table) should then be editable, thus letting the user set up the values of that item. The cells could have text fields in them, or drop-down lists, or whatever else is necessary to set the values quickly and precisely. As with any form-like user input, Good Defaults (Chapter 8) help save the user work by prefilling those values; the user doesn’t have to edit every column.

There are still some loose ends to clean up, though. What happens if the user abandons the new item before finishing? You can establish a valid item right from the beginning—if the user abandons the edits at any time, the item exists until the user goes back and deletes it. Again, Good Defaults help by prefilling valid values if there are multiple fields.

Depending on how it’s implemented, this pattern can resemble Input Prompt (Chapter 8). In both cases, a dummy value is set up for the user to edit into a real value, and that dummy value is worded as a “prompt” that shows the user what to do.

Excel’s built-in spreadsheet templates, such as the one shown in Figure 5-40 for budgeting, mark the New-Item Row very clearly by putting a blue box around the entire row. The PowerPoint outline view shown in Figure 5-41 affords creation of new slides by typing into the bottom row, but the interface is subtler and hard to notice. (I went looking for this feature before I found it; I never knew beforehand that it existed.)

Figure 5-40. New entry in an Excel ledger

Figure 5-41. New slide in a PowerPoint slideshow

http://quince.infragistics.com/Patterns/New-Item%20Row.aspx

http://www.welie.com/patterns/showPattern.php?patternID=list-entry-view