C H A P T E R 1 4

Windows

Figure 14-21 A scope bar can act as a filter

As you choose the locations and categories that should appear in a scope bar, revisit the user’s mental model of the tasks your application performs. (See “Reflect the User’s Mental Model” (page 39) for more information on discovering this cognitive model.) Determine the objects the user works with, and identify the attributes of those objects. For example, an application that allows users to create, use, and store recipes might display a scope bar when the user begins a search, providing buttons that correspond to different recipe collections.

If appropriate, allow users to define subsets of the locations and categories you offer by providing filter rows that display additional rules and filtering criteria. For example, the recipe application described above could display filter rows that allow users to filter their results by ingredient, cuisine, seasonal availability, complexity, date last used, diet type, and other criteria. You should also allow users to save their searches. As shown in Figure 14-20 (page 202), the Finder offers many types of additional filtering functionality and the ability to save searches.

Source Lists

A source list (also called a sidebar) is an area of a window, usually set off by a movable splitter, that provides users with a way to navigate or select objects in the application (for more information on splitters, see “Split Views” (page 327)). Typically, users select an object in the source list that they act on in the main part of the window. You can provide a source list as the primary means of navigating or viewing within your application, as the Finder and iTunes do, or as a way to select a view in a part of the application, as some panes in System Preferences do.

Figure 14-22 shows some examples of source lists that function as primary navigation and selection mechanisms.

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 4

Windows

Figure 14-22 Source lists help users navigate and select collections of objects or data

Source List Behavior and Appearance

In Mac OS X v10.5 and later, source lists look different depending on their usage. A source list that provides the primary navigation or selection mechanism for the application as a whole displays a blue background. This type of source list should be the only source list in the application window and should always be visible (unless the user chooses to hide it). The Finder sidebar (shown on the left in Figure 14-22 (page 204)) is an example of this type of source list: It provides primary navigation and selection functionality for the application, it's separated from the rest of the window by a movable splitter, and it’s always visible (unless the user chooses to hide it and the toolbar).

The other style of source list is often used in preferences windows. This type of source list provides selection functionality for the window, but not the application as a whole. A source list of this type displays a white background and might not be separated from the rest of the window by a movable splitter. The Network System Preferences pane contains this type of source list, as shown in Figure 14-23.

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 4

Windows

Figure 14-23 A source list may support selection in a window, not in the application as a whole

Source lists don’t generally have headers like lists can, but they can display titles to distinguish subsets of objects or data. For example, the Finder displays several useful subsets of locations in its sidebar, such as Devices, Shared, and Places, as shown on the left in Figure 14-22 (page 204).

Designing a Source List

Source lists provide a very effective file-system abstraction. This means that a source list can shield users from the details of file and document management, allowing them to work with user-customizable, application-specific containers that hold related items. These high-level container objects can hide the actual file-system locations of their files and data and conceal the associations between them. This can relieve users of the burden of locating and opening the auxiliary or related files they need to do their work.

Source lists are especially useful in single-window applications that are not necessarily document-based, but that allow users to create and manage content. For example, iTunes allows users to ignore the file-system locations of their songs, podcasts, and movies, and instead work with libraries and playlists. Similarly, iWeb focuses on website creation, not file management.

You should consider including a source list in your application when:

■Navigation and selection of content are primary tasks.

■Collections of objects are key to the user’s mental model (see “Reflect the User’s Mental Model” (page 39) to learn more about the mental model).

■The hierarchical arrangement of objects presents a natural way to navigate.

■Arranging objects hierarchically removes complexity.

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.

C H A P T E R 1 4

Windows

Because the source list is a navigation and selection tool, it should not contain controls other than controls used to organize the data itself. For example, you can use a disclosure triangle to reveal an additional level of hierarchy (disclosure triangles are described in “Disclosure Triangles” (page 320)). Figure 14-24 shows how Mail uses disclosure triangles to display two levels of hierarchically organized information.

Figure 14-24 A source list can contain disclosure triangles

A source list should not contain more than two levels of hierarchy. If the data you need to display is organized in more than two levels of hierarchy, you can use a second source list, but you should not use additional disclosure triangles to expose additional levels of hierarchy in a single source list. If, however, your application is centered on the navigation of deeply nested objects, you should consider using a browser view instead of multiple source lists.

As mentioned in “Source List Appearance and Behavior” (page 204), if your application contains a single source list that provides primary navigation and selection functionality, you can use the blue background. In all other cases, however, you should use the white background. Specifically, use the white background when:

■Your window contains more than one source list.

■You use a source list in a panel or preferences window.

You should allow users to customize the contents of a source list. This way, you allow users to decide what object containers are most important to them. You should also consider using Spotlight to support smart data containers. For more information on using Spotlight in your application, read Spotlight Overview.

If you need to allow users to add, remove, manipulate, or get information about items in the source list, you have two options:

■If your window has a bottom bar, you can place window-frame controls in the bottom bar directly below the source list. See “Controls for Toolbars and Bottom Bars” (page 250) for more information about the controls you can use in a bottom bar; see “Bottom Bars” (page 207) for more information on designing bottom bars.

■If your window does not have a bottom bar, you can use gradient buttons at the bottom edge of the source list. Gradient buttons blend well with the background of the source list and look good with the bottom edge of the window-body area. See “Gradient Buttons” (page 265) for details about using gradient buttons.

2008-06-09 | © 1992, 2001-2003, 2008 Apple Inc. All Rights Reserved.