Chapter 7. Lists of Things

This chapter covers only one topic: how to display lists of items in an interactive setting. Just lists.

Why do lists merit their own chapter, you may ask?

Lists are everywhere in screen design. Consider the many types of items that we show in lists: articles, screens, photos, videos, maps, books, games, movies, TV shows, songs, products, email messages, blog entries, status updates, forum posts, comments, search results, people, events, files, documents, apps, links, URLs, tools, modes, and actions. And that list of lists goes on and on.

Practically every interface or website ever designed includes lists. This chapter will help you think about them logically and clearly, understand different design aspects, and make good trade-offs when designing interfaces that use lists.

Use Cases for Lists

Before jumping into a design, it’s useful to analyze the use cases for a list. What will people need to do with the list? Consider which of these scenarios apply:

Getting an overview

What impression will someone get from the list as a whole? In some cases, a user should be able to skim down the list and understand what it’s about. Often that requires more than just words; it might require images or carefulvisual organization to convey that impression.

Browsing item by item

Will the user peruse items randomly or in order? Do they need to click or tap items to open them? If so, it should be easy to go back to the list and find another item, or move directly to the next one.

Searching for a specific item

Is the user looking for something in particular? They should be able to find it quickly, with a minimum of clicks, scrolling, and back-and-forth.

Sorting and filtering

If someone is looking for an item or group of items with a specific characteristic (e.g., “anything with a date between X and Y”) or is looking for general insight into a set of data, sorting and filtering functions might help.

Rearranging, adding, deleting, or recategorizing items

Does the user have the need to rearrange the items? Does the user own the list and the items within it? Most apps and sites that show personal collections permit direct manipulation of those lists so that the user can drag items around into a desired order or grouping scheme. They should also be able to select multiple items at a time for moving, editing, or deleting; a design should either use the platform standards for multiple selection (e.g., Shift-select or tapping in an edit mode), or supply checkboxes beside each item to permit the user to select an arbitrary subset.

Back to Information Architecture

We discussed information architecture in Chapter 2—organizing information, independent of its visual representation. Let’s return to it for a minute. If you have a list of things to show on a screen, what are the salient nonvisual characteristics of that list?

  • Length

    • How long is the list? Can it fit in the space you’ve designed for it?

    • Could the list sometimes be “bottomless”? For example, web search results often constitute such a long list that the user will never reach the end; likewise for items taken from a very large and deep archive.

  • Order

    • Does the list have a natural order, such as alphabetical or by time? (See Chapter 2 for a more in-depth discussion of ways to organize data and content.)

    • Would it make sense for a user to change the sorting order of the list? If so, what would the user sort on?

    • If you choose to put a list into an order, would it actually make more sense as a grouping scheme, or vice versa? As an example, think about a blog archive: the articles are naturally ordered by time, and most blogs categorize them by month and year, rather than offering a flat ordered list. Someone looking for a particular article might remember that “it was before article X but after article Y,” but not remember exactly which month it was published. A monthly grouping thus makes it hard to find that article; a time-ordered flat list of titles might work better.

  • Grouping

    • Do the items come in categories? Is it a natural categorization that users will immediately understand? If not, how can you explain it, either verbally or visually?

    • Do these categories come in larger categories? More broadly, do the items fit into a multilevel hierarchy, such as files in a filesystem?

    • Are there several potential categorizations? Would they fit different use cases or user personas? And can users create their own categories for their own purposes?

  • Item types

    • What are the items like? Are they simple, or are they rich and complex? Are they just stand-ins for larger things, such as headlines for articles or thumbnails for video clips?

    • Are the items in a list very different from each other (e.g., some are simple and some are complex)? Or are they homogeneous?

    • Does each item have an image or picture associated with it?

    • Does each item have a strict field-like structure? Would it help the user to know that structure, or possibly even sort the list based on different fields? (Email messages typically have a strict and sortable structure—timestamp, from field, subject, etc.—and this structure is shown in lists of messages.)

  • Interaction

    • Should you show the whole item at once in the list, or can you just show a representation of the item (such as its name or the first few sentences) and hide the rest?

    • What is the user supposed to do with those items? Should they be looked at? Should they be selected for inspection, or for performing tasks on them? Or are they links or buttons to be clicked on?

    • Does it make sense for the user to select multiple items at a time?

  • Dynamic behavior

    • How long does it take to load the entire list? Can it be more or less immediate, or will there be a noticeable delay as the list is put together somewhere and finally shown to the user?

    • Will the list change on the fly? Should you show the updates as they happen? Does this mean inserting new items at the top of the list automatically?

