Panels

A panel is an auxiliary window containing controls, options, or information related to the active document or selection. A panel appears less prominent than a main window, and can behave like a normal window or be configured to float above other open windows—even modal windows. Panels can also adopt a darker, translucent (HUD-style) appearance when the user experience calls for it.

Use a panel to provide quick access to important controls or information related to content. For example, you might use a panel to expose controls or settings that affect the active document window.

Consider alternatives to panels. Since panels take screen space away from content, many apps present auxiliary information and tools less intrusively using popovers, sidebars, split views, and toolbars. For example, Keynote, Numbers, and Pages include formatting panes that are attached as sidebars (which can be quickly hidden and revealed) to document windows.

Title a panel based on its purpose. Use nouns or noun phrases with title-style capitalization. Some common panel titles are Fonts, Colors, and Inspector.

Show and hide panels appropriately. When a document becomes active, bring all of the app’s open panels to the front, regardless of which document was active when the panel was displayed. When an app is inactive, all of its panels should be hidden.

Don’t include panels in the documents list at the bottom of the Window menu. It’s fine to include commands for showing or hiding panels in the Window menu, but panels shouldn’t be listed as documents.

Make sure all panels include a title bar. Even if a panel doesn’t need a title, give it a title bar so the user can drag the panel to reposition it onscreen.

In general, disable the Minimize button on a panel. A panel shouldn’t need to be minimized because it’s only displayed when needed and disappears when the app is inactive. The close button—and in some cases, the zoom button—should be enabled, however.

Refer to panels by title in your interface and user documentation. In menus, include just the panel’s title. For example, Show Fonts, Show Colors, Show Inspector. In documentation, you may need to provide additional context for some windows. For example, the Fonts window, the Colors window. Other windows, like the Inspector may sufficiently stand on their own.

Keep inspector panels up-to-date. An inspector is a type of panel that lets people view and sometimes edit attributes of the currently selected content. Information displayed in an inspector panel should always match the current state of the selected content. If the attributes of the selection change or the user makes a different selection, the inspector should update accordingly.

Consider providing Info windows in addition to inspectors. An Info window is a standard window that displays content attributes (sometimes for multiple items) captured at the time the window was opened. These attributes continue to be displayed even when the selection changes. Unlike inspectors, Info windows appear in the Window menu’s document list, don’t float above other windows, can be minimized, and may remain visible when the app becomes inactive.

For developer guidance, see NSPanel.

HUD-Style Panels

A HUD-style panel—simply known as a HUD—serves the same function as a normal panel, but its appearance is darker and translucent. HUDs are 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 HUD to display inspector information without obstructing too much of the user’s content.

Prefer standard panels. People can be distracted or confused by a HUD when there’s no logical reason for its presence. In general, a HUD should only be used in the following scenarios:

  • In a media-oriented app that focuses on movies, photos, or slides.
  • In an immersive app with a dark interface.
  • When a standard panel would obscure essential content.
  • When the panel is used for making quick adjustments and then dismissed.

Use a combination of standard panels and HUDs when appropriate. If your app focuses on highly visual content only at specific times or only in certain modes, use the panel type that is best suited to the current task and environment.

Don’t switch panel types when your app switches mode. For example, if you use a HUD when your app is in an immersive mode, don’t transform it into a standard panel when your app switches to a nonimmersive mode.

Use simple adjustment controls in HUDs. Avoid controls that require typing text or selecting items because these actions force people to shift attention from content to the panel. Instead, use controls like sliders and steppers because they’re easy to use without focusing on them.

Use color sparingly in HUDs. Too much color in the dark appearance of a HUD can be distracting and lessen the panel’s impact. Often, only small amounts of high-contrast color are needed to enhance the information in a HUD.

To the extent possible, keep HUDs small. HUDs are designed to be unobtrusively useful, so letting them grow too large defeats their primary purpose. Don’t let a HUD obscure the content it adjusts and make sure it doesn’t complete with the content for the user’s attention.

For developer guidance, see NSWindowStyleMaskHUDWindow.