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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
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):
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.
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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.
Uber Eats (Figure 7-12) uses cards without a border to show a photo, the restaurant name, and user ratings.
For more information on cards, check out the following:
Arrange a list of visual items into a “small multiples” grid of photos, as illustrated in Figure 7-13.
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.
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.
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.
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 video application, HBO Now, shown in Figure 7-15, features a photo and title of the movie or TV show in a thumbnail grid.
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.
For more information on thumbnail lists, check out the following:
Arrange a list of visually interesting items arranged into a horizontal strip or arc, as demonstrated in Figure 7-17. This lets the user scroll or swipe the image thumbnails back and forth to view them.
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, they won’t mind moving past many items before finding the one they’re looking for. You might 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 they must scroll through everything—this pattern thus encourages browsing and serendipity.
Carousels are compact vertically, so they can 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.
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 imposes even stricter restraints—thumbnails of different sizes 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 scroll bar below the Carouselin addition to the arrows. You might 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 can 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 Carousels 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 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 shows book covers this way (Figure 7-18); 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?
Both Amazon and Airbnb (Figure 7-19) provide arrows with their Carousels. This helps the user understand that there is more content beyond the bounds of the window.
Break up a very long list into pages, and load them one page at a time. Provide controls to navigate the list, as shown in Figure 7-20.
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 screen or scrolled are, for any of the following reasons:
Loading the entire list would take too much time, and you don’t want to make the user wait. This might be the case over a slow internet connection or with a slow backend server.
Rendering the list would take too much time.
The list is effectively “bottomless,” and implementing an Infinite List or a continuously scrolling list (which both handle bottomless lists) isn’t feasible for some reason.
“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 screen 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 can come prebuilt in some systems.
First, you’ll need to decide how many items will be in each screen. 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 screen.
This is fairly important: the first screen should be enough! The odds are good that most users won’t go beyond that first screen of items, so if they can’t find what they’re looking for on the first screen, they might become discouraged. (If you’re dealing with a search facility, make sure that it returns high-quality results at the top of that first screen.)
For screens on which users might linger, such as lists of products or videos, consider letting the user set the number of items per screen. Some people are irritated by having to screen 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 screen, but some designs also have them at the top—if a user really does need to go to a subsequent screen of items, there’s no need to make them scroll all the way down the screen.
Consider these elements in the pagination control:
Previous and Next links, with arrows or triangles for emphasis. Disable the Previous link when the user is on the first screen and the Next link when the user is on the last screen (if there is a known last screen).
A link to the first screen. This should always be visible; remember that the first screen is supposed to contain the most relevant items.
A sequence of numbered links to screens. Don’t link the screen the user is on, of course; instead, show it in a contrasting color and type size to give the user a “You are here” navigational clue.
Ellipses to cut out parts of the sequence if there are too many screens to reasonably show in the control—more than 20, for instance. Again, keep the first screen, and the last screen if the list isn’t “bottomless.” Keep the screens immediately before and after the user’s current screen. Elide the rest.
Optionally, the total number of screens (if known). You could do this in several ways, such as showing text like “screen 2 out of 45,” or simply showing the last screen as a numbered link at the end of the pagination control.
Etsy does an excellent job of including all the elements and cues from the preceding list. Figure 7-21 shows the first screen for a very large number of items.
Figure 7-22 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 screens. Also note the size of the click targets. How accurate does the user need to be with their mouse or fingertip?
When the user types the name of an item into a list, jump straight to that item, as depicted in Figure 7-23.
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.
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.
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.
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.
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).
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.
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.
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.
The iPhone offers what is probably the best-known example of this pattern. Figure 7-25 (right) shows its built-in Contacts app.
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.
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.
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” 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.
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.
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.
3.133.131.168