Dialogs are transient windows that your application uses either to communicate something important to the user (for example, that a pending action could cause some data to be lost), or to obtain a specific piece of information from the user (for example, which file to open). Users interact quickly with dialogs and then dismiss them. This chapter covers dialogs in the following sections:
“Types and Modes of Dialogs” discusses the standard types of dialogs, when to use them, and whether they should be modal or not (that is, whether they should prevent the user from doing anything else until the dialog is dismissed).
“Designing Dialogs” discusses general dialog design issues—such as the dialog window decorations, the layout of dialog information, and what the standard actions are (in the form of push buttons). It also covers specific design and content issues for the various types of dialogs listed in the previous section.
“Invoking Dialogs” describes the most common situations that require dialogs and which types of dialogs to use in them.
Dialogs are used to give information to the user or to get information from the user; once they've served their purpose, they go away. Dialogs that give information to the user are instigated by the application; these application-generated dialogs present important messages for the user's immediate attention. Dialogs whose purpose is to get information from the user are displayed as the result of a user action (such as pushing a button or selecting a menu entry). An example of such a user-requested dialog occurs when the user selects “Open...” from the File menu; the application should display the IRIX Interactive Desktop File Selection dialog so that the user can specify a file to open.
The OSF/Motif Style Guide defines several types of application-generated and user-requested dialogs. The most common of these are listed in Table 10-1, along with a brief description of when each might be used in an application and whether they should be modal or not. Figure 10-1 shows each of the standard OSF/Motif dialogs with the IRIX Interactive Desktop look, and Figure 10-2 shows the IRIX Interactive Desktop File Selection dialog. Each of these standard dialogs are discussed in more detail in the rest of this chapter and in their reference pages in Chapter 9 of the OSF/Motif Style Guide. Dialog modes are defined and discussed in the next section (“Dialog Modes”).
Table 10-1. Types of Dialogs, Their Modality, and When to Use Them
Type of Dialog | When to Use It | Modality |
|---|---|---|
To ask users for specific information. | Modeless or modal | |
To tell users about an error they've made in interacting with your application. | Application-modal | |
When there's an action pending that will cause users to lose data. | Application-modal | |
To ask users a specific question that they must respond to before continuing to interact with the application. Note that although Warning dialogs can also ask users a question, that question relates to a pending action that's destructive. | Application-modal | |
When an operation takes more than 5 seconds to complete. This dialog gives users the chance to cancel or stop the operation. Note that you might have to choose one of several different platforms as your standard for estimating times of operations. Also note that the pointer shape might need to change to the watch if the Working dialog is modal; see “Standard Pointer Shapes and Colors” in Chapter 11. | Modeless or modal | |
To give users information that's of immediate importance. Use this type of dialog sparingly; use a status area in one of your primary application windows for the less important messages (see “Status Areas in Primary Windows” in Chapter 6). | Modeless | |
To allow users to navigate the file hierarchy and choose a file. Note that the IRIX Interactive Desktop File Selection dialog, which is shown in Figure 10-2, is slightly different from the standard OSF/Motif File Selection dialog. | Modeless |
Both the IRIX Interactive Desktop and IRIS IM File Selection dialogs provide lists of the contents of the current directory and a text input field; the IRIX Interactive Desktop list contains both the files and the subdirectories of the current directory, while the IRIS IM list presents these in two separate lists. The IRIX Interactive Desktop File Selection dialog also allows users to navigate through the file hierarchy using the drop pocket, path navigation bar, and history button. As discussed in detail in “File Finder” in Chapter 9, these components allow users to drop file or directory icons in the drop pocket, traverse to ancestors of the current directory, or return to any directory visited previously. In addition, the IRIX Interactive Desktop dialog presents a Filter button (rather than the IRIS IM text input field), which brings up a dialog that allows the user to enter the filter string.
As listed in Table 10-1, dialogs can have different modes whereby the application can require the user to respond to the dialog before continuing with other actions in the application. The following are the most commonly used modes defined by OSF/Motif:
In addition to these modes, OSF/Motif defines a system-modal dialog that requires the user to interact with the dialog before doing anything else on the system. You shouldn't use system-modal dialogs because your application should never need to restrict users' activities to this degree.
Modal dialogs typically show static information, but modeless dialogs should display dynamically updated information as the current state changes. Otherwise, the dialog becomes useless. For example, the IRIX Interactive Desktop File Selection dialog dynamically updates itself if a user changes the file hierarchy while it's displayed; if it didn't, the user could select a file that no longer exists, for example.
As listed in Table 10-1, File Selection and Information dialogs are modeless. Error, Warning, and Question dialogs are application-modal. Working and Prompt dialogs can be modeless or modal, depending on what they are being used for in the application. For example, the desktop displays a Working dialog when you're copying a large directory from a remote system using a directory view, but you can still do other things in the Directory View while the copy is in progress. In other situations, you might not want to allow user input until your application has completed a particular operation. For example, when a user opens a large folder in MediaMail, no other actions can be performed in that window until the folder has been read in completely. See “Working Dialogs” for details on the design of Working dialogs.
When choosing the type and mode of a dialog . . .
Use a Prompt dialog to ask users for specific information. This dialog can be modeless or modal.
Use an application-modal Error dialog to tell users about an error they've made in interacting with your application.
Use an application-modal Warning dialog when there's an action pending that will cause users to lose data.
Use an application-modal Question dialog to ask users a specific question that they must respond to before continuing to interact with the application.
Use a Working dialog when an operation takes more than 5 seconds to complete. This dialog can be modeless or modal.
Use a modeless Information dialog to give users information that's of immediate importance. Use this type of dialog sparingly.
Use the modeless IRIX Interactive Desktop File Selection dialog to allow users to navigate the file hierarchy and choose a file.
Don't use system-modal dialogs.
Use modal dialogs to show static information, and update modeless dialogs dynamically as the current state changes.
This section discusses general guidelines that apply to the design of all dialogs—for example, dialog window decorations, size, information displayed when they first come up, and the layout of information. It also describes the standard actions (in the form of pushbuttons) that dialogs should contain. Finally, this section covers guidelines for the content of the specific types of dialogs.
Keep in mind that as discussed in Chapter 6, “Application Windows,” every dialog is associated with a specific primary or support window (its parent). The parent window should be visible and mapped to the screen so that dialogs work properly across Desks, as noted in “Desks” in Chapter 3.
This section covers:
All dialogs should have the window decorations and Window menu entries listed in Table 3-1 and described in “Window Decorations and the Window Menu” in Chapter 3. These decorations and menu entries allow the user to:
Move a dialog using the title bar. Since 4Dwm doesn't guarantee that a dialog will be placed in a specific location, a user may need to move the dialog to access information in order to figure out the appropriate response to the dialog. Note that a dialog's title bar should follow the guidelines discussed in “Rules for Labeling the Title Bar in Windows Other Than Main” in Chapter 3. A proper label allows users to quickly identify the type of dialog and the application to which it belongs.
Resize a dialog that contains resizable components such as text input fields and scrolling lists. See “Window Decorations and the Window Menu” and “Window Size” in Chapter 3 for specific guidelines on when a dialog should be resizable.
Note that these window decorations and menu entries don't include operations either for minimizing a dialog (since dialogs can't be minimized independently of their parent window) or for exiting an application from a dialog.
When a dialog is opened, its size, placement, keyboard focus, and information displayed should follow these guidelines:
The default size should allow all of the components and information to be displayed in their entirety. Users shouldn't have to resize a dialog to see its contents.
The dialog should be placed automatically on the screen—either near (but not overlapping) any related information in the parent window, or in the center of the parent window (if the contents of the dialog aren't related to the contents of the parent window). For more information on choosing a screen location, see “Window Placement” in Chapter 3.
The keyboard focus should be in the field with which the user is most likely to want to interact. For example, if there are text input fields, the focus should probably be in one of those fields. In general, dialogs should follow the keyboard focus and keyboard navigation guidelines discussed in “Keyboard Focus Policy and Navigation Within a Window” in Chapter 7.
The information being displayed in the dialog should always match the current state of the application. If the dialog is modeless, this information should be dynamically updated, as described in “Dialog Modes”.
All dialogs you create should include a response area that contains standard dialog actions (pushbuttons) tailored to the type and purpose of the dialog. The next section (“Standard Dialog Actions”) discusses what the appropriate buttons are for this area. In addition to the response area, Prompt dialogs should include an input area that consists of whatever controls are necessary for selecting objects or setting application parameters. Instead of this input area, Error, Warning, Question, Working, and Information dialogs should include a message area, as shown in Figure 10-3. The message area consists of an icon and text region that displays the dialog's message.
Don't include menu bars in dialogs; they're intended for short, quick user input rather than for accessing lots of functionality. Also, dialogs don't contain secondary work areas; if you need additional work areas, use a support window instead. (See “Support Windows” in Chapter 6 for information.) Also note that the pre-designed IRIX Interactive Desktop File Selection dialog has a somewhat different set of elements and layout than the other types of dialogs.
All dialogs include a response area that contains a horizontal row of pushbuttons across the bottom of the dialog. The standard dialog pushbuttons (or actions) are Yes, No, OK, Close, Apply, Retry, Stop, Pause, Resume, Clear, Reset, Cancel, and Help, and they should appear in that order. Your dialogs will typically contain some subset of these buttons and possibly additional ones; the additional buttons should appear after the OK and Apply buttons but before the Cancel and Help buttons.
All of these standard actions except Clear are defined in the reference page for DialogBox in the OSF/Motif Style Guide. Clear, which is used in IRIX Interactive Desktop applications, should clear all of the text input fields in the dialog. Note that this differs from the “Reset” action, which resets all controls in a dialog (not just the text fields) to default values.
When choosing which of the standard actions to include in your specific dialog, use the guidelines listed in the OSF/Motif Style Guide, Sections 6.2.1.7 and 6.2.4.2, with the following additions and exceptions:
Most dialogs should have a Help button. If the situation is stated clearly, you might not need a Help button.
Avoid using both OK and Apply on the same dialog because it often confuses users. Consider using both when the number of users who will want to make one set of changes, apply them, and close the dialog is equal to the number of users who will want to make and apply multiple sets of changes before closing the dialog.
To decide between OK and Apply, determine whether users are more likely to use the dialog to make one set of changes at a time (if so, use OK) or whether they're more likely to want to make and apply changes repeatedly before closing the dialog (in this case, use Apply).
If you can't decide which of these scenarios best describes your users, use Apply rather than OK. With Apply, users who want to make a single set of changes must press an extra button (Apply, then Close, instead of just OK), which is at most a minor annoyance. On the other hand, using OK by itself forces users who want to make several sets of changes to re-launch the dialog for each set of changes, which can be annoying.
Any dialog that has an Apply button should also include a Cancel/Close button. When the dialog is opened, the button is labelled “Cancel.” After the user applies some irreversible change, the label on the button changes to “Close” to inform users that the action is irreversible. This button doesn't indicate whether or not there are pending changes to be applied.
Working dialogs should have a Cancel button that allows users to cancel an operation and return the application to the state it was in before the operation began. If you can't return your application to the pre-operation state, you should still allow users to stop the operation at the current point in the processing. It's even better to allow the user a choice of actions—for example, Pause (with the option of later resuming) and Cancel.
By default, pressing the <Esc> key within a dialog is equivalent to clicking a Cancel button. This is true even if the dialog doesn't have an explicit Cancel button.
For many dialogs, you should choose one of the actions in the response area to be the default action. By default, the default pushbutton is visually distinguished from the other buttons (for example, the OK button in Figure 10-3), and it's activated when the user presses the <Enter> key while the dialog is the active window. If other buttons in the response area can accept keyboard focus, they become the default button when they have the focus—that is, they're visually distinct from the other buttons, and pressing <Enter> causes them to be activated. When none of these other buttons has the keyboard focus, the default button status returns to the original default button.
The following bullets describe common default actions for certain types of dialogs:
The default action for Information dialogs, which typically have buttons only for OK and Help, is OK.
The default action for Question, Warning, Error, and any other dialogs that contain buttons but no text fields is the response that users are most likely to select. For example, a Warning dialog that asks, “Do you really want to do this destructive action?” should have the affirmative response as the default action. Note that as discussed in the next section, “Labeling Dialog Buttons,” make sure that each button name clearly indicates the specific action that will occur if that button is clicked.
The default action for dialogs that have only one text field and no other controls than the buttons in the response area (such as the File Selection and Prompt dialogs) is the action that the user is most likely to select after entering a text string.
Dialogs that contain multiple text fields should not have a default action since many applications require users to press <Enter> after entering data in a text field. Users tend to press <Enter> regardless of whether they have to, and they expect that action to ensure that their data is entered; they don't expect that action to invoke the dialog's default action.
When labeling dialog buttons, use the OSF/Motif standard names except in the following cases:
Replace the “Yes” and “No” labels in Warning and Question dialogs with button names that clearly indicate the specific action that will occur if the button is clicked. The buttons replacing Yes and No perform the action and close the dialog. As an example, consider the Warning dialog shown in Figure 10-4.
Replace the “OK” or “Apply” labels in Prompt or Warning dialogs with button names that clearly indicate the specific action that will occur if the button is clicked (for example, Open, Save, Print). Don't replace these names when the button is used for more than one purpose—for example, when the file browser is used to specify a name for a new file, the OK button can be used to both name the file and display the contents of a directory.
Also don't replace either of these names on those rare instances when OK and Apply are used together in a Prompt dialog.
In addition to the general guidelines discussed in the two previous sections (“Decorations, Initial State, and Layout of Dialogs” and “Standard Dialog Actions”), follow the more specific guidelines for the different types of dialogs presented in this section. (The dialog types are defined in Table 10-1.)
Prompt dialogs use a variety of controls to collect information from the user, including text input fields, a list of all possible choices, radio buttons, checkboxes, and option menus. Try to collect this information in related chunks—that is, avoid collecting unrelated pieces of information in the same dialog, and don't launch multiple dialog boxes one right after the other to collect several pieces of information if these pieces are frequently collected at the same time.
All Error dialogs should include a description of the error, step-by-step instructions for how to recover from it (or a pointer to information on how to recover from it if the instructions are long), and a pointer to more information about why the error might have occurred. If the error involves a specific entity (for instance, a file, user, or host), name the entity in the error message, as shown in Figure 10-5. Invoke Error dialogs only when they're directly relevant to the user; for example, don't tell the user that the printer is out of paper until the user has a job in the queue.
Warning dialogs should clearly state what data is likely to be lost and why, and give the user a chance to cancel the action.
Limit your use of Question dialogs to those situations where the user couldn't have provided the information in advance. Also, don't use Question dialogs for questions that relate to a pending destructive action—for these cases, use Warning dialogs instead.
For Working dialogs, use the IRIX Interactive Desktop scale to dynamically indicate the percentage of how much of the operation is complete. A Working dialog, also known as Progress dialog or Percent Done indicator, is shown in Figure 10-6. See “IRIX Interactive Desktop Scales” in Chapter 9 for more information about these indicators.
As described earlier in this chapter in “Choosing Specific Actions for Your Dialogs,” Working dialogs should include at least one way to interrupt the task in progress. If the dialog is modal, you should also switch from the general-purpose pointer to the watch pointer in the dialog's parent window. If for some reason you're unable to include any buttons in the Working dialog (such as Cancel, Pause, Resume, or Help), switch to the watch pointer in the Working dialog to indicate that user input will be ignored while the operation is in progress. See “Standard Pointer Shapes and Colors” in Chapter 11 for more information about the watch pointer.
When choosing the window decorations, initial state, and layout of dialogs . . .
Associate every dialog with a primary or support window (its parent) that's mapped to the screen.
Use the window decorations and Window menu entries listed in Table 3-1 and described in “Window Decorations and the Window Menu” and “Rules for Labeling the Title Bar in Windows Other Than Main” in Chapter 3.
Have the default size large enough to allow all of the components and information to be displayed in their entirety.
Place the dialog on the screen either near (but not overlapping) any related information in the parent window, or in the center of the parent window if the contents of the dialog aren't related to the contents of the parent window.
Locate the initial keyboard focus in the field with which the user is most likely to want to interact.
Be sure the information being displayed in the dialog matches the current state of the application. If the dialog is modeless, update this information dynamically.
Include a response area that contains standard dialog actions (pushbuttons) tailored to the type and purpose of the dialog. Also include an input area that consists of whatever controls are necessary for selecting objects or setting application parameters in Prompt dialogs. Include a message area in Error, Warning, Question, Working, and Information dialogs.
Don't include secondary work areas; if you need additional work areas, use a support window instead.
Don't include menus. If the dialog includes so much functionality that menus are necessary, use a support window.
When choosing pushbutton actions for dialogs . . .
Use a subset of the standard dialog actions (Yes, No, OK, Close, Apply, Retry, Stop, Pause, Resume, Clear, Reset, Cancel, and Help), and have them appear in that order. If you include additional buttons, put them after the OK and Apply buttons but before the Cancel and Help buttons.
Include a Help button unless the situation is explained thoroughly in the dialog.
Avoid using both OK and Apply on the same dialog.
To decide between OK and Apply, determine whether users are more likely to use the dialog to make one set of changes at a time (if so, use OK), or whether they're more likely to want to make and apply changes repeatedly before closing the dialog (in this case, use Apply).
Include a Cancel/Close button on any dialog that has an Apply button.
Include a Cancel button on Working dialogs and, if possible, a Pause button (with the option of later resuming).
When choosing and creating default actions . . .
Whenever appropriate, choose one of the actions to be the default action.
Have OK be the default action for Information dialogs (which typically have buttons only for OK and Help).
Have the response that users are most likely to select be the default action for Question, Warning, Error, and any other dialogs that contain buttons but no text fields.
Have the response that users are most likely to select after entering a text string be the default action for dialogs that have only one text field. Use no other controls than the buttons in the response area (such as the File Selection and Prompt dialogs).
Don't have a default action for dialogs that contain multiple text fields.
When labeling dialog buttons . . .
Replace the “Yes” and “No” labels in Warning and Question dialogs with button names that clearly indicate the specific action that will occur if the button is clicked.
Replace the “OK” or “Apply” labels in Prompt or Warning dialogs with button names that clearly indicate the specific action that will occur if the button is clicked, unless the button is used for more than one purpose, or in the rare instance that “OK” and “Apply” are used together in a Prompt dialog.
In all other cases, use the OSF/Motif standard names.
When deciding what content to include in specific types of dialogs . . .
Use Prompt dialogs to collect information in related chunks—that is, avoid collecting unrelated pieces of information in the same dialog, and don't launch multiple dialog boxes sequentially to collect several pieces of information if these pieces are frequently collected at the same time.
Include a description of the error, step-by-step instructions for how to recover from it, and a pointer to more information in Error dialogs. If the error involves a specific entity (for instance, a file, user, or host), name the entity in the error message.
Invoke Error dialogs only when they're directly relevant to the user; for example, don't tell the user that the printer is out of paper until the user has a job in the queue.
State what data is likely to be lost and why, and give the user a chance to cancel the action in Warning dialogs.
Limit your use of Question dialogs to those situations where the user couldn't have provided the information in advance.
Don't use Question dialogs for questions that relate to a pending destructive action—for these cases, use Warning dialogs instead.
Dynamically indicate how much of the operation is complete with the IRIX Interactive Desktop scale used as a percent-done indicator in Working dialogs.
Switch from the general-purpose pointer to the watch pointer in the parent window of a modal Working dialog.
Users expect to encounter dialogs in certain situations. This section describes the most common situations and gives an example of the dialog your application should provide if users can encounter this situation when interacting with your application. Topics include:
For more information about the standard menu entries referred to in this section, see “Standard Menus” in Chapter 8.
Since dialogs are designed to get the user's attention, overuse of them will be distracting to the user. Similarly, don't use application-generated dialogs to provide general status information; use a status area in the associated primary or support window instead (see “Status Areas in Primary Windows” in Chapter 6).
Users expect to be prompted with a dialog whenever they choose a menu entry that includes an ellipsis. These dialogs prompt the user for information that's necessary before the action can be completed, as described in the following common examples.
“Open...” from the File (or leftmost) menu should display the IRIX Interactive Desktop File Selection dialog shown in Figure 10-2. The first time this dialog is opened for an application, it should show the current working directory and no specific file. Subsequently, it should come up in the state it was last in when the user dismissed it—that is, it shows the last directory the user traversed to, and the file that the user opened the last time is selected. (See Table 10-1 and Figure 10-2 earlier in this chapter for more information about the IRIX Interactive Desktop File Selection dialog.)
“Save As...” from the File (or leftmost) menu should display the IRIX Interactive Desktop File Selection dialog. If the file being saved doesn't exist yet, the dialog should show the current working directory and no specific file. If the file exists, the dialog should show that file's directory, and the current name of the file should be selected. If the user uses “Save As...” to change the name of an existing file, your application should create a copy of the existing file with the new name, close the previous file, and open the new file. (See “File Menu” in Chapter 8.)
When users open, close, or save changes to files, prompt them with the Warning dialog shown in Figure 10-4 whenever these actions will cause data to be lost. The standard situations in which this can arise include the following (see “Application Models” in Chapter 6 for a discussion of the single- and multiple-document application models described in the following paragraphs):
In an application that allows only one document to be open at a time, when the user chooses to open another (new or existing) document and there are unsaved changes in the currently opened document. The user can open another document by selecting “New” from the File menu, by selecting “Open...” from the File menu and using the File Selection dialog, or by choosing a file from the “Reopen” cascading menu in the File menu.
When the user chooses “Close” from the File menu in a co-primary window, and the co-primary window contains data that will be lost if the window is closed. This situation is especially common in applications that support multiple open documents because for these applications, closing a co-primary window is equivalent to closing a file.
When the user chooses “Exit” from the File menu, and at least one open co-primary window contains data that will be lost if the application is exited. For applications that support multiple open documents, prompt the user with a separate dialog box for each file that's currently open and has unsaved changes.
Other common file-related situations that require dialogs include:
When the user chooses “Save” from the File menu, and the current file is untitled. In this situation, prompt the user with the IRIX Interactive Desktop File Selection dialog, as described above for “Save As....”
When the user is interacting with the File Selection dialog and chooses a filename that already exists. In this situation, prompt the user with the Warning dialog shown in Figure 10-7.
When the user chooses “Revert” from the File menu, and the file currently has unsaved changes. In this situation, prompt the user with the Warning dialog shown in Figure 10-8.
When the user chooses “Product Information” from the Help menu, provide an Information dialog like the one shown in Figure 10-9. (See “Product Information” in Chapter 4 for some suggestions about what to include in Product Information dialogs.)
When users initiate an operation that takes more than five seconds to complete, your application should display a Working dialog. In this situation, prompt the user with the Working dialog shown in Figure 10-6. Note that you might have to choose one of several different platforms as your standard for estimating times of operations. See “Working Dialogs” earlier in this chapter for more information about the content of these dialogs.
When the user chooses “Paste” from the Edit menu and there's nothing currently on the clipboard to be pasted, bring up an Information dialog that says “The clipboard is empty” and that contains the single button “OK.” (See “Edit Menu” in Chapter 8.)
When determining when to display a dialog and which dialog to display . . .
Limit the use of dialogs to those cases when they're absolutely necessary. Don't use dialogs to provide general status information—use a status area in the associated primary or support window instead.
Invoke a dialog whenever users choose a menu entry that includes an ellipsis.
Display the IRIX Interactive Desktop File Selection dialog when the user chooses “Open...” from the File menu. The first time this dialog is opened, it should show the current working directory and no specific file. Subsequently, it should come up in the state it was last in when the user dismissed it.
Display the IRIX Interactive Desktop File Selection dialog when the user chooses “Save As...” from the File menu. If the file being saved doesn't exist yet, the dialog should show the current working directory and no specific file. If the file exists, the dialog should show that file's directory, and the current name of the file should be selected.
When users open, close, or save changes to files, prompt them with a Warning dialog whenever these actions will cause data to be lost:
In an application that allows only one document to be open at a time, when the user chooses to open another (new or existing) document and there are unsaved changes in the currently opened document. (For example, the user chooses “New,” “Open,” or “Reopen” from the File menu.)
When the user chooses “Close” from the File menu in a co-primary window, and the co-primary window contains data that will be lost if the window is closed.
When the user chooses “Exit” from the File menu, and at least one open co-primary window contains data that will be lost if the application is exited. For applications that support multiple open documents, prompt the user with a separate dialog box for each file that's currently open and has unsaved changes.
Prompt users with the File Selection dialog when they choose Save from the File menu and the current file is untitled. The behavior is the same as the “Save As...” entry in this situation.
Prompt users with a Warning dialog when they're interacting with the File Selection dialog and they choose a filename that already exists.
Prompt users with a Warning dialog when they choose “Revert” from the File menu and the file currently has unsaved changes.
Display an Information dialog when a user chooses the “Product Information” entry from the Help menu.
Display the Working dialog when users initiate an operation that takes more than five seconds to complete. Note that you might have to choose one of several different platforms as your standard for estimating times of operations.