A popover is a transient UI element that provides functionality that is directly related to a specific context, such as a control or an onscreen area. Popovers appear when users need them and (usually) disappear automatically when users finish interacting with them. For example, Calendar displays a popover in which users can create and edit a meeting.
A popover floats above the window that contains the control or area that it’s related to, and its border includes an arrow (sometimes referred to as an anchor) that indicates the point from which it emerged. In some cases, users can detach a popover from its related element, which causes the popover to become a panel. For example, Calendar allows users to detach the meeting-editing popover so that they can make changes to it while they refer to other windows.
To learn how to define a popover in your code, see
NSPopover. Follow the guidelines in this section to use popovers appropriately in your app.
Use a popover to display UI that users need occasionally. Popovers are perfectly suited to provide small amounts of focused functionality that users need. For example, when users select a term and open a contextual menu, they can choose the Look Up “term” menu item to see the Dictionary definition (in addition to information related to the term) in a popover.
Because popovers can disappear when users finish interacting with them, users can spend more time focusing on their content and less time removing clutter from their workspace.
Consider using popovers instead of source lists, panels, or changeable panes. You might want to use a popover instead of these UI elements because doing so allows you to present a more focused and stable UI. For example, users might not need to navigate or select objects in your window’s source list very often. If you use a popover to display the source list’s content, you can use the window space for more important UI that directly relates to the user’s task.
Using a popover to replace a panel that contains auxiliary information can also make sense, because you can ensure that the popover disappears when users click outside of it. For example, users appreciate that they don’t have to explicitly dismiss the Safari Downloads popover before they continue interacting with the Safari browser window.
Finally, using a popover to replace changeable panes in a main window can help your UI seem more stable. For example, if you offer secondary or transient functionality in a pane that users can hide and reveal, you can instead offer the functionality in a popover. Because a popover appears only when it’s needed, it doesn’t alter the look of the window. Users tend to be most comfortable with a window layout that does not change very often.
Allow users to detach a popover if appropriate. Users might appreciate being able to convert a popover into a panel if they want to view other content or other windows while the popover content remains visible.
Don’t use a popover as an alert. Popovers and alerts are very different UI elements. For one thing, users choose to see a popover; they never choose to see an alert. If you use popovers and alerts interchangeably, you blur the distinctions between them and confuse users. In particular, if you use a popover to warn users about a serious problem or to help them avoid imminent, unintentional data loss, they are likely to dismiss the popover without reading it, and blame your app when negative results occur. If you really need to alert users (which should happen only rarely), use an alert; for guidelines on how to design an alert, see Alerts.
As much as possible, ensure that the popover arrow points directly to the element that revealed it. The arrow helps people remember where the popover came from and with what task or object it’s associated.
In general, use the standard popover appearance. The standard appearance is identified by the
NSPopoverAppearanceMinimal constant. You can also use the “HUD” appearance, but this is generally only suited to an app that uses a dark UI and enables an immersive, media-centric experience.
Avoid including a “close popover” button. In general, a popover should close automatically when the user doesn’t need it anymore. This behavior helps users focus on their task without worrying about cluttering their desktop. For example, after users finish editing an Calendar event, they can click Done or they can click outside the event-editing popover to close it. Regardless of the method users choose, Calendar saves the edits they made.
Choose a closure behavior that makes sense in the context of the task the popover enables. A popover can close in response to a user interaction (transient behavior), in response to a user’s interaction with the view or element from which the popover emerged (semitransient behavior), or in an app-defined way. If a popover merely presents a set of choices, it can be appropriate to close it as soon as the user makes a choice (that is, using the transient behavior). Because this behavior mirrors the behavior of a menu, users are comfortable with it. If, on the other hand, you use a popover to enable a task that requires multiple user interactions, such as the Calendar event editing popover, you can use the semitransient behavior to close the popover when the user interacts with the area outside of it.
Avoid nesting popovers. A popover that emerges from a control inside a different popover is physically difficult for users to interact with and confusing to see. In addition, users can’t predict what will happen when they click outside of both popovers.
Avoid making a popover too big. A popover should not appear to take over the entire screen. Instead, it should be just big enough to display its contents and still point to the area from which it emerged.
Avoid making significant appearance changes in a detachable popover. If you allow users to detach a popover, ensure that the resulting panel looks similar to the original popover. If the new panel looks too different, users might forget where it came from.
If appropriate, change a popover’s size while it remains visible. You might want to change a popover’s size if you use it to display both a minimal and an expanded view of the same information. For example, Calendar displays a minimal popover when users double-click a meeting they’ve created. If the user wants to edit the meeting, the minimal popover expands to accommodate more information about the meeting and the editing controls. The transition from one popover size to another should be smoothly animated, so that users can be sure that they’re still interacting with the same popover.
A table view displays data in a one-column list, with optional additional columns that display attributes associated with the data.
A table view displays the entire set of data in the leftmost column (in systems that use left-to-right script). When the data is hierarchical, the child objects are revealed within the primary column, not in other columns (table views use disclosure triangles to indicate objects that contain other objects).
Additional columns in a table view display attributes that apply to the data in the primary column; they don’t contain data that is specific to a different level of hierarchy. In general, users can resize, rearrange, and sometimes add and subtract the columns that represent attributes of the table data.
When users click a disclosure triangle to reveal the child items contained within another item, the table lengthens and the leftmost column can widen. If the primary column widens, other columns might shift to the right, but they don’t change their headings or order.
In an editable table view, users begin editing by clicking once on a selected table row. This behavior allows the table view to respond differently to a double click. In the Finder, for example, users can double-click a file to open it or single-click a selected file to edit its name.
Use a table view to display a list of items along with various attributes of each item. If you need to display a simple list of items, and you don’t need to display associated attributes, you might want to use a scrolling list instead. For more information about scrolling lists, see Scrolling List. Using a table view, you can create a column for each attribute that is associated with the items you display.
Sort the rows in a table view by the selected column heading. You can implement sorting on secondary attributes behind the scenes, but the user should see only one column selected at a time. If the user clicks an already selected column heading, change the direction of the sort.
Create column headers that are nouns or short noun phrases that describe an attribute of the data. When you use clear, succinct attribute names, users quickly understand what information is available in each column.
Column (Browser) View
A column view (also known as a browser view) displays a hierarchy of data, in which each level of the hierarchy is displayed in one column.
Column views don’t use disclosure triangles that reveal content within a column. The triangle displayed to the right of an item shows that the item contains other objects (to reveal those objects, users click anywhere on the item’s row).
Users scroll vertically within columns and horizontally between columns. When users click an object in one column, its contents (that is, its descendants in the hierarchy) are revealed in a column to the right. Each column displays only those objects that are descendants of the item selected in the previous column. If the item selected in the previous column has no descendants, the column to the right might display details about the item.
Columns in column views don’t have headings, because a column view doesn’t behave like a table. A column in a column view contains the objects that exist at a particular node in the hierarchy; it doesn’t contain an attribute of every object in the hierarchy.
Use a column or browser view when there is only one way the data can be sorted or when you want to present only one way of sorting the data. A column view is also useful for displaying a deep hierarchy of data in which users frequently move back and forth among levels.
Display the first or root level of the hierarchy in the leftmost column (in systems that use left-right script). As users select items, the focus moves to the right, displaying either the child objects at that node or, if there are no more children, the terminal object (a leaf node in the hierarchy). When the user selects a terminal object, you can display additional information about it in the rightmost column.
In general, allows users to resize columns. This is especially helpful when the names of some items might be too long to display in the default width of a column.
A split view groups together two or more other views, such as column or table views, and allows the user to adjust the relative width or height of those views. Automator (shown here) uses more than one split view to give users a customizable work area.
A split view includes a splitter bar, or splitter, between each of its subviews; for example, a split view with five subviews would have four splitters. Each subview is generally known as a pane. A split view can arrange views horizontally or vertically, but not both.
The entire splitter bar is a hot zone. In other words, when the pointer passes over any part of the splitter, the pointer changes to one of the move or resize pointers. To learn more about the different pointers that are available, see Pointers. For zero-width splitters, the hot zone includes two points on both sides of the splitter.
Use a split view to display two or more resizable content views.
In general, use the zero-width splitter. Users are accustomed to the appearance of the zero-width splitter. You might want to use a wide splitter bar if you need to indicate a stronger visual distinction between panes, but this is unusual.
Don’t let users lose the splitter. A zero-width splitter can disappear when the user drags it far enough to hide the subview. To avoid this, you can define minimum and maximum sizes for the subviews so that the splitter remains visible. Alternatively, if you want to allow users to completely hide a subview by dragging a zero-width splitter, you should provide a button that re-opens the subview.
A tab view presents information in a multipane format.
A tab view consists of a tab view control (which looks similar to a segmented control) combined with a set of views. Each segment in the tab view control is called a tab. The content area below a tab is called a pane, and each tab is attached to a specific pane. The tab view control is horizontally centered at the top edge of the view.
Users click a tab to view the pane associated with that tab. Although different panes can contains different amounts of content, switching tabs does not change the overall size of the tab view or the window.
Use a tab view to present a small number of different content views in one place within a window. Depending on the size of the window, you can create a tab view that contains between two and about six tabs.
Use a tab view to present a few peer areas of content that are closely related. The outline of a tab view provides a strong visual indication of enclosure. Users expect each tab to display content that is in some way similar or related to the content in the other tabs.
Ensure that each pane contains controls that affect only the contents of that pane. Controls and information in one pane should not affect objects in the rest of the window or in other panes.
In general, inset the tab view so that a margin of window-body area is visible on all sides of the tab view. The inset layout looks good and it allows you to provide additional controls that can affect the window itself (or other tabs). For example, the “Enable access for assistive devices” and “Show Universal Access status in the menu bar” checkboxes in Universal Access preferences are outside of the inset tab view, because they represent settings that affect accessibility generally.
It’s also possible to extend the side and bottom edges of a tab view so that they meet the window edges, although this is unusual.
Provide a label for each tab that describes the contents of the pane. It’s best when users can accurately predict the contents of a pane before they click the tab. Nouns or very short noun phrases work well for tab labels, although a verb (or short verb phrase) might make sense in some contexts. Tab labels should have title-style capitalization (described in Use the Right Capitalization Style in Labels and Text).
Avoid using a pop-up menu as a tab-switcher. This arrangement is not encouraged in modern Mac apps. If you have too many tabs to fit into a single tab view, you should investigate other ways to factor your information hierarchy.
A group box provides a visual way to break a window into distinct logical areas.
The outline of a group box is similar in appearance to the outline of a tab view, except that a group box does not include a tab view control (for more information about tab views, see Tab View). Users don't interact with a group box (for example, they can’t directly resize it), but they can interact with the controls inside it.
Group boxes tend to be untitled, but they can include a text title that appears above the outline of the box.
Group boxes are seldom used in modern Mac apps. You might want to use a group box when you want users to understand logical groupings of controls in a window.
Avoid nesting group boxes. Nested group boxes take up a lot of space, and it can be difficult for users to perceive individual boundaries when group boxes are nested too deeply. Instead, consider using white space to group content within a group box.
Use sentence-style capitalization in the title of a group box. For more information on this style, see Use the Right Capitalization Style in Labels and Text.