HE: User Control and Freedom（用户具有良好的控制权与较高的自由度）

Let the User Be in Control(让用户具有控制权 )

The sense of "who's in charge" strongly affects how a user feels about an application. Users get frustrated when they don’t feel in control of the computer, and for this reason, users should initiate actions, not the computer. Also, carefully consider the wording of messages; their tone should suggest that the computer is ready and compliant, not commanding or threatening, and that the user, not the computer, is in charge.

交谈之中，听者为大。软件生产，客户为大。软件运行，用户为大。软件始终需要灌输一个思想：用户是软件运行的主导，他需要具有很好的软件控制权。

Provide an Undo Mechanism（提供撤销操作）

The user should be able to reverse the steps in a process and retreat back to a previous state. Some of the ways applications implement undo are listed below:

An undo command that reverses the most recent command is common in many applications. The simplest form only allows the user to reverse the most recent command. Some applications allow the user to reverse several steps.

A "Reset" or "Factory Settings" button is another form of undo mechanism. These buttons will reverse certain edits. The Reset button will reverse settings that have been set in the current editing session. The Factor Settings button will cause the settings to be returned to their out-of-the-box configuration。

人人都会犯错，软件使用者亦不例外。我们需要给用户提供良好的用户体验。提供Redo和Undo.这一点我非常佩服Google，人家让WEB应用也如此的人性化了。在这里略微谈下原理：利用栈结构。

Require Confirmation(在重要操作时，需要给用户提供确认操作 )

The user should be warned when an irreversible action is about to be initiated. An application should require an explicit confirmation before allowing an irreversible step to be set in motion.

Provide an Escape Route（提供及时退出功能）

Users should be able to halt processes. A typical way to provide for this is to offer a Cancel button at all times. However, when canceling a process may leave the computer in an unstable state - such as canceling an install process when only a subset of the necessary files have been transferred - the user should be warned that canceling could have negative consequences and should be advised of an alternative way to halt or reverse the process.

下面给出一个UAR：

Date/Time Control Panel Applications of this Heuristic

Example UAR: Aspect 1 — Cancel Button Is Good

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:

Command

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:

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."