HE: Consistency and Standards(一致性与标准化的设计规范)

HE: Consistency and Standards(一致性与标准化的设计规范 )

Don’t Frustrate the User（不要迷惑用户 ）

Users become accustomed to certain actions and sequences, and they are likely to become confused or frustrated when they encounter unexpected behavior. When one screen requires a specific series of actions, users will expect the same series of actions to be required under similar conditions. The qualities of familiarity and predictability in an interface reduce the stress involved in using an application.

系统的返回信息需要明确 ，需要让用户能够在看到系统的反应时不会诧异和意外。

Maintain Platform Consistency（系统设计需要符合平常的使用惯例 ）

Products should conform to the conventions of the platform for which they are built.

1. User frustration is minimized when products adhere to platform conventions.  An example of a platform convention is the location and contents of the File menu-the File menu option is always the leftmost item on a Windows-style menu bar-and users can expect to find File menu commands for opening, closing, saving, printing, and quitting.
2. Users are able to learn new products quickly. That is, users don’t have to learn new locations or sequences for common commands (such as Open, Close, Save, Print, and Exit/Quit). Hence, they can concentrate on learning the commands that are unique to the product.

  Maintain Application Consistency（整个系统需要统一 ）

Consistency within an application is also important. One kind of consistency is location consistency-that is, commands should not move around between menus, sometimes appearing on one menu and sometimes on another. Also, commands should not appear and disappear from menus-disappearing or moving menu items leave users unsure of where and when they last saw or used a particular item. Instead, menu items that aren’t available to the user at a given moment should be dimmed (or shaded ) instead of being removed from the menu.

Other areas where consistency is important are

1. Key bindings-keyboard shortcuts should comply with platform and application standards.
2. Messages, warnings, and alarms-messages, warnings, and alarms should be consistent in their wording and in where they appear.
3. Color semantics—colors, when they are used as codes, should keep the same meaning throughout.
4. Formatting-formatting styles for date and time, monetary units, and numbers should be kept consistent.
5. Dialog boxes-dialog boxes should be consistent in their presentations.
6. Data presentation-aspects of data presentation (such as labeling, capitalization, font face, use of bold and italic, and the placement of fields) should be kept consistent.
7. Terminology-words used to describe actions, behaviors, and commands should be kept consistent.

系统上面的显示和使用控件需要在系统的始末都保持一致 ，举个简单的例子：一个button在有的时候不能点击，这个时候我们最好使它的属性变成不可使用而不是直接删除。

这方面（一致性 ）涉及到其它的一些控件和事件：

1. 快捷键
2. 各种提示信息
3. 颜色风格（错误提示是一种风格、普通显示是一种风格等等）
4. 整体样式
5. 提示对话框
6. 数据显示
7. 专业的术语

 

下面用一个UAR来作为一个具体实例进行解释：

Date/Time Control Panel Applications of this Heuristic

Example UAR: Aspect 1 - Button Labels Are Good

UAR Identifier

HE5-Good Feature

Succinct description:

"OK", "Cancel", and "Apply" button labels follow Windows standards.

Evidence for the aspect:

Heuristic: Consistency and standards (in particular, the "standards" part of this heuristic)

Interface aspect:

The buttons at the bottom of the screen are labeled "OK", "Cancel", and "Apply"-as shown in the picture below.

In the online MSDN Library Visual Studio 6.0 (see Books/The Windows Interface Guidelines for Software Design/ Chapter 8 Secondary Windows/Property Sheets and Inspectors/Property Sheet Commands) , it lists the following standard ways to close the property sheet:

 

Command

Action
OK	Applies all pending changes and closes the property sheet window.
Apply	Applies all pending changes but leaves the property sheet window open.
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:

All the standard ways to close the property sheet are present and work as described.

Benefit of the good feature:

Users will be able to use their prior knowledge of Microsoft products with this control panel.

Solution:

I cannot think of any drawbacks to using the standard button labels and actions at this time.

Relationship to other UARs:

None when this UAR was originally written.

 

 

Example UAR: Aspect 2 - Button Names Are Very Similar

At the same time that the "OK" and "Apply" button labels conform to the standards part of the consistency and standards heuristic, those words are so similar in meaning that they may violate the "consistency" part of the same heuristic. That is, when very similar words are used to describe different actions, the user is likely to become confused. First, we'll write up this UAR and then discuss the problem of what to do when heuristics give conflicting design advice.

UAR Identifier

HE6-Problem

Succinct description:

The difference between "OK" and "Apply" is not obvious.

Evidence for the aspect:

Heuristic: Consistency and standards (in particular, the "consistency" part of this heuristic)

Interface aspect:

The button labels "OK" and "Apply" have very similar definitions in lay English.

Definition of "OK" in Webster's New Collegiate Dictionary: approve, authorize.
In the context of just making changes to something, the changes are the things that are approved or authorized.

Definition of "apply" in Webster's New Collegiate Dictionary: To put into effect.
In the context of just making changes to something, these changes are the things that will be put into effect.

Explanation of the aspect:

The difference between "OK" and "Apply" is not obvious to the user. From common definitions of the words, it would seem that they do the same thing: make the changes that the user just indicated in the control panel. Since the words are different, the actions should also be different according to the consistency and standards heuristic, but the difference between the actions should be reflected in the words used to label them.

According to the Design Guide passage quoted above , both buttons apply the changes the user made to the property sheet. The only difference is that the Apply button leaves the property sheet open and the OK button closes the property sheet. Unfortunately, this difference is not inherent in the meanings of the labels.

Severity of the problem:

The users will probably learn the difference between these buttons pretty quickly, especially if they use other Windows products.

Solution:

Change the labels to reflect the real difference in the actions. Perhaps use "Apply" and "Apply & Close".

However, following this solution will violate the Windows Design Guide conventions and, therefore, will violate the standards part of the same heuristic. The buttons "OK" and "Cancel" were standardized long before dialog boxes that needed "Apply" were in use. Therefore, the terms have been "inherited" with a lot of users knowing what they mean. It will not be easy to change away from the "OK" label.

Relationship to other UARs:

UAR# HE5 – Good Feature:
"OK", "Cancel," and "Apply" button labels follow Windows standards.

This heuristic seems to give conflicting advice. Perhaps we'll have to do user testing-or at least conduct a survey or some interviews-to see if our users will really have problems with "Apply" and "OK".