UAR Identifier

HE7 - Good Feature

Succinct description:

"Cancel" button provides an "emergency exit."

Evidence for the aspect:

Heuristic: User control and freedom

Interface aspect:

There is a Cancel button at the bottom of the screen, as shown in the picture below:

In the online MSDN Library Visual Studio 6.0 (see section Books/The Windows Interface Guidelines for Software Design/ Chapter 8 Secondary Windows/Property Sheets and Inspectors/Closing a Property Sheet) , it lists the following specification of the Cancel button's action:

?

Action
?	?
Cancel	Discards any pending changes and closes the property sheet window. Does not cancel or undo changes that have already been applied.

?

Explanation of the aspect:

If users setsthe time and then change their minds, they can cancel all the changes by clicking the Cancel button. The button is prominent and is the standard way to undo a sequence of changes made in a property box.

Benefit of the good feature:

Users will be able change their mind and undo a series of changes with just one button click.

Solution:

Although the Cancel button discards all the changes that have not been applied and closes the window, if the Apply button was clicked prior to clicking the Cancel button, no changes will be undone, though the window will be closed. See UAR #HE8 for more discussion of this control panel operation.

Relationship to other UARs:

UAR# HE8 Cancel doesn't give feedback when it doesn't cancel anything.

?
?

Example UAR: Aspect 2 — UARs Sometimes Lead to More UARs

It is quite possible that as you write up one UAR about a good feature or problem, you will discover other usability aspects that warrant their own UARs. When this happens, just record in the first UAR that another UAR is connected; then write the second UAR. For example, while writing UAR# HE7 above, we discovered that the Cancel button doesn't always cancel something, and when it does not, it doesn't indicate that fact. We discovered this when we were thinking about trade-offs and writing in the Solution slot. Therefore, we put a note in that slot referring readers to the next UAR, UAR# HE8. Likewise, we listed UAR# HE8 in UAR# HE7's Relationship to other UARs slot.

UAR Identifier

HE8 - Problem

Succinct description:

Cancel doesn't give feedback when it doesn't cancel anything

Evidence for the aspect:

Heuristic: Visibility of system status

Interface aspect:

There is a Cancel button at the bottom of the screen, as shown in the picture below:
?

In the online MSDN Library Visual Studio 6.0 (see section Books/The Windows Interface Guidelines for Software Design/ Chapter 8 Secondary Windows/Property Sheets and Inspectors/Closing a Property Sheet) , it lists the following specification of the Cancel button's action:

?

Command

Action
?	?
Cancel	Discards any pending changes and closes the property sheet window. Does not cancel or undo changes that have already been applied.

?

As specified in the Design Guide , if changes are made in the property box and then the Apply button is pressed, those changes are made permanent and cannot be discarded by clicking the Cancel button. However, there is no visual indication that these changes are not available to be canceled; the Cancel button still looks active. In effect, if the Cancel button is clicked right after the Apply button is clicked, the Cancel button will behave exactly like the OK button: it will simply close the window (because the changes have already been applied).

Explanation of the aspect:

The Windows Design Guide does not seem to give advice about whether the standard buttons should be available (black) or unavailable (gray) at any particular time. However, this Date/Time control panel tab (labeled "Date & Time") makes the Apply button unavailable (gray) when there are no changes to be applied, and it will have no effect. The Cancel button is not grayed out when there are no changes to cancel, presumably because it will still have an effect (i.e., closing the window), but it will NOT have the effect it was labeled for (i.e., canceling something) if the changes have been applied.

Severity of the problem:

This can be a rather severe problem if there is no way the user can check the status of the property box once it is closed - or even if the information is on the screen but difficult to see. In this case, many users will have the clock in very small font down in the bottom right corner where they may never have occasion to look. This is severe because users may think they've canceled changes when they haven't: in reality, the changes have been applied to the system clock. This change will affect the dating of files and e-mail messages and, therefore, can have wide-reaching consequences.

Solution:

Make the Cancel button unavailable (gray) when there are no changes to cancel. Thus, the Apply and Cancel buttons will either be available (black) or unavailable (gray) at the same time - depending on whether or not there are changes to apply or cancel.

When there are no unapplied changes, only the OK button will be available (black), and it will close the window.

Note that this train of thought could continue to the point of reconsidering if the OK button should also be gray when there are no unapplied changes made. The window could always be closed with the Close button (labeled with an "x") in the top right corner of the window. A complete analysis of this issue would generate at least one more UAR to discuss the OK button, links between all these UARs, and a group UAR to discuss them all as a group (to be discussed in a later section of the course). The Windows Design Guide seems to be silent on the issue of active/inactive Property Sheet command buttons, so graying the Cancel button would not violate an explicit platform standard. However, we might want to look at several other applications with property boxes to see if there is a de facto standard, or see if people in user tests are confused by the Cancel button becoming unavailable (gray).

Relationship to other UARs:

UAR# HE7 - Good Feature:

"Cancel" button provides an "emergency exit."