The answers to these questions might suggest a variety of design solutions to you. Of course, a solution should also take into account the type of content (blogs should look different from, say, contact lists), the surrounding screen layout, and implementation constraints.

What Are You Trying to Show?

The interaction questions listed in the preceding section set the tone for almost all other decisions. For instance, a fully interactive list—multiple selection, drag-and-drop, editing items, and so on—tends to dominate the interface. You might be building a photo management app, an email client, or some other full-fledged application that people use to manage and enjoy the content that they own.

In this and other types of interfaces, a common requirement is to show only item names or thumbnails in a list—just a representation of each item—and then display the whole item when the user selects one from the list. There are at least three ways to do this.

“When the user selects an item from a list, where should I show the details of that item?”

Two-Panel Selector or Split View shows the item details right next to the list. It supports the overview and browsing use cases quite well because everything’s visible at once; the surrounding screen stays the same, so there’s no awkward context switch or screen reload.

One-Window Drilldown replaces the list’s space with the item details. This is often used for small spaces that cannot accommodate a Two-Panel Selector, such as mobile screens or small module panels. It does lead the user to “pogo-stick” between the list screen and the item screen, though, so browsing and searching are not so easy.

List Inlay shows the item details embedded in the list itself. The list expands to show the detail when the user clicks or taps. This pattern supports the overview and browsing use cases, too—though an overview is more difficult if lots of items are open.

Now let’s shift our attention to the items that appear on a list. How much detail should you show with each item, assuming that the user will click or tap through to see the whole thing? Again, you have three main use cases to serve: get a quick overview, browse the list, and find items of interest. For really focused tasks, such as finding a person’s phone number in a long contact list, all that’s needed is the item name. But for a broader, more browsing-oriented experience—news articles on a web screen, for instance—more information makes an item more interesting (up to a point, anyway). And if you have visuals associated with each item you should show the thumbnails.

“How can I show a list of items that have heavy visuals?”

Cards consolidate images, text and functionality into one user interface (UI) element. See the Grid of Equals (Chapter 4) for the basis of this pattern.

Thumbnail Grid is a common pattern for pictorial objects. A 2D grid of small pictures is visually powerful; it dominates the screen and draws attention. Text data is often shown with the thumbnails, but it tends to be small and less important than the pictures. Again, see the Grid of Equals pattern for a generalization.

Carousel is an alternative to Thumbnail Grid that can use less space on the screen. It is strictly linear, not 2D, and the user must actively scroll through it to see more than a few objects. Depending on its design, a Carousel implementation might actually give you more space to show the selected or center object than a Thumbnail Grid.

Very long lists can be difficult to design. Certainly, there are technical challenges around loading times and screen length, but interaction design might be even harder—how does a user browse and move through such a list? How can they find something specific, especially if a text search doesn’t behave as desired? The following techniques and patterns apply to all the previously listed ways to show a list and its items (except maybe a Carousel, which has tighter constraints):

“How can I manage a very long list?”

Pagination lets you load the list in sections, putting the onus on the user to load those sections as needed. This is, of course, quite common in websites—it’s easy to design and implement. Pagination is most useful when the user is likely to find the desired item(s) in the first screen given that many people won’t bother going to subsequent screens anyway. You could also resort to Pagination when loading the entire list will result in a ridiculously long screen or take a ridiculously long time. A good Pagination control shows the user how many screens of items there are as well as letting a user jump among those screens.

Common in mobile designs, the Infinite List (Chapter 6) is a single-screen alternative to Pagination. The first section of a long list gets loaded, and at the bottom the user finds a button that loads and appends the next section. The user stays on one screen. This pattern is useful when you don’t actually know how long the list will be, or when it’s bottomless.

