Figure 1: This is what the button layout and order should be for dialog boxes that require the standard set of apply buttons.
Proposal for the Use of an Apply Button in Dialogs
Version 1
Date: February 14th, 2001
David Engen, Andrea Mankoski, Leyla Schroeder
These guidelines for the placement and functionality of a standard "apply button set" in dialog boxes have been developed to facilitate the process of finely adjusting objects within StarOffice / OpenOffice.org documents. The benefit is that users will be able to see their changes immediately reflected in the context of the document while the dialog box is still open. Users frequently want to make iterative changes to the selection, and if the dialog closes as each change is made, it is inefficient to re-open the dialog multiple times.
The "Apply button" functionality was deemed as a necessary tool for the medium-skill to advanced-skill user to avoid tedious command repetitions and for efficiency. Because this functionality will replace several other button sets, it is important that while it helps with efficiency to the advanced user, it does not hinder novice or cross-over users.
The proposed guidelines set standards for the placement of a "standard set of Apply buttons" as well as the behavior of each of the buttons in the set. Inclusion and exclusion principles have been established to more clearly state when and when not to use this functionality. It clearly states what buttons should be included in the "standard set of Apply buttons", what types of dialog boxes they should be used with, and their location and arrangement in those appropriate dialog boxes.
In addition to guidelines for the use of the standard set of apply buttons, a non-exhaustive list of dialog boxes to which it might be useful to add the standard set of apply buttons has been included - these can be found in the Appendix. Dialog boxes in four modules of StarOffice / Openoffice.org (Writer, Calc, Impress, Draw) were examined to see whether they warranted the Apply functionality. Because of the variation in conditions under which these buttons can be used, some dialog boxes were verified individually. All of those mentioned in this specification were found under the Format menus on the main menu bar of StarOffice v5.2. There is some overlap from module to module, but there are also dialog boxes that are module-specific.
In summary, this report provides inclusion and exclusion guidelines, button configuration and behavior guidelines, scenario descriptions, and screen-shots of some of the dialog boxes that may be affected by the implementation of this functionality.
StarOffice v5.2 used several variations of an Apply button without any apparent standardization measures, and this functionality is not new. Some examples of programs that have already implemented similar functionality are: for Windows Display and Desktop Themes (Start - Settings - Control Panel - Display/Desktop Themes); and for GNOME the Panel Properties dialog. This dialog shows a button set with "OK", "Apply", "Close", "Help", though in the desktop's Control Center (Main Menu Button - Programs - Settings - Desktop - Panel) you can find a set with "Try", "Revert", "OK", and "Cancel".
Note:
The Assign button that can be found in several dialog boxes in StarOffice / OpenOffice.org Draw (i.e. Format - 3D Graphics) is not dealt with in this HCI Specification. It is suggested that when the behavior of those Assign buttons is identical to that of the Apply button, the mouse-over tip for the assign button be changed from "Assign" to "Apply" to avoid confusion. Otherwise, the name of this command should be changed to something less ambiguous.
It is recommended that dialog boxes employ the standard set of apply buttons: "OK", "Apply", "Reset", and "Close". Because it is also useful to be able to find contextual help from each of those dialog boxes, the standard button set will also include a "Help" button. The buttons order and layout can be seen in Figure 1.
Figure 1: This is what the button layout and order should
be for dialog boxes that require the standard set of apply buttons.
The buttons should be aligned along the bottom of the dialog boxes in question and should be referred to as "the standard set of apply buttons". Their behavior is as follows:
When a user clicks the OK button, the settings should be saved and the commands specified in the dialog box should be carried out. The dialog box should then be closed.
When a user clicks the Apply button from the main dialog box, changes are applied to the selected object within the document, but the dialog box is not closed.
When a user clicks the Reset button from the main dialog box, the settings in the dialog box are returned to their values as per the last Apply command. If the user has opened the dialog and has made changes but has not yet clicked the Apply button, the settings are returned to the values corresponding to when they first opened the dialog box. The Reset button does not close the dialog box.
When a user makes changes to the values in the dialog box and clicks the Close button from the main dialog box without first clicking Apply, an alertbox like the one shown below should be displayed to allow them to continue without losing any information.
The Help button invokes the standard Help Tool window contextualized to the dialog box in question.
Figure 2: This is the alert-box that is displayed if a user clicks the Close button and there are changed settings that have not yet been applied to the document.
The wording of the text within the alert-box is modeled after phrasing that is already used throughout StarOffice 5.2. It should read: "Settings have been modified. Do you want to apply your changes?" The alert-box is similar to that which appears when a user attempts to close a document without saving its contents first. The behavior of each button in this alert-box is as follows:
When a user clicks the Apply button in the alert-box, the changes they made to the values within the main dialog box will be applied to the selection in the document, and the dialog box is closed.
When a user clicks the Discard button in the alert-box, the changes they made to the values within the main dialog box should not be applied, and the dialog box should be closed.
When a user clicks the Cancel button in the alert-box, the alert-box should be closed but the changes should not be applied and the user should be returned to the main dialog box.
Mouseless navigation and keyboard traversal should work as in other StarOffice / OpenOffice.org dialog boxes employing default buttons, mnemonics, and full keyboard access.
For accessibility reasons, mnemonics have been added to the Apply and Reset buttons. The Close button does not require one because the Escape key defaults to Close in a dialog box. The letters "a" and "r" have been chosen as the mnemonics for Apply and Reset respectively. The letter "h" will remain as the default for Help as is standard.
To ensure that users have a safety net, they should always be allowed to undo commands that were invoked through an Apply button in a dialog box. The current behavior in one of the few modeless dialog box that currently (v5.2) contains an Apply button (Insert - Hyperlink) is to undo each of the apply commands individually, even if the selection has been changed. It is suggested that modal dialog boxes follow this behavior as closely as possible for the sake of consistency. This means that for both modal and modeless dialog boxes the Undo command should only go as far back as one Apply command, and not as far as all the Apply commands invoked in the last instance of the dialog box.
The "standard set of apply buttons" should be used ... :
When it might be helpful to users to make iterative changes to a selection within a document without closing and re-opening the dialog box.
Even in instances where the dialog box presents the user with a preview of the changes in question. This allows the user to view the object's properties in the context of the document.
The "standard set of apply buttons" should not be used ... :
If the changes applied to the user's selection are not visibly noticeable. Dialog boxes that contain visibly confirmable changes and non-visibly confirmable changes may still use the apply button set, and should apply both sets of changes.
If the changed settings will not immediately be reflected in the user's document.
If the Apply command is in reference to an action that will occur within that specific dialog box. It should only be used when setting are transferred from a dialog box directly to a document.
In any dialog box that is accessed from within another dialog box (i.e. secondary, terciary, ... ).
When the changes made in the dialog box are immediately reflected in the document, as in an inspector window.
The Apply and Reset buttons should be inactive(grayed out) when the user first opens a dialog box that contains the standard set of apply buttons. They should become active as soon as any of the values are changed in that dialog box. As soon as the Apply or Reset buttons are clicked, they should again revert to their greyed out condition.
When a user clicks the Apply button in a dialog box containing multiple tabs, the settings in all tabs within that dialog box should be applied, not only those in the active window. To be consistent, when the Reset command is clicked, the settings in all tabs within that dialog box should be reset.
The Reset button (that returns settings to previously applied values) should not be confused for a defaults button (that returns settings to program defaults). Dialog boxes that need a Defaults button should present it separately from the standard set of apply buttons.
The account of buttons should be reduced to a minimum as too much buttons could be confusing for a user. Because of this two questions came up:
It is not clear if the Reset button should be an optional part of the button set. As there might be situations where an Apply button would be useful, but a Reset button would not make so much sense. An example are dialogs, where just some simple values are entered, e.g. for adjusting the row height of a table (see Format – Row – Height). The more complex the possible dialog settings are, the more useful a Reset button would be. Should the Apply button set always contain a Reset button?
Can we find another solution for the Help button, for example by replacing it with an icon? (As this also affects other dialogs, that won't have an Apply button, this will probably be an open issue for the future.)
The Reset button's current behavior allows users to revert the settings in the dialog box to their values as of the last Apply command. As we see it, there are several options here:
Change the behavior of the Reset button to more of an Undo so that it reverts the settings back to the values at the invocation of the dialog box
Eliminate the Reset button altogether to eliminate clutter, still allowing the user to "cancel" their Apply commands using the Undo function
Leave the Reset button like it is.
Again, there are other options that are listed here, but what is the best solution?
Appendix 1: Proposed Additions