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.
- 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.
- 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
- Key bindings-keyboard shortcuts should comply with platform and application standards.
- Messages, warnings, and alarms-messages, warnings, and alarms should be consistent in their wording and in where they appear.
- Color semantics—colors, when they are used as codes, should keep the same meaning throughout.
- Formatting-formatting styles for date and time, monetary units, and numbers should be kept consistent.
- Dialog boxes-dialog boxes should be consistent in their presentations.
- 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.
- Terminology-words used to describe actions, behaviors, and commands should be kept consistent.
系統上面的顯示和使用控件需要在系統的始末都保持一致 ，舉個簡單的例子：一個button在有的時候不能點擊，這個時候我們最好使它的屬性變成不可使用而不是直接刪除。
這方面（ 一致性 ）涉及到其它的一些控件和事件：
- 快捷鍵
- 各種提示信息
- 顏色風格（錯誤提示是一種風格、普通顯示是一種風格等等）
- 整體樣式
- 提示對話框
- 數據顯示
- 專業的術語
?
下面用一個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:
?
| 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".
更多文章、技術交流、商務合作、聯系博主
微信掃碼或搜索：z360901061
微信掃一掃加我為好友
QQ號聯系： 360901061
您的支持是博主寫作最大的動力，如果您喜歡我的文章，感覺我的文章對您有幫助，請用微信掃描下面二維碼支持博主2元、5元、10元、20元等您想捐的金額吧，狠狠點擊下面給點支持吧，站長非常感激您！手機微信長按不能支付解決辦法：請將微信支付二維碼保存到相冊，切換到微信，然后點擊微信右上角掃一掃功能，選擇支付二維碼完成支付。
【本文對您有幫助就好】元
