A panel is an auxiliary window that contains controls and options that affect the active document or selection. An app-wide toolbar in its own window is also called a tool panel or, less frequently, a tool palette.
Panels are either app-specific or systemwide.
App-specific panels float on top of the app’s windows and disappear when the app is deactivated. For example, the Preview Inspector panel is visible only when a Preview window is main or key.
Systemwide panels, such as the Fonts window shown here, float on top of all open windows. (To learn more about the Fonts window, see Colors and Fonts Windows.)
In general, use a standard panel. For some apps, such as highly visual, immersive apps, translucent panels (sometimes called HUD panels) can be appropriate, but for most apps, standard panels are best. Users don’t expect to see a translucent panel unless it contains image adjustment tools or it is displayed by an immersive app that uses a dark UI. To learn more about when translucent panels are appropriate, and how to design one, see Translucent Panels.
Consider using a panel to give users easy access to important controls or information that directly affects their task. For example, you can create a modeless panel, such as a tools panel, to offer controls or settings that affect the active document window. Because panels take up screen space, however, don’t use them when you can meet the need by using a popover, a modeless dialog, or by adding a few appropriate controls to a toolbar.
Hide and show panels appropriately. When a user makes a document active, all of the app’s panels should be brought to the front, regardless of which document was active when the user opened the panel. When an app is inactive, its panels should be hidden.
Don’t list panels in the Window menu as documents, but you can put commands to show or hide all panels in the Window menu.
Make sure a panel includes a title bar. Even if a panel doesn’t need a title, give it a title bar so that users can drag the panel.
Avoid including an active minimize button in a panel. Users shouldn’t need to minimize a panel, because it’s displayed only when needed and disappears when its app is inactive. Instead, include the close and zoom buttons or, more commonly, only the close button.
An inspector is a panel that allows users to view the attributes of a selection. Inspectors (sometimes called inspector windows) can also provide ways to modify these attributes.
Modern macOS apps often present inspector information within a main window instead of a separate inspector window. For example, Keynote displays multiple inspector panes within the main window.
Ensure that an inspector updates dynamically based on the current selection. Users expect an inspector’s view to always be up to date. Similarly, they expect the changes they make in an inspector to immediately affect their content. Contrast this behavior with that of an Info window, which shows the attributes of the item that was selected when the window was opened, even after the focus has been changed to another item. Also, an Info window is not a panel; it is listed in the app’s Window menu, and it does not hide when the app becomes inactive.
Consider providing both inspectors and Info windows in your app. In some cases users want one window in which context changes with each new item they select (an inspector), and in other cases they want to see the attributes of more than one item at the same time (a set of Info windows). Note that users can open multiple inspector windows and Info windows in the same app at the same time.
The behavior of a translucent panel is similar to the behavior of a standard panel, but its appearance is designed to complement apps that focus on highly visual content or that provide an immersive experience, such as a full-screen slide show. For example, QuickTime Player uses a translucent panel to display inspector information without obstructing too much of the user’s content.
Have a good reason to use a translucent panel instead of a standard panel. Users can be distracted or confused by a translucent panel when there is no logical reason for its presence. In general, use translucent panels only when at least one of the following statements is true:
Your app is media-oriented, that is, focused on movies, photos, or slides.
Users use your app in a dark environment or in an immersion mode (frequently, this type of app also uses a dark, custom UI).
Users make only quick adjustments in the panel and dismiss it quickly.
A standard panel would obscure the content that users need to adjust.
Use a combination of standard and translucent panels, if appropriate. If your app focuses on highly visual content only at specific times or only in some modes, use the panel type that is best suited to the current task and environment.
Don’t change a panel’s type when your app changes its mode. For example, if you use a translucent panel when your app is in an immersive mode, don’t transform it into a standard panel when your app switches to a nonimmersive mode.
As much as possible, use simple adjustment controls in a translucent panel. In particular, avoid using controls that require users to type or to select items, because these controls force users to shift their attention from their content to the panel. Instead, consider using controls such as sliders and steppers, because they’re easy for users to use without focusing on them.
Use color sparingly. In the dark UI of a translucent panel, too much color can lessen its impact and distract users. Often, you need only small amounts of high-contrast color to enhance the information you display in a translucent panel.
In general, keep translucent panels (and their contents) small. Translucent panels are designed to be unobtrusively useful, so allowing them to grow too big defeats their primary purpose. Don’t let a translucent panel obscure the content that the user is trying to adjust, and don’t let it compete with the content for the user’s attention.
The About Window
An About window (sometimes called an About box) is an optional window that displays your app’s version and copyright information. The Safari About window is shown here.
Unlike other windows, an About window combines some of the behaviors of panels and windows: Like a panel, an About window is not listed in the app’s Window menu, and like a window, it remains visible when the app is inactive.
Make an About window modeless so the user can leave it open and perform other tasks in the app. If you decide to provide an About window, be sure that it:
Has a title bar with no title
Includes the close button as the only active window control
Displays your app icon
Includes the full app name and version number, which should be the same as the version number displayed by the Finder
Includes copyright information, technical support contact information, and a brief description of what the app does
Use buttons in an About window if you want to give users a way to contact you. For example, you might provide a button that opens your website in a browser window or opens a blank email message that is preaddressed to you. Of course, it’s best to provide most of your company contact information in the first page of your help documentation. For more information on Help menu items, see The Help Menu.
Consider putting branding elements, such as logos or slogans, in your About window. An About window is the appropriate place for these elements because users expect it to provide information about your company and product. Avoid putting such elements in document windows and dialogs.