|< Previous PageNext Page >|
Every document, application, and utility window should have, at a minimum:
In addition, a standard document window has the following attributes that an application or utility window might not have:
These elements are shown in Figure 8-2.
Figure 8-2 Standard window parts
The Title Bar
Brushed Metal Windows
All windows should have a title bar even if the window doesn’t have a title (which should be a very rare exception).
A document window should display the name of the document being viewed. Application windows display the application name. Utility windows display a descriptive title appropriate for that window. If the contents of the window can change, it might be appropriate to change the title to reflect the current context. For example, in the Keynote inspector, the title of the window changes to reflect which pane has been selected.
If you need to display more than one item in the title, separate the items with an em dash (—) with space on either side. For example, the main viewer window of Mail displays the currently selected message mailbox and the selected folder, if any. Note that if a message is viewed in its own window, the message title is displayed.
Don’t display pathnames in window titles. When displaying document titles, use the display name and show the extension if the user has selected to show extensions. See Apple Software Design Guidelines for more information.
Document and application windows always display active close and minimize buttons. (See “Closing Windows” and “Minimizing and Expanding Windows” for details on what the close and minimize buttons do.) Include the zoom button if the window can be adjusted in size. Information on how the zoom button works is in “Resizing and Zooming Windows”.
Utility windows always display an active close button but never an active minimize button.
If buttons are not active, they should at least all be present in an inactive state. The exception is utility windows, where it is acceptable to display only one button, the close button.
Alerts and modal dialogs do not include any of these buttons.
The title bar should include a toolbar control if a toolbar is available in the window (see “Toolbars”).
Figure 8-3 Title bar buttons for standard windows
When a document has unsaved changes, the close button should display a dot.
Figure 8-4 The close button in its unsaved changes state
Carbon: Display the dot with the SetWindowModified function.
Cocoa: The dot appears automatically if the application is NSDocument-based; otherwise, use the setDocumentEdited: method of the NSWindow class.
Document windows include a proxy icon in the title bar after a document is saved for the first time. After pressing a proxy icon for a couple of seconds, users can manipulate it as if they were manipulating the corresponding file-system object. For example, you can attach a document to an email message by dragging its proxy icon into the email message.
Figure 8-5 A proxy icon being dragged to another application
A proxy icon appears in its normal state as long as the state of the document and the file-system object are the same. When a document has unsaved changes, its proxy icon appears dimmed. Note the difference between the proxy icon in the document with unsaved changes versus the document with saved changes in Figure 8-6.
Figure 8-6 Proxy icons in documents with saved and unsaved changes
Command-clicking the title or the proxy icon displays a pop-up menu illustrating the document path.
Figure 8-7 A document path pop-up menu, opened by Command-clicking the proxy icon
Toolbars are useful for giving users immediate access to the most frequently used commands. Any item in a toolbar should also be available as a menu command. An application-wide toolbar in its own window is also called a tool palette; for more information, see “Utility Windows”. This section describes toolbars that are part of a window with other content.
The set of toolbar items you provide should fit in the default window size; users should be able to customize which items appear in the toolbar and in what order. As the default, a toolbar should display icons with text labels; users should be able to change the display to icons only or text only. You can provide these options with a Customize Toolbar command in the View menu.
When the user has selected an item in the toolbar, it should either maintain its pressed state to indicate that item is selected, or the icon itself should change to indicate the current state.
If your application uses toolbars as part of a window with other content, include a control in the window’s title bar for showing and hiding the toolbar, as shown in Figure 8-8. You should also put commands for showing and hiding the toolbar in the View menu (see “The View Menu”).
Figure 8-8 The toolbar control
For information about designing icons for toolbars, see “Toolbar Icons”.
Carbon: Create a toolbar with the HIToolBarCreate function. See Using HIToolbar in Carbon User Experience Documentation for more information.
Cocoa: Create a toolbar with the NSToolbar class.
A drawer is a child window that slides out from a parent window and that the user can open or close (show or hide) while the parent window is open. A drawer should contain frequently accessed controls that don’t need to be visible at all times. A drawer’s contents should be closely related to the contents of its parent window. A drawer automatically inherits the brushed metal appearance if its parent window is brushed metal (see “Brushed Metal Windows”.
Figure 8-9 An open drawer next to its parent window
Carbon: Create a drawer using the CreateNewWindow function with the kDrawerWindowClass constant, and associate it with its parent window using SetDrawerParent. The Carbon Window Manager also provides other drawer-related functions.
Cocoa: Drawers support is available via the NSDrawer class.
Use drawers only for controls that need to be accessed fairly frequently but that don’t need to be visible all the time. (Contrast this criterion with a utility window, which should be visible and available whenever its main window is in the top layer.) Some examples of uses of drawers include access to favorites lists, the Mailbox drawer (in the Mail application), or browser bookmarks.
Although a drawer is somewhat similar to a sheet in that it attaches to a window and slides out, the two elements are not interchangeable. Sheets are primarily intended to replace modal dialogs, as described in “When to Use Sheets”, whereas drawers provide additional functionality. When a sheet is open, it is the focus of the window and it obscures the window contents; when a drawer is open, the entire parent window is still visible and accessible.
Some uses of a drawer are similar to uses of a source list. See “Source Lists” for information on when to use a source list.
The user shows or hides a drawer, typically by clicking a button or choosing a command. If a drawer contains a valid drop target, you may also want to open the drawer when the user drags an appropriate object to where the drawer appears.
When a drawer opens or closes, it appears to be sliding from behind its parent window, to the left, right, or down. You should ensure that a parent window’s default position allows its drawer to open fully without disappearing offscreen. If a user moves a parent window to the edge of the screen and then opens a drawer, it should open on the side of the window that has room. If the user makes a window so big that there’s no room on either side, the drawer opens off the screen.
To support the illusion that a closed drawer is hidden behind its parent window, an open drawer should be smaller than its parent window. When the parent window is resized vertically, an open drawer resizes, if necessary, to ensure that it does not exceed the height of the parent window. (A drawer can be shorter than its parent window.) The illusion is further reinforced by the fact that the inner border of a drawer is hidden by the parent window and that the parent window’s shadow is seen on the drawer when appropriate.
The user can resize an open drawer by dragging its outside border. The degree to which a drawer can be resized is determined by the content of the drawer. If the user resizes a drawer significantly—to the point where content is mostly obscured—the drawer should simply close. For example, if a drawer contains a scrolling list, the user should be able to resize the drawer to cover up the edge of the list. But if the user makes the drawer so small that the items in the list are difficult to identify, the drawer should close. If the user sets a new size (if that is possible) for a drawer, the new size should be used the next time the drawer is opened.
A drawer should maintain its state (open or closed) when its parent window becomes inactive or when the window is closed and then reopened. When a parent window with an open drawer is minimized, the drawer should close; the drawer should reopen when the window is made active again.
A drawer can contain any control that is appropriate to its intended use. Follow normal layout guidelines, as stated in “Positioning Full-Size Controls”.
Consider a drawer part of the parent window; don’t dim a drawer’s controls when the parent window has focus, and vice versa. When full keyboard access is on, a drawer’s contents should be included in the window components that the user can select by pressing Tab.
A source list is an area of window set off by a movable pane splitter to provide users a way to navigate data. Use a source list when the data presented in it is a primary means of navigating within the application, as in iTunes or the Finder. Users select objects in the source list that they act on in the main part of the window.
Source lists are normally used in application windows, not in document windows. The iTunes playlist, the iPhoto library, and the Finder Sidebar are all examples of source lists.
Figure 8-10 Finder Sidebar as a source list
Do not put controls in a source list other than contextual controls used to organize the data itself. You might include controls below the source list to add, remove, or get information about items in the source list. If you need to add other controls, consider using a drawer instead of a source list.
Windows have two distinct looks in Mac OS X. There is the standard default look of windows, as shown in the examples so far. There is also a brushed metal look available, shown in Figure 8-11. You can use a brushed metal window if your application:
Don’t use the brushed metal look indiscriminately. Although it works well for some types of applications, some applications appear too heavy when using this look. For example, it works well for the iSync application window (see Figure 8-11), but it does not work very well for the TextEdit document window (see Figure 8-12).
Figure 8-11 A brushed metal application window
Figure 8-12 Metal and regular versions of a document window
Use brushed metal window look for the primary application window and other windows that meet the above criteria—for example, the Equalizer window in iTunes. Don’t use it for supporting windows, such as preferences and other dialogs. It is acceptable to have a mix of standard Aqua windows and brushed metal windows within an application, as the Finder does.
Figure 8-13 Mixing standard and brushed metal versions of windows
If a brushed metal window has a drawer or a toolbar, it automatically inherits the brushed metal look.
Users can move metal windows by dragging anywhere on the brushed metal surface (not just the title bar).
Carbon: Use the window type defined in MacWindows.h.
Cocoa: Apply the NSTexturedBackgroundWindowMask to a titled window. Avoid using a borderless window, which doesn’t have rounded corners.
|< Previous PageNext Page >|
Last updated: 2004-05-27