a3--Heursitic evaluation

• 6. 提供上下文识别而不是孤立记忆 使物体、动作和选项都清晰可见。 用户应该不需要在系统的一个部分记忆一些信息，才能使用系统的另一 个部分。系统的使用说明应该在需要的时候容易找到，并清晰可见。 计算机应该可以把可选项显示给用户，而不应该要求用户自己记忆所有 的命令。 与这条原则相关的可用性问题的例子包括： 系统的使用过于复杂，用户不得不记忆复杂的命令去操作系统； 界面提供的信息不及时，用户不得不自己从系统的另一个部分找到相 关的信息； 图像或符号难以理解，甚至误导用户； 菜单、选择或链接有太多的层次。
• 7.Flexibility and efficiency of use
Accelerators -- unseen by the novice user -- may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.
• 7. 使用的舒适性和高效性 为用户提供捷径。这些捷径常常可以提高熟练用户的使用效率，让 用户能方便地启用使用频率较高的功能。 好的软件不但对新用户来说简单易学，还要对熟练用户来说快捷高 效，尤其是可以很方便地使用频率较高的功能。提高效率的最好的办法就 是提高软件的自动化程度，尽量减少用户不必要的动作。 为常用功能提供功能键和命令键。命令键是指用来代替菜单的“热 键”。 在有等级层次的信息系统中，应该允许用户容易地切换到系统的其 他部分。 系统的默认值是为用户提供的另一个捷径，用户可以很快地阅读并 接受默认值，这样可以省下填写和选择的时间。 • 与这条原则相关的可用性问题的例子包括： 系统缺少自动化，没有自动地执行下面的任务，例如，一个新窗口打 开时，视窗大小不合适，用户不得不自己改变视窗的大小； 系统没有提供应有的默认值； 默认值不正确； 使用系统需要太多的控制动作； 系统没有提供捷径，例如，系统没有定义必要的功能键。
• 5. 预防错误的发生 人的行为分为三个层次：基于知识的，基于规则的和基于技巧的行为层 次。 5.1 基于知识的行为，常常发生在刚刚开始使用新系统时。 错误主要由用户对系统理解的差错引起。 为防止错误，应该为用户提供正确的帮助信息，帮助他们在解决问题的 过程中建立对系统的正确理解。 5.2 基于规则的行为层次，用户根据记忆中已经形成的规则来处理所接受 到的信息。 错误常常是因为忽略了重要的步骤，或是使用了错误规则来处理问题。 防止错误最有效的方法是提供明确的文字提示，或是非语言的暗示（如 鼠标变化） 上去像背景，用户不知道他们可以点击这些图像到达其他网页。
• 5.3 基于技巧的行为层次，用户的行为是一种近乎机械的行为，他们 可以不断地对接受到的信号进行条件反射式的处理。 错误常常是与用户的知觉及运动机能有关。（不够详细） 系统提供的信息应该能清晰地从背景中分辨出来，防止用户错误。（ 目的是为了防止由于动作的习惯性导致的出错，因此提示信息应该很 明显显示，从而起到一个中断的作用。） 与这条原则相关的可用性问题的例子包括： 用户不能学会怎样控制用户界面上的物体； 输入信息时，界面没有告诉用户所需闪烁的光标来提示用户可以输入； 用户界面上不同的物体太相似，例如：在网页上有超级链接的图像 看
•
1.1 系统的响应时间 总的来说，用户比较喜欢较短的响应时间 较短的响应时间会使用户的思考时间缩短，用户会加快和计算机交互的频 率，从而可能会相应地增加错误率。 小于0.1s的响应是即时响应；（如打字、光标移动和鼠标选择等响应时间 应该50ms-150ms） 通常小于1s的响应时间不会打断用户的连续思考（用户能注意到延迟，但 通常只需用直接显示结果，不需要特别的反馈信息） 简单且经常使用的任务的响应时间应该小于1s 10s是用户保持注意力的极限。 随着响应时间的增长，用户的满意度会降低。 1.2 网页的下载时间和用户觉察的下载时间 试验表明，用户觉察的下载时间和用户放弃下载网页的几率是显著相关的 。 2000年对网页实际下载时间的研究表明，用户对低于5s的下载时间的评价 是良，6s – 10s是中，高于10s是差。 适当的反馈可以缩短用户觉察的下载时间。 在网速不高的情况下，一个长网页可能会比几个短网页有更高的可用性。
• Help and documentation
Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user's task, list concrete steps to be carried out, and not be too large.
• 4.Consistency and standards
Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.
十条启发式评估准则
1. 提供显著的系统状态 与这条原则相关的可用性问题的例子包括：
• 缺乏必要的反馈，没有清晰的系统状态；例如：在网站中用户登录 后，应该有持久的信息提示用户已登录的状态； • 反馈不够持久，用户没有足够的时间注意到或理解反馈的内容； 反馈没有立即显示； • 非文字反馈不容易看到，或不容易理解； • 不必要的反馈，或是反馈使用户慢下来； • 让用户误解的反馈。 系统应该随时让用户知道什么正在发生，这应该是在合理的时间内，通过提 供正确的反馈来达到的。
• 4. 保持一致性和标准性 一致性包括内部一致性（系统的各部分之间要保持一致）和外部的一 致性（系统应该和其他的系统、传统的习惯和标准保持一致） 系统内，同样的信息应该使用一致的用词、外观和布局。可以帮助用 户快速学习记忆和熟悉系统的功能。 与这条原则相关的可用性问题的例子包括： 界面元素的外观、布局和分组不一致； 界面元素的命名不一致； 系统反馈信息的格式不一致； 系统提供不一样的方法来操作相似的对象； 表达含义不一致，例如在不同的地方红色代表不同的意义； 设计标准和通用的标准不一致。
• 5.Error prevention
Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.
• 3. 让用户能随时退出操作进程 用户有时会错误地使用系统的功能，他们需要一个清晰的紧急出 口离开当前不必要的状态，支持撤销和恢复的功能。 用户喜欢使用工具时有运用自如的感觉，软件也不例外。他们不 喜欢有被系统控制，困在当中的感觉。 用户学习使用系统的过程是一个试错的过程，他们通常会试一试 新的功能，如果发现错误就改正错误，试用新的方法直到成功为止。 需要紧急出口，确保试错的过程。 撤销功能可以鼓励用户尝试新的功能 与这条原则相关的可用性问题的例子包括： 在不可逆转的行动之前系统没有提供足够的警告； 系统没有在适当的时机提供取消的功能； 系统的取消功能不明显或是很难找到； 系统不支持撤销的功能。
1.Visibility of system status
The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.
• 8.Aesthetic and minimalist design
Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.
Jacobe Nielsen 的10条启发式 评估准则***
• These are ten general principles for user interface design.
• They are called "heuristics" because they are more in the nature of rules of thumb than specific usability guidelines.
• 9.Help users recognize, diagnose, and recover from errors
Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.
• er control and freedom