A variant on Infinite List has the list automatically loading itself as the user scrolls down. See the Continuous Scrolling pattern.

When a very long alphabetized list or range of dates is kept in a scrolled box, consider using an Alpha/Numeric Scroller. This device shows the alphabet arrayed along the scroll bar itself; the user can then jump directly to a desired letter.

Direct searching via a Find field may be critical for helping your users to find specific items. Also, filtering a list—screening out entire classes of items that don’t meet certain criteria—can help shorten a list to a manageable size.

So far, this section has talked mostly about flat lists: those that have no categories, containment, or hierarchy. However a list might be rendered, you might still want to break it up into categories for clarity.

“How can I show a list that’s organized into categories or hierarchies?”

Titled Sections work well for a single level of containment. Just separate the list into sections with titles, and perhaps allow the user to sort the list within a single section so as not to disrupt the categorization. If you have only a few sections, try an Accordion—this lets the user close list sections that they don’t need.

For two or more levels of hierarchy, basic trees are the standby solution. These are normally presented with indented hierarchy levels, and with icons such as pluses and minuses (commonly found on Windows) or rotating triangles. The levels can be closed and opened by the users or automatically by the interface as needed. Many UI toolkits offer tree implementations.

Next, we will take a deeper dive into how the solutions for showing lists actually appear on the web and in mobile UIs.

The Patterns

Now that you have identified what the purpose is for the list you are showing, let’s take a look at when and how to use them.

  • Two-Panel Selector or Split View

  • One-Window Drilldown

  • List Inlay

  • Cards

  • Thumbnail Grid

  • Carousel

  • Pagination

  • Jump to Item

  • Alpha/Numeric Scroller

  • New-Item Row

Two-Panel Selector or Split View

What

Also known as a Split View, this consists of 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, as demonstrated in Figure 7-1, which shows the Spotify website.

Spotify
Figure 7-1. Spotify

Use when

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 them 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 smartphone displays cannot cope with this pattern, but many larger mobile devices like tablets can.

Why

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 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 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:

  • It reduces physical effort. The user’s eyes don’t need to travel a long distance between the panels, and they can change the selection with a single mouse click or key press rather than first navigating between windows or screens (which can take an extra mouse click).

  • It reduces visual cognitive load. When a window pops to the top, or when a screen’s contents are completely changed (as happens with One-Window Drilldown), the user suddenly must pay more attention to what their now looking at; when the window stays mostly stable, as in a Two-Panel Selector, the user can focus on the smaller area that did change. There is no major “context switch” on the screen.

  • It reduces the user’s memory burden. Think about the email example again: when the user is looking at just the text of an email message, there’s nothing on-screen to remind them of where that message is in the context of their inbox. If they want to know, they must remember, or navigate back to the list. But if the list is already on-screen, the user merely has to look, not remember. The list thus serves as a “You are here” signpost.

  • It’s faster than loading a new screen for each item, as can happen with One-Window Drilldown.

How

Place the selectable list on the top or left panel, and the details panel below it or to its right, as shown in Figure 7-2. 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 their 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.

Apple iOS News
Figure 7-2. Apple iOS News

