Dialogs
A dialog is a window designed to elicit a response from the user. Many dialogs—the Print dialog, for example—permit the user to provide many responses at one time.
An alert is a dialog that appears when the system or an application needs to communicate information to the user. Alerts provide messages about error conditions or warn users about potentially hazardous situations or actions.
For information about using the keyboard to interact with dialogs, see “Keyboard Focus and Navigation.”
For specific design information on how to lay out dialogs, see “Layout Examples.”
In this section:
Types of Dialogs and When to Use Them
Dialog Appearance and Behavior
Find Windows
Preferences Windows
The Open Dialog
Dialogs for Saving, Closing, and Quitting
The Choose Dialog
The Print Dialog
Types of Dialogs and When to Use Them
Mac OS X applications can use these types of dialogs:
Modeless. A modeless dialog enables users to change settings in a dialog while still interacting with document windows; the Find window in many word processors is an example of a modeless dialog. Most modeless dialogs include only the close button title-bar control, because users usually interact briefly with a modeless dialog and then close it, they do not need to zoom it or minimize it.
Document modal. A document-modal dialog prevents the user from doing anything else within a particular document. The user can switch to other documents in the application and to other applications. Document-modal dialogs should be sheets, which are discussed in “Sheets (Document-Modal Dialogs).”
Application modal. An application-modal dialog prevents the user from doing anything else within the owner application, although the user can switch to another application. Most application-modal dialogs do not have the standard title bar controls (close, minimize, zoom); the user dismisses these dialogs by clicking a push button, such as OK or Cancel. Application-modal dialogs that appear as the result of the user choosing a command, such as the Open dialog in Figure 14-55 should display a title that matches the command.
An alert can be document modal or application modal. If the error condition or notification applies to a single document, the alert should be document modal (that is, a sheet). See the Save Changes alert in Figure 14-46 for an example. If the alert applies to the state of the application as a whole, or to more than one document or window belonging to that application, the alert should be application modal. Both the Review Changes alert for multiple unsaved documents (Figure 14-60) and the Save Changes alert for applications that are not document-based (Figure 14-59) are application modal.
Sheets (Document-Modal Dialogs)
A sheet is a modal dialog attached to a particular document or window, ensuring that the user never loses track of which window the dialog applies to. Because a sheet is attached to the window from which it emerges, a sheet does not have its own title. Figure 14-46 shows an example of a sheet.
The ability to keep a dialog attached to its pertinent window helps users take full advantage of the Mac OS X window layering model (see “Window Layering”). Sheets also allow users to perform other tasks before dismissing the dialog, with no sense of the system being “hijacked” by the application.
Lay out sheets as you would any other dialog in Mac OS X. For guidelines on laying out a dialog, see “Positioning Regular-Size Controls in a Window Body.”
Sheet Behavior
Sheets are displayed as an animation that appears to emerge from the window’s title bar. When a sheet opens on a window near the edge of the screen and the sheet is wider than the window it’s attached to, the sheet moves the window away from the edge; when the sheet is dismissed, the window returns to its previous position.
Only one sheet may be open for a window at any one time. A sheet prevents any other operation on that window until the sheet is dismissed. If, when the user responds to a sheet, another sheet for that document must open, the first sheet closes before the second one opens.
A sheet on an active document window should cover (appear on top of) any active panels (if necessary). However, if the user leaves a sheet open and clicks another document in the same application, the inactive window and its sheet should go behind any open panels.
In an application that allows multiple windows for the same document (so that the user can see different parts of a document simultaneously), a sheet is not appropriate. Use an application modal dialog in this situation to make it clear that changes to one window affect other windows in the application.
In an application that displays multiple documents in a single window at different times, such as in a tabbed browser, a sheet is appropriate even though it applies to only the current document in the view. This is because, in a single-window situation, the user can’t move the view and its sheet aside to handle later when choosing to view a different document. Rather, the user in effect dismisses the view’s contents when choosing to view a different document. The user should therefore dismiss the sheet on the current view before selecting a different document.
When to Use Sheets
Use sheets for dialogs specific to a document when the user interacts with the dialog and dismisses it before proceeding with work. Here are some examples of when to use sheets:
A modal dialog for an activity that is specific to a particular document, such as saving or printing.
A modal dialog that is specific to a single-window application that does not create documents. A single-window utility program might use a sheet to request acceptance of a licensing agreement from the user, for example.
Other window-specific dialogs that are typically dismissed by the user before proceeding. Use a sheet when a dialog benefits from being attached to the window as a modal dialog, even if you might otherwise design the dialog as a modeless dialog.
When Not to Use Sheets
Don’t use sheets in the following situations:
For dialogs that apply to several windows. Use sheets only when a particular dialog is associated with only one window.
For modeless operations in which the dialog should be left open to allow the user to observe the effects of changes applied. Such tasks (find and replace operations, for example) are better suited to modeless dialogs, panels, or drawers.
On a window that doesn’t have a title bar. Sheets should emerge from a definite visual edge.
When the user will need information in the window that is essential to filling in requested information in the dialog.
Alerts
Alerts display messages to inform users of situations that are notable or potentially dangerous. Alerts are modal dialogs. For an alert that applies to one document or in single-window applications, display the alert as a sheet. See “When to Use Sheets” for guidelines.
Figure 14-47 shows the elements of an alert.
See “A Standard Alert” for more information on laying out alerts.
The Elements of an Alert
An alert should contain only the following elements:
Alert message text. This text, in emphasized (bold) system font, provides a short, simple summary of the error or condition that summoned the alert. This should be a complete sentence; often it is presented as a question. See “Writing Good Alert Messages” for more information.
Informative text. This text appears in the small system font and provides a fuller description of the situation, its consequences, and ways to get out of it. For example, a warning that an action cannot be undone is an appropriate use of informative text.
Buttons for addressing the alert. Button names should correspond to the action the user performs when pressing the button—for example, Erase, Save, or Delete. The rightmost button in the dialog, the action button, is the button that confirms the alert message text. The action button is usually, but not always, the default button. (Note that in Cocoa methods, the rightmost button is always referred to as the default button even though it might not be.) For more information, see “Dismissing Dialogs.”
The application icon. Because of the Mac OS X window layering model (described in “Window Layering”), an icon is necessary to make it clear to the user which application is displaying the alert.
In rare cases, you may want to display a caution icon in your alert, badged with the application icon as shown in Figure 14-48. A badged alert is appropriate only if the user is performing a task, such as installing software, and a possible side effect of that task would be the inadvertent destruction of data. Don’t use a caution icon for tasks whose only purpose is to overwrite or remove data, such as Save or Empty Trash; too-frequent use of the caution icon dilutes its significance.
Writing Good Alert Messages
A good alert message states clearly what caused the alert to appear and what the user can do about it. Express everything in the user’s vocabulary. Figure 14-49 shows an example of an alert message that provides little useful information.
You could improve this message by describing the problem in the user’s vocabulary as shown in Figure 14-50.
To make the alert really useful, provide a suggestion about what the user can do about the current situation. Even if the alert serves as a notification to the user and no further action is required, provide as much information as needed to describe the situation. Figure 14-51 shows the alert with additional information.
Dialog Appearance and Behavior
When appropriate, your application’s dialogs should display default values for controls and text fields so the user can verify information rather than generate it from scratch.
Display a selection or an insertion point in the first location—a text entry field or a list, for example—that accepts user input.
When it provides an obvious user benefit, static text in a dialog should be selectable. For example, a user should be able to copy an error message, a serial number, or IP address to paste elsewhere.
In dialogs that display columns and are user resizable, such as the Open dialog, as the dialog is made bigger, the columns should grow and additional columns should appear. All other elements should remain the same size and be anchored to the right, center, or left side of the dialog.
Accepting Changes
In general, all changes a user makes in a dialog should appear to take effect immediately. There are three possible opportunities for data validation in a dialog:
When the user types data
When the user moves out of a data field (by pressing Tab, for example)
When the user clicks a button to apply changes
It is your responsibility to make the three states as clear as possible to the user. For example, checkboxes and radio buttons update immediately and display the appropriate results.
You need to decide when your application does error checking of user input. Possible approaches are to:
Evaluate the input and check for errors as the user tabs from one field to the next. The drawback is that it isn’t clear to the user that the changes are taking effect as he or she tabs among items. The user doesn’t click a button, and so isn’t aware of completing an action.
Save user input in a queue and apply it when the user clicks a button, closes the dialog, or switches to another application. If your application waits to check user-input errors until the user tries to dismiss the dialog, you may have to present an alert, thereby forcing the user to revisit the dialog. If you do error checking as the user enters input, it takes more time up front, but you can warn the user immediately when invalid data is entered.
In most cases, validating input after each keystroke is annoying and unnecessary. It’s better to design your interface to automatically disallow invalid input. For example, your application could automatically convert lowercase characters to uppercase when appropriate.
In addition to error checking, you need to decide when to apply user input. In some cases, changes can take effect immediately—for example, View Options for Finder windows. In other cases, it may be appropriate to wait until the user performs an action, such as clicking an Apply button.
In a dialog that has multiple panes (selected by buttons, tabs, or a pop-up menu), avoid validating data when a user switches from one pane to another.
Finally, you need to determine whether your application should automatically perform an operation based on user input or whether the user should initiate the operation—for example, by clicking a button. It’s acceptable to automatically perform an operation that completes quickly and returns user control within a couple of seconds. For an operation that takes a longer time to execute, it’s best to warn the user of the estimated time required and let the user initiate it.
Dismissing Dialogs
The buttons at the bottom right of a dialog all dismiss the dialog. A button that initiates an action is furthest to the right. This action button confirms the alert message text. The Cancel button is to the left of this button.
If there’s a third button for dismissing the dialog, it should go to the left of the Cancel button. If the third button could result in data loss—Don’t Save, for example—position it at least 24 pixels away from the “safe” buttons (Cancel and Save, for example).
A button that affects the contents of the dialog itself, such as Reset, should have its left edge aligned with the main dialog text or if there is a Help button, 12 pixels to the right of it.
Usually the rightmost button or the Cancel button is the default button. The default button should be the button that represents the action that the user is most likely to perform if that action isn’t potentially dangerous. A default button has color and pulses to let the user know that it is the default. When the user presses the Enter key or the Return key, your application should respond as if the user clicked the default button.
Don’t use a default button if the most likely action is dangerous—for example, if it causes a loss of user data. When there is no default button, pressing Return or Enter has no effect; the user must explicitly click a button. This guideline protects users from accidentally damaging their work by pressing Return or Enter. You can consider using a safe default button, such as Cancel. Figure 14-48 shows an example of a safe default button.
Don’t use a default button if you use the Return key in text entry boxes. Having two behaviors for one key can confuse users and make the interface less predictable.
In addition to the action button or buttons, it’s a good idea to include a Cancel button. This button returns the computer to the state it was in before the dialog appeared. It means “forget I mentioned it.” Always map the keyboard shortcut Command-period and the Esc (Escape) key to the Cancel button. These keyboard equivalents, along with Return and Enter, are accelerator keys and serve the purpose of letting the user respond quickly to a dialog or an alert. In general, it’s not a good idea to assign other keyboard shortcuts to buttons. If you find it useful to assign keyboard shortcuts to some buttons that are used very often in your application, be sure to follow the guidelines in “Keyboard Shortcuts.”
In some circumstances, it’s appropriate to implement an Apply button—for example, to permit a user to see the effect of multiple text attributes before committing to them. In cases like these, clicking Cancel should undo any of the applied changes. Cancel should never silently commit the changes the user previewed by clicking Apply. For more guidelines on using an Apply button, see “Providing an Apply Button in a Dialog.”
Providing an Apply Button in a Dialog
You may choose to provide an Apply button in a dialog that displays multiple settings that affect the user’s view of data. An Apply button should allow a user to preview the effect of the selected settings without committing to the changes. Be cautious about using an Apply button for operations that take a long time to implement or undo; it might not be obvious to users that they can interrupt or reverse the process. Save dialogs or dialogs that allow users to make changes that can’t be previewed easily should not include an Apply button.
Clicking the Apply button does not dismiss the dialog because the user must decide whether to accept the previewed changes (by clicking OK) or to reject them (by clicking Cancel). Do not use the Apply button as another OK button—when the user dismisses the dialog without clicking OK, all previewed changes should be discarded.
Expanding Dialogs
Sometimes you need to provide the user with additional information or functionality in a dialog, but you don’t want to display it all the time. To do this, you use one of the disclosure controls to expand the dialog and reveal the additional information or capability to the user.
If you want to allow the user to view details that elaborate on the primary information in a dialog, you use a disclosure triangle (note that disclosure triangles are also used in hierarchical lists). The disclosure triangle expands the dialog, revealing additional information and, if appropriate, extra functionality. An example of a dialog expanded by a disclosure triangle is shown in Figure 15-76. For more information about how to use a disclosure triangle in your dialog, see “Disclosure Triangles.”
If you want to provide the user with additional choices directly related to the selections offered in a pop-up or command pop-down menu in a dialog, you use a disclosure button. The disclosure button expands the dialog to reveal selections in addition to those listed in the pop-up or command pop-down menu. An example of a dialog expanded by a disclosure button to reveal additional choices is shown in Figure 14-58. For more information about how to use a disclosure button in your dialog, see “Disclosure Buttons.”
Find Windows
A Find window is a modeless dialog that opens in response to the Find command to provide an interface for specifying items to search for. Its appearance can vary depending on the needs of your application, but if your application handles text you might want to make your Find window similar to the one shown in Figure 14-53 to provide a consistent user experience.
Find windows are useful in document-creation applications, because users can use one Find window to search for a term in several different documents. If your application is not document-based or if it is a single-window application, however, you might instead choose to offer find or searching functionality in a scope bar. A scope bar is attached to a window and provides both search and filtering capabilities to users. Figure 14-19 shows a scope bar in Safari. For more information about scope bars and how to use them in your application, see “Scope Bars.”
Preferences Windows
A preferences window is a modeless dialog that contains settings the user changes infrequently. In general, the user opens a preferences window to change the default way an application displays an item or performs a task, closes the window, and expects the new settings to have taken effect. For some guidance on how to provide preferences in your application, see “Preferences.”
Often, an application needs to provide a set of preferences for each of several different categories of functionality. For example, Safari allows the user to set preferences for bookmarks, webpage appearance, RSS display, and security measures, among other things. Because these categories are unrelated to each other, it would be confusing to display settings for all of them in one pane. Therefore, Safari (and many other applications) provides a preferences window with a toolbar that contains a toolbar item for each category. When the user clicks a toolbar item, the window displays a pane that contains the settings associated with that item. Figure 14-54 shows the General pane of Safari preferences.
If you choose to create a preferences window that uses a toolbar to switch among different categories of settings, make sure the toolbar is not customizable. This is because a toolbar in a preferences window does not provide a shortcut to frequently used commands, but acts as a convenient way to group settings. In addition, you should remove the show/hide toolbar control in your preferences window toolbar (you can see this control in Figure 14-4). This is because there is no need to hide the toolbar in a preferences window (hiding it would also hide all but the currently selected collection of settings), and because novice users might mistakenly click the toolbar control when they mean to click the close button.
A preferences window should not include a resize control. In general, preferences windows do not need to display active minimize or zoom buttons. Remember that preferences windows are intended to provide users with a place to make adjustments to the way an application behaves, so there’s seldom a need for preferences windows to be resized or to remain open for a long time.
If you have changeable panes in your preferences window, the title of the window should be the title of the currently selected pane. For example, the title of the window shown in Figure 14-54 is “General” because the currently selected toolbar icon is labeled “General.” (If your preferences window does not contain additional panes, the title should be “Application Name Preferences”.) In addition, a changeable-pane preferences window should remember which pane the user selected the last time the window was open.
The menu item to open your preferences window should be in the application menu and be labeled Preferences. Use Command-comma for the keyboard shortcut.
The Open Dialog
The Open dialog appears when the user chooses the Open command or presses Command-O. The Open dialog is application modal (that is, the user can switch to other applications before closing the Open dialog).
If you implement an Open command, you should also include an Open Recent command so users can open recently opened documents without going through the dialog. Figure 14-55 shows an example of an Open dialog.
The Open dialog contains these elements:
A default title (“Open”); you should add your application’s name to the Open dialog title—”TextEdit: Open,” for example.
Back and forward buttons to navigate back and forth between selections made in list or column view.
A pop-up menu that contains common places a user might save things and Recent Places (the five most recent folders the user opened or saved documents to). Your application specifies the default location, typically one of the predefined folders in the user’s home folder. If the user selects another folder, the dialog should “remember” the user’s selection the next time the dialog appears.
A source list that mirrors the Finder sidebar.
A column or list view for navigating the file system.
A Cancel button and an Open (default) button.
A resize control in the lower-right corner.
The ability for expert users to specify a pathname by pressing Command-Shift-G. (Note that the pathname separator is the “/” character.)
You can extend the Open dialog as appropriate for your application as illustrated in Figure 14-56. You might, for example, include a pop-up menu allowing users to filter the type of files that appear in the list. Items that do not meet the filtering criteria would appear dimmed. The system creates a list of native file types supported by the application to populate the menu. You can supplement this list with custom types and specify the default to show when the dialog opens. You should include an All Applicable Files item, but it does not have to be the default.
Open dialogs should support document preview. In addition, an Open dialog can support multiple selection if your application allows more than one document to be open at a time.
Dialogs for Saving, Closing, and Quitting
This section describes the standard dialogs that you use when a user is saving a document for the first time, closing a document, or quitting an application.
Save Dialogs
An application that saves the contents of individual windows—which would be most text and graphics applications—should use document-specific sheets for its Save dialogs. In a Save dialog, users can save a document for the first time or change the name or location (or both) of a previously saved document.
The Save dialog has two states: minimal and expanded. Clicking the disclosure button toggles between these states. If the user changes the state, the next Save dialog should open in the selected state.
Your application should pass in a filename extension as part of every filename. Users can control its visibility using the Hide Extension checkbox in the expanded Save dialog; see Figure 14-30. Existing documents do not get extensions added to or removed from their filenames unless the user chooses Save As and changes the setting in the Save dialog.
The Minimal Save Dialog
In the minimal Save dialog (shown in Figure 14-57), users can specify a name and choose a frequently accessed location to store a document.
The minimal Save dialog contains these elements:
Save As text field for the document name. Expert users can enter pathnames by pressing Command-Shift-G. (Note that the pathname separator is the “/” character.)
If the document has not been saved previously, your application should put the default name (such as “untitled”) in this field, and the filename should be selected. If the user has chosen to make the filename extension visible, the extension is not selected.
If the document has been saved previously and the user chooses Save As, the Save dialog should open with the document name highlighted in the Save As field. The filename extension (if it is visible) is not selected.
Where pop-up menu, containing mounted volumes, the folders in the Finder sidebar, and Recent Places (the five most recent folders the user opened or saved documents to). Your application specifies the default location, typically the predefined Documents folder in the user’s home folder. If the user selects another folder, the dialog should “remember” the user’s selection the next time the dialog appears.
A Save button (default).
A Cancel button. Dismisses the dialog and returns the application to its previous state.
A disclosure button. Clicking it displays the expanded Save dialog. (For more information about how to use disclosure buttons, see “Disclosure Buttons.”)
Any custom elements you add go between the Where pop-up menu and the buttons at the bottom of the dialog.
The Expanded Save Dialog
In contrast with the minimal Save dialog, the expanded Save dialog lets users save documents in locations other than those available in the minimal Save dialog’s Where pop-up menu. An example of the expanded Save dialog is shown in Figure 14-58.
In addition to the items in the minimal Save dialog, the expanded Save dialog displays the following:
Back and forward buttons to navigate back and forth between selections made in the list or column view.
A source list that mirrors the Finder sidebar.
A column or list view for navigating the file system.
A File Format (or Format) pop-up menu, which displays a list of file formats from which the user can choose.
A New Folder button, which displays an application-modal dialog that asks the user to name the new folder, and then creates it.
A “Hide extension” checkbox, which allows the user to control whether or not the filename’s extension (
.jpg,for example) is visible. The “Hide extension” checkbox should be selected as the default (that is, filename extensions should not appear in user-visible filenames unless the user requests them).If the user changes the state of the checkbox for a particular document, the next new document should match the last user-selected state, even after the user quits and reopens the application. The filename in the Save As field updates in real time as the checkbox is selected or deselected.
If you add other elements to customize the Save dialog, they should appear above the Cancel and Save buttons. When the dialog is expanded, custom elements should appear between the file-system browser and the push buttons.
In default keyboard navigation mode, pressing Tab in the expanded Save dialog shifts the keyboard focus from the Save As text field to the source list, to the visible columns, and then back to the text field.
Closing a Document With Unsaved Changes
When the user attempts to close a document that has unsaved changes, present a Save Changes alert. An application that saves the contents of individual windows—such as most text and graphics applications—should use document-specific sheets, like the one shown in Figure 14-46 for its Save Changes alert.
In an application that can display multiple views of the same file, if the user chooses the Close File command instead of Close Window, you should use an application-modal dialog instead of a sheet. This emphasizes the fact that the user’s actions affect the file as a whole, not just the portion displayed in the current view. In this situation, change the word “document” in the Save Changes alert message to the word “file”. After the user clicks Save or Don’t Save, close all open views of the file.
When a Save Changes sheet is open, the document’s close button and the Close command in the File menu are unavailable; the user can’t close the document until the Save Changes sheet is addressed.
Attempting to Save a Locked or Read-Only Document
If the user edits a locked or read-only document and then quits the application or chooses Save, do not display the standard Save Changes alert. Instead, display a sheet explaining that because the document is read-only, it cannot be saved. The sheet should then offer the user the options of saving a copy, rejecting the changes, or continuing to view or edit the document.
Saving Documents During a Quit Operation
Users can interrupt a quit operation with documents still unsaved. For example, if a user chooses Quit and a save alert (a sheet) opens for a document, the user can work on other documents or switch to another application without addressing the save alert.
When a user quits an application in which all open documents have been saved, all documents close immediately and the application quits.
Quitting an Application That Is Not Document-Based
When a user attempts to quit an application that is not document-based but that has many windows whose contents are saved simultaneously, present an application-modal Save Changes alert, such as the one shown in Figure 14-59.
Quitting an Application With Multiple Unsaved Documents Open
When a user attempts to quit a document-based application and there is more than one document with unsaved changes open, present an application-modal Review Changes alert, such as the one shown in Figure 14-60.
Figure 14-60 The Review Changes (application-modal) alert that appears when the user quits with more than one unsaved document open
The appropriate action for each button is as follows:
Discard Changes. Closes all documents without saving changes and quits the application.
Cancel. Cancels the Quit command.
Review Changes. All open documents (including those minimized in the Dock) come forward, with the unsaved documents on top. The active document presents a Save Before Quitting alert. If the user clicks Save, the Save dialog appears (if the document has not previously been saved). If the user clicks Don’t Save, the next unsaved document comes forward with its Save Before Quitting alert. If the user dismisses the last Save Before Quitting alert with Save or Don’t Save, all documents close and the application quits.
During the review, if the user activates another unsaved document, it should come forward with its Save Before Quitting sheet open. Save Before Quitting sheets on other documents remain open. During the review, if the user activates a saved document, the review process continues when the next unsaved document becomes active.
If, in the midst of a quit operation, the user clicks the application icon in the Dock or chooses Bring All to Front from the Window menu, documents should appear in this order: documents with open sheets on top, unsaved documents next, and then saved documents.
At any time during the review process, the user can click Cancel to stop the quit operation. If the user initiates a Quit command during the review process, the process begins again with the application-modal alert shown in Figure 14-60.
Saving a Document With the Same Name as an Existing Document
If the user types the name of a document that already exists in the same location into the Save As field of a Save dialog, and then clicks Save, present an application-modal alert in which the user can confirm whether or not to replace the previous document.
The Choose Dialog
A Choose dialog lets a user select an item as the target of a task. For example, when a user attempts to open a broken alias, the Fix Alias dialog lets the user choose another item for the alias to open. An application can have more than one Choose dialog, but only one can be open at a time. In some situations, it may be appropriate for a Choose dialog to be a sheet. Figure 14-62 shows an example of a Choose dialog.
A Choose dialog:
Can be opened by various commands
Can support multiple selection
Supports document preview
Can be resized with the resize control in the lower-right corner
Can include a Show pop-up menu, which allows the user to filter the type of files that appear in the list. Items that do not meet the filtering criteria appear dimmed. The system creates a list of native file types supported by the application to populate the menu. You can supplement this list with custom types and specify the default to show when the dialog opens. You should include an All Applicable Files item, but it does not have to be the default.
If the dialog is not a sheet, the dialog’s default title is “Choose,” but you should change it to include the name of the task. For example, if the command that brings up the dialog is Choose Picture, the dialog should be titled “Choose Picture.” Also include some instructional text at the top, such as “Choose a picture to display in the background of ‘Documents.’” If it’s helpful, also change the Choose button to something more specific.
The default location is the user’s home folder. If the dialog is targeted to volumes only, the default location is the user’s directory. Files and folders not appropriate for the target selection should be dimmed.
Note: Recent Places (in the Where pop-up menu of a Save dialog) does not record folders selected in Choose dialogs.
The Print Dialog
In addition to printing, the minimal Print dialog lets users choose a printer and printer settings, save, mail, or fax a document in the PDF or PostScript formats, and preview a document before printing. The expanded Print dialog adds printing-specific settings, such as number of copies, page range, paper settings, and layout.
Print Dialog
In the Print dialog, user options are provided via the features pop-up menu, which displays panes drawn and controlled by printing dialog extensions (PDEs). PDEs are provided by the operating system, printer modules, and applications. Apple provides a number of printing panes. The standard Print dialog is shown in Figure 14-63.
Options for choosing paper type and print quality are displayed through the features pop-up menu. The ability to save the document in PDF or PostScript format, fax the document, or save it to iPhoto or other applications is available in the PDF pop-down menu in the lower left. You can create custom print panes by following the interface guidelines provided throughout this document and the layout guidelines described in “Positioning Regular-Size Controls.” Here are some specific guidelines to keep in mind if you implement custom printing features:
Choose a menu item name that doesn’t conflict with menu items already in the features pop-up menu.
The menu item (the pane name) should help users easily determine the options the pane contains.
Make sure the features you implement are appropriate for your application. For example, an option to print in reverse order should be provided by the operating system, not by your application. (Implementing this feature requires the application to know the hardware’s capabilities.)
Make interdependencies among options clear to users. For example, if a user selects double-sided printing, the option to print on transparencies should become unavailable.
Separate more advanced features from frequently used features. When the user chooses to display the advanced features, there should be an “advanced options” title above the advanced controls.
Provide visual feedback (such as the preview in the Layout pane of the Print dialog) when appropriate. A thumbnail showing the effect of changing a tone control, for example, helps users determine desired settings.
Save a user’s printing preferences for a document, at least while the document is open. Provide a way for users to save custom settings.
Page Setup Dialog
The Page Setup dialog provides a way for users to set the scaling and orientation options for a document based on the intended output paper size and the printer. Save the settings in this dialog with the document. Figure 14-64 shows an example of a page setup dialog.
Last updated: 2008-01-15
  |
||
|
|
|
|
| ||
Get information on Apple products.
Visit the Apple Store online or at retail locations. 1-800-MY-APPLE Copyright © 2007 Apple Inc. All rights reserved. | Terms of use | Privacy Notice |