Make the selected item visually obvious. Most 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 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 graphical user interface (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, and One-Window Drilldown is like a Menu Screen.

Examples

Many email clients (Figure 7-3) use this pattern to show a list of email messages next to the currently selected message. Such listings benefit from being nearly as wide as the entire window, so it makes sense to put the listing on top of the second panel, not to its left.

Google Mail
Figure 7-3. Google Mail

Apple Photos (Figure 7-4) 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.

Apple Photos
Figure 7-4. Apple Photos

One-Window Drilldown

What

Show a list of items in a single screen or window. When the user selects an item from the list, show the details or contents of that item in the screen, replacing the list, as in the example in Figure 7-5.

Mac Mail on iPhone
Figure 7-5. Mac Mail on iPhone

Use when

You are designing for mobile applications or websites. 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.

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 screen to list conversation topics and a separate scrolled screen to show the conversations themselves.

Why

In a very constrained space, this might 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 screen.

The shallow hierarchy of the one window drilldown pattern helps your user to not get too deep in the UI and makes it easy to return to the list where they started.

How

Create the list using whatever layout or format you find best—simple text names, cards, rows, trees, or outlines all work fine with Thumbnail Grid, 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 can 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 screen and the item screen. 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.

Examples

Examples abound in mobile design. Contrast the mobile version of a mail client shown in Figure 7-5 with its desktop counterpart. 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.

In the example in Figure 7-6 a reader can scroll through all the comments on a post in Reddit, and by clicking the back arrow in the header, easily return back to the Topic to view other threads.

Reddit
Figure 7-6. Reddit

List Inlay

What

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 (Figure 7-7). Allow items to be opened and closed independently of each other.

Kayak’s expanding list items
Figure 7-7. Kayak’s expanding list items

Use when

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 them to browse through the items easily and quickly. Users might want to see two or more item contents at a time, for comparison.

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

Why

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, whereas the item containers (mailboxes, groupings, filters, etc.) are shown next to it in a Two-Panel Selector structure.

How

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

When an item is opened, enlarge the item’s space downward, pushing the subsequent items down the screen. Other items do the same when opened. A scrolled area should be used to contain this ever-changing vertical structure because it could become 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 might need it at the top of the panel if it is long and they don’t want to move all the way down to the bottom. 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 they want 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 Screen.

Examples

Apple iOS Voice Memos (Figure 7-8) uses a List Inlay to hide functionality and only shows the playback and recording controls when a user taps on the recording in the list.

Apple iOS Voice Memos
Figure 7-8. Apple iOS Voice Memos

The Transit app (Figure 7-9) demonstrates a unique hybrid use of a List Inlay behavior combined with a modal window. When a user sees routes nearest them, they can tap the route and the list expands not only to see the times the next bus or train arrives, but it also reveals the specific stops they can expect along the route.

Transit
Figure 7-9. Transit

Further reading

Bill Scott and Theresa Neil identified this technique in their book, Designing Web Interfaces (O’Reilly, 2009). List Inlay is one of a set of inlay techniques that includes Dialog Inlays and Detail Inlays.

Cards

What

Cards are one of the most popular and flexible UI components in use. Cards are self-contained components that have images, text, and sometimes actions. They were given their name because they resemble playing cards. You can find examples of these nifty components in newer websites and mobile applications that were designed to be responsive (resizable) and use popular UI component libraries. Pinterest’s use of cards is shown in Figure 7-10.

Pinterest, website and mobile app
Figure 7-10. Pinterest website and mobile app

Use when

You are showing a list of heterogeneous items and they will all have the same behaviors associated with them. For example, all of the items will contain an image, some text, a way to “favorite” or share the item, and a link to a detail screen.

You need to show a collection of items, but each item might differ in size and/or aspect ratio.

Why

Cards are used frequently in mobile and web design, so a user will likely have seen this UI convention before. Cards allow a great deal of flexibility in the layout or size of the viewport (screen type) your user will be viewing them on.

How

Think about the things you want a user to do with the list of items you are showing. What are their commonalities? Do they all have a picture, a title, and a short description? Perhaps they will show a rating? What do you want the user to do? Do you want them to link to a detail screen? Add the item to a cart? Share the item to social media? Will all of the items do the same thing? If so, a card will be likely be the best way to show your list.

A good practice when designing is to take the item with the most or longest amount of content and mock it up. Do the same for the one with the least or smallest amount of content. Tweak your layouts until your design looks good and the information is readable and clear at both sizes.

Consider which actions will be icons and which will be text links. Use real examples of the photos you will be using to determine the best orientation (portrait or landscape) that works for the type of content you will be showing.

Examples

Airbnb (Figure 7-11) uses cards all over its website and mobile application to display homes and experiences listings. Using this style for its listings ensures a consistent look and feel and also offers a visually pleasing way to view the information without giving more visual weight to one listing over another.

Airbnb website and mobile App
Figure 7-11. Airbnb website and mobile App

Uber Eats (Figure 7-12) uses cards without a border to show a photo, the restaurant name, and user ratings. 

Uber Eats search results
Figure 7-12. Uber Eats search results

Further reading

For more information on cards, check out the following:

Thumbnail Grid

What

Arrange a list of visual items into a “small multiples” grid of photos, as illustrated in Figure 7-13.

Google Photos app
Figure 7-13. Google Photos app

Use when

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 can be long, and it can be divided into Titled Sections.

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 entire list, and they might need to scan it quickly to find a particular item of interest. Users might also need to select one or more items at a time for moving, deleting, or viewing.

Why

A Thumbnail Grid is a dense, attractive presentation of large numbers of items. A specialized instance of Grid of Equals, 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 screen.

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 and tablet screens.

How

Scale the thumbnails so that they’re 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 visual prominence.

Some Thumbnail Grids 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.

Examples

The macOS Finder (Figure 7-14) displays a variety of thumbnail types for a file directory listing. 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.

The macOS Finder
Figure 7-14. The macOS Finder

The video application, HBO Now, shown in Figure 7-15, features a photo and title of the movie or TV show in a thumbnail grid.

HBO Now search results
Figure 7-15. HBO Now search results

Mobile devices need Thumbnail Grid in many contexts: to show applications, features, and images themselves. Note the relative sizes of the thumbnails in Figure 7-16; the Google Images and iPhone home screen examples are just big enough to be touched easily by human fingertips.

Google Drive
Figure 7-16. Google Drive

Jump to Item

What

When the user types the name of an item into a list, jump straight to that item, as depicted in Figure 7-23.

Font Book app
Figure 7-23. Font Book app

Use when

The interface uses a scrolling list, table, drop-down box, 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.

Why

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 their hands on the keyboard. As the user moves through a form or dialog box, they might find it nice to select from a list simply by typing the first few characters of the item they want—the system then picks the item for the user, and they can continue on to the next thing. No scrolling or clicking is necessary; the user’s hand never needs to move from the keyboard to the mouse.

How

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

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

Examples

A variant of Jump to Item is used by Spotify’s search functionality. A user can start typing and the search results will begin to show different results as each letter allows the system to better predict what songs or artists the user is looking for.

In the example in Figure 7-24 in the upper left, I have typed “Brian” and the results show Spotify’s algorithms best guess at what I am searching for. I don’t even have to type the second word before the search results display the artist I was searching for. In some ways, this incremental search is more convenient—and certainly faster.

Spotify’s variant of the Jump to Item pattern
Figure 7-24. Spotify’s variant of the Jump to Item pattern

Alpha/Numeric Scroller

What

Display the letters of the alphabet, numbers, or a timeline arrayed along the scroll bar of a list, as shown in Figure 7-25 (left).

Use when

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.

Why

Alpha/Numeric 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 Scroll Bar. 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.

How

Place a long list into a scrolled area. Along the scroll bar, show the letters of the alphabet or date; when the user clicks a letter, scroll the list to that point.

Examples

The iPhone offers what is probably the best-known example of this pattern. Figure 7-25 (right) shows its built-in Contacts app.

Apple iOS Health app Date Scroller control and the iPhone Contacts list
Figure 7-25. Apple iOS Health app Date Scroller control and the iPhone Contacts list

New-Item Row

What

Use the last or first row in the list or table to create a new item in place, as in the fourth list item in Figure 7-26.

Hulu, Profile Switcher
Figure 7-26. Hulu, Profile Switcher

Use when

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.

Also use when you want to be explicit about what type of information or functionality the user is adding.

Why

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.

How

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” button.

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 10) 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 (also Chapter 10). 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.

Examples

You can find the new item row pattern most frequently in applications where the user organizes or created their own content.

Slack (Figure 7-27) uses this same pattern in its “Add Workspaces” function.

Slack, Add Workspaces
Figure 7-27. Slack → Add Workspaces

Lists Abound

In this chapter, we have covered the most common ways to show lists and when to use them. As is evident, a lot of the content you see on the web and in mobile applications are actually lists. When designing for lists, try out different ways in which you might display your content, and remember to always keep in mind what the task your user is trying to do and optimize your design for it.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.133.131.168