需求分析的基本问题：
1. 专注于用户的任务，Task，而不是所谓的技术。
2. 时刻清楚谁是最终用户，最终用户使用你的软件所需要服务的对象是谁。
3. 软件做什么用的，支持什么活动，解决什么问题，提供什么价值
4. 当前的客户他们所面对的问题是什么，对于目前的工作，他们喜欢什么，不喜欢什么。
5. 当前的客户具备什么样的知识水平，是否有学习的意愿，他们经常怎么去学。
6. 对于新软件所要管理的数据，或者信息，客户有什么是最担心的。
7. 客户习惯怎样的工作方式，新软件是否会与这些工作习惯合拍，或者是客户将要围绕这个软件做什么样的改变。
8. 用户有些什么样的习惯用语，表达什么样的意思。
分析你的用户：
用以下三个尺度来衡量你的用户：
1. 电脑操作知识
2. 业务理解知识
3. 系统认知
4. 是否有动力去学习这个系统
5. 是工作需要的，还是生活需要的, 还是用在客户那里的
6. 用户是否还有其他的选择
7. 用户的工作岗位，职位高低
8. 用户的教育程度
9. 用户的人品
衡量完成后，对于用户群体建立一个 user profile，用户档案
找出任务：
从以下几个方面可能可以找出用户所需要完成的Task
任务：（做幻灯片，填写营业报表，审批资金等）可以用 动词+名词的方式将其列出来。这些任务会符合以下的一些特性：
1.组织的策略目标，反映创立者，高层和股东的利益
2.雇员的期待
3.历史的工作任务
4.任务与目前的资产，流程 或者基础设施相关
5.任务能够反映用户对现有市场机遇的感知
分析任务：
对任务进行研究：
1.这些任务对于达成应用程序的总目标有什么作用
2.这些任务里面，哪些是通用的任务，哪些是独特的任务。
3.任务的优先级有哪些
4.每个任务的步骤有哪些
5.任务的输出是什么
6.任务的输入时什么，任务中怎么去应用这些输入.
7.任务分别是又谁负责
8.任务中经常会遇到什么样的问题，有些什么常常会遇见的错误，原因是什么，破坏性有多大
9.执行这些任务需要有些什么技能
10.任务之间有些什么联系
11.任务对某些人或者事有依赖性
获取Task以后，和用户Interview, 并且观察他们所做的工作。获取Task的详细目标可以采用以下的样例：
1.你在做这个Task的时候，是一个什么角色
2.是你自己亲自做这个Task，还是监督别人做的
3.做这个Task你需要的总工作量有多少
4.这个Task你是为谁而做的
5.这个Task有什么质量检查指标体系吗
6.有标准的格式或者模板可以采用吗
7.你用什么软件来完成这个Task
8.你只有一个软件，还是一组软件来完成的
9.谁来决定你用这个软件
10.你喜欢什么软件，或者是不喜欢什么软件
11.你可能需要什么软件来让Task更好完成
12.这个Task包含了什么步骤
13.怎么样才算完成了这个Task
14.你会需要重用到以前的数据来完成现在这个Task吗
15.怎么来跟踪这个Task的效果
设计的时候需要放眼软件最后即将是使用的环境，在全局的观点来审视这个设计。学习并研究那个环境。环境是指这个软件周围的人，流程，
场合或者是周围人使用的其他的系统
UI的原则二， 先考虑功能，再考虑展现。
功能的考虑，相信通过上面那组巨大的问题，已经描绘的差不多了，接下来该整理这些功能，抽象出功能，形成一种观念
先考虑的功能包括如下几个要素：
1.要展现的观念是什么 （观念：也就是我们所说的domain model，这些domain model的能力，属性，以及被操作的方式：如被展现，被查询等
鞥）
2.信息如何组织 （domain model之间的关系如何，比如继承，依赖，聚合，组合，等）
3.功能是什么
4.可定制性如何
最重要的是观念，先整理观念，以及各个观念之间的联系，然后再考虑怎么来体现这些观念。
回答另外一些问题：（采用域建模的方式）
和用户一起编排出一个词典
从用户的任务提取出该概念对象
确定概念对象之间的关系，比如继承关系，拥有关系
确定对概念对象的操作，执行
指定操作概念的场景
最后由场景发展出用户操作界面
和用户的观点保持一致， 不让用户执行和任务目标没有明显联系的操作。 让人生厌，并不容易记住
不要让用户做不自然地事情，（比如：多余的步骤，过多的用户私人信息填写）
采用用户熟悉的词汇，而不是开发人员熟悉的词汇，在做需求的时候就要特别注意用户的概念列表， 对于提到的对象（名词）， 所作的动作
（动词）， 和对象的属性（形容词）都要有一个概念列表将其记载
不要将软件的信息暴露给用户，比如软件的异常，软件的log等。 只显示概念模型所涉及到的部分。
减少用户所需要操作的功能，让常用的任务变得简单，是GUI设计的重要目标，做少量的工作，得到很多的结果
1.不让每个用户都从0开始，采用封装模板的方式。
2.采用恰当的默认值 比如生成schedule， 就可以copy/paste方式
3.采用指南性的路径和向导，比如银行客户端中的，汇款
4.比如配置MSP的lineup的时候，只让用户输入最简单，最必要的 headendId和networkId,而不需要手动去查询或者选择
zoneName,adcachename,以及channelName。输入的时候自动过滤掉那些已经存在的配置，避免错误。而不是用户输入错误之后再提示重新输入
。
对于所有的功能，都要定义出常用功能的范围：（对功能的重要程度进行排序，用以确定设计，或者界面。 不重要的功能稍微多些步骤没关系
，常用的功能一定要集中精力设计）
1.有多少人用这个功能
2.功能的使用频率是多少
3.功能越重要，使用时所需要点击的次数要越少
4.重要功能要非常明显
不要为边缘的情况，付出太多的工作， 比如我们的active, 我们的delete, add, update schedule. 核心场景是人们使用你程序的主要原
VISTA 用户体验是个失败的经典，它让用户过多的参与了安全的工作，让人生厌烦
讨论过程中不能分散用户的注意力，用户使用软件的时候应该是停留在业务层面上，而不应该来考虑界面怎么使用（比如说，讨论登录的时候
，不必要讨论指纹登录，还是输入框登录，或者是软键盘登录，以及加入标识码）。不能占用思维带宽
不要让用户去解决技术问题，不能让用户通过排除法来猜测软件是怎么工作的
促进学习：
界面需要能够促进学习这个软件；保证图解，文字，标签的明确性。提供一个低风险的环境，让用户尝试，学习。低风险的定义就是出错能随
时回到初始化的地方，比如一个logo的链接，导航，上下文链接，后退按钮等等
传递信息，而不是数据：
显示成用户了解的信息，而不是计算机了解的数据
1.通过视觉焦点，视觉顺序体现信息，比如说高亮。 但是高亮的时候，只能是最需要关注的部分高亮，关注结束要取消。
2.前后的一致性，描述的正确性，图解，标签的适当。细节体现在，注解前后一致， 描述的正确性，图标的适当精致，标签的效果，以及标签
的操作方式（比如closeOthers）
满足响应性：
用户对速度的理解是，感觉的速度，而不是实际速度。
响应时间： 交互软件可以有很高的响应事件，而很低的速度，响应是提高用户满意度的重要指标,响应差的实例有：
1.对于按下的按钮，滚动条，或者对象操作，反应迟钝：
2.阻碍其他活动的费时操作，不能停止
3.无线索,没有明确表示出操作花费的时间
4.不连贯的动画
5.软件内部任务执行时，忽略用户输入，让用户等待
响应佳的系统必须具有以下几个特性：
1.所有操作，不管完成与否，必定做出回答
2.用户知道系统何时忙碌，何时空闲
3.等待期间，用户可以做其他操作
4.用户可以结束冗长的操作
5.动画流畅，不一帧帧显示
6.用户能够判断操作需要花多少时间
通过用户的的测试，发现错误，这是极其有用的，但多数情况，用户发现错误，都是有代价的。
易用性测试，或者称为可用性测试，只是一种重要的开发方法，开发工具。 而不是评估GUI开发人员的方式。 开发人员不能抵触易用性的测试
。
第一章所总领的原则有：
1.研究你的用户，研究用户的任务，观念。考虑功能，概念，最后才是界面
2.不要让用户做不自然地事情，比如下棋的时候要切换模式...，不分散用户注意力
3.界面要能促进学习，采用习惯用法的图标，和表述，采用用户的模式
4.传递出来的应该是信息，而不是一堆数据，不要包含表现的技巧
5.具有很好的响应性，比起提高速度，成本低很多
整本书按照如下的思维行文：
1. 总领所有的原则， 研究用户，研究任务，研究领域，创建概念模型，衍生出界面
2. 控件的使用禁忌
3. 导航规则的禁忌
4. 文字描述的使用禁忌
5. 界面布局的规则
6. 用户交互的一些规则，任务焦点，多余步骤，暴露过多信息
7. 响应性的禁忌
8. GUI开发管理的禁忌
控件的禁忌
1.单选，复选禁忌
避免单个单选的按钮 (radio: yes i agrees)
避免一组复选按钮互斥 (checkbox: 100. checkbox: 200 checkbox:300)
避免将复选框当做单选 （checkbox :yes checkbox no）
避免非开关类的复选框 (checkbox: red)
避免使用反向复选框 （checkbox: Not open the dialog）, 同时使用正向和反向复选会使用户疑惑，分散用户注意力
2.正确使用命令按钮作为开关
命令按钮开关是一类比较容易出错的控件， 其必须有非常明显的，持久化的状态表示命令的执行状况。 明显非常重要，要符合用户的习惯用
法， 比如：文件夹的展开，合拢；按钮按下去但并未弹起来， 再按就弹起来；等等
3.Tab Panel不能被用作单选面板使用， Tab Panel是将一个大页面组织布局的方式，作为导航的控件来使用，而不是用来单选界面。
Tab的真正作用是导航，以及渐进式的使用，将界面隐藏起来，直到用户真正需要的时候再打开。
用户选择Tab本身的时候，不应该对后台数据产生任何影响，它只是起到导航的作用
Tab项目太多也不好，多个层次的跳动，比如widnow的property， 让用户很困惑。这种情况，在软件中，可以采用acorshion的方式，竖向折叠
卡+Tree菜单来解决(ADM的Menu), 或者是分类列表，比如amazon的分类列表
4.输入控件，不能用在只读的模式下，比如说Text Field只显示文字， Checkbox来表示状态， 应该换成Text，以及icon
对于冗长的不可编辑的文字，采用TextField是不得以的做法，比如安全条款，很多页的说明等。
另外就是在读数据的地方，输入数据，不另外使用界面也是交互的一个重要原则。
不能因为编码的方便而滥用输入文本框， 是用文本框之前，要好好考虑是否有更好，更便于用户使用的控件（比如 输入日期， 比如输入
email采用三段，名zzhonghe+公司sohu+域com）,我们应该非常保守地使用文本框进行输入。用于非结构化，自由格式的数据。 如： 描述，密
码定义，注释, 名称等。
输入框不能采用过于严格的控制，比如空格，符号的禁用。 借口是易于编码， 给用户造成的困惑就是难于输入，容易放弃。
5.动态菜单的使用，这是绝对不允许，而且是吃力不讨好的事情，给用户会造成相当大的困惑。 不能动态增加或者减少菜单子项目。 菜单子
项目可以被disable/enable，菜单栏目也可以增加或者移除。
6.默认值对于控件来说，最好要有一个合适的初始值。包括输入框，单选按钮，复选框，下拉框等等。 对于确实没有合适，并有意义默认值
的情况，可以加上None,other等来默认，或者采用下拉框，默认内容为提示选择的信息。为用户提供尽可能多的匹配。
不恰当的默认值比没有默认值危害大很多，所以要非常斟酌
导航的禁忌：
导航成功的目标：
用户目前在哪里
用户到过哪里
用户能去哪里
1.调用的窗口，不能没有名称，比如enter 框，输入某些数据， 要提示title，标题。知道目前在做什么， 而且要和点击的按钮名称一致。
目标就是不要求用户思考，并记住其已经调用的功能。 浏览器的title来标示，没有效果，它的作用只在于最小化的时候，能够识别
采用标示的CSS在导航栏中标记，这种做法也是可以的，采用多种方法，多次标示，这总是不会错的。
标题名应该是唯一的，不同的窗口，应该显示不同的标题名。编程的规则是： 将这些消息都整理在一个消息文件中集中管理，这样就不会轻易
重复
经常遇到的情况是，create 的窗口，和update的窗口，标题出现了重复，而没有处理
2.界面的目标应该明确，引导用户达到这个目标，并排除过多的干扰。比如，要点击某篇文章中的链接，然后进行续约， 但是在文章中出现了
N多其他的链接，会导致这个界面的目标失效。因为，很少有用户会仔细地阅读这篇文章。
所以界面应该主题明确，进行正确的引导。
提交的信息，比如submit, continue, ok 等等，最好只出现一次， 不能被其他链接干扰，导致用户点击失误，而白白填写表单
用户任务开始后，最好提供用户通道，让用户知道目前的进度，比如列出所有步骤等等。
ADM中，用户进行配置的时候，需要给出给出如下的步骤：
1.配置相关的headendId，根据MSP所支持的ZoneName来填写,同时也可以填写上zoneName的description
2.配置相关的channelName，检查是否重复，或者多个channelName其实是表示同一个channel，这个一般没问题。添加channelName的
description
3.由channelName,ZoneName,MSPName来配置headendId
用户可以随时退回到上面一个步骤，或者进入下一个步骤，中途数据不会丢失
3.导航栏中不应该显示自身的链接， 比如--> aa-->bb的最后一项，应该不是活动链接，而是不能点击的
4.界面中的对话框层次不应该太多， 一二级导航条显示具体页面， 三级功能按钮， 四级功能选项就到极限了。 5级是不能接受的。
层次太多，会分散用户的注意力。不知道如何返回
界面可以提供一个网站结构图来描述宏观视图，让用户有整体印象
对话框不能超过两层，功能指定参数确认等
如果确实有很多层次的话，可以采用detail面板（论坛里面那种）， 或者是将对话框插入到menu里面去
4.搜索功能不能冲突，最好只能出现一个，两个同时出现会让用户产生疑惑。如果确实搜索功能不同，而且需要同时出现，必须很明显得标示
出不同点。或者合并成一个搜索框，提供不同的模式
搜索框竞争将分散用户的注意力。
专门针对自己领域的搜索，需要把搜索的外观做得不同，容易通过图片，或者词语，暗示用户区分开来。
搜索结果需要分页，然后能够轻易跳转到任何页面
搜索结果应该将重要类容，能够区分出其他结果的内容放在最前面， 有意义的关键字词，放在最前， 而不是分类，链接等等， 命中结果应该
显示不同的内容，显示和强调重要的信息，最大限度地减少单击的次数。 很多软件的搜索结果很多，但是都显示得没有意义，没有关键词，让
用户无法找到有用的搜索结果。
搜索结果尤其需要注意到这一点，重点信息，有区别的信息放在最显眼的地方， 不然的话， 太容易给雷同的分类，关键字淹没了。
文字的禁忌：
不利于交流的文字：
1.术语表达了不同的意思，不同的术语表达了同一种意思。 我们需要一个message文件，然后将所有文字集中管理。这样做的原因是，我们的
用户会非常严格地从字面意义来考虑术语和意义。
好的做法是，创建1个词典， 公共概念使用行业术语。
词典需要专人去开发，维护，用户测试。
以下是一些经常用到的不一致的术语，我们的软件中会犯错的：
1. properties, atrribures, parameters, settings, recources
2. welcome window, introduction window
3. version revision
4. FAO, QNA
5. find, search, query, inquiry
6. server, service
7. exit , quit
8. order size, order quantity
9. stock symbl, instrument ID, instrument instr
10. task, step
11. specify , define
所以在定义这些常用的术语的时候，最好有个文档，message recourse, 然后所有的值，都从这个文档上面取。 这样便于所有程序员之间进行
沟通和维护。
常见的原因是使用了表单的数据库字段的名称，而没有使用输入标签上的文字:
比如提示密码，用户名不匹配的时候， 说username和password不匹配， 而不是会员账号和会员密码不匹配。 这样会照成用户误解，或者不必
要的思考。
另外一种原因是开发的疏忽，代码copy后，没有修改标签的术语，或者title的术语。如： update的用在了insert的表单里面。
如select， 只应该赋予一种含义： 选择，而不应该再用作selected， selection等，如我们的itemselecter的右边标签，改成to be present
会更加贴切。
总之，select经常会被乱用，值得好好注意。
用户不会知道memeber和record是指同一事物，而且可能不知道record在界面中是一个名词。
比如用户在查询时候，会去寻找有Search的文字，而对query产生疑问，或者会对其视而不见。
创建的词典，应该来源于任务的描述，而不是实现的描述。
创建的词典可以拿给用户进行测试， 让其在术语和含义之间进行连线，测试其思考的时间，如果一个术语，等用户扫描完所有的描述后，还没
有答案，说明术语有问题。即使用户多看几次描述连线正确，也需要修改这个术语。
含义不清的术语：
refuse 表示垃圾，或者拒绝
enter表示进入，或者输入数据
这时应该将不同的意思，采用不同的术语区分开来。
delete 和 remove只用一个
copy和duplicate只用一个
Find和search只用一个
目的是为了减少用户思考，不让用户混淆，这两个其实都是指示同一事物。
重合的概念，让用户很难去学习这个软件，避免同义词，避免模糊用语， 确定模糊用语要根据用户的术语测试来修复。
用词语的书写的一致体现在如下的一些地方：
1.大小写。Menu，Title,Command，Label。所有单词，第一个字母都大写，或者都不大写
2.全部加冠词，the An, a或者都不加
3.同一种类型的动作，采用相同的命令： show Detail, 或者全部 properties
4.消息，提示信息，句子末尾全部加上句号，或者全部都不加
5.要么都用简洁的词语，要么都用小句子
冗长的信息也会给用户造成麻烦，造成了文字噪音污染，让用户很难抓住重点。 用户一边急于操作，一边从文字中挑出几个字进行理解
冗长的链接也是难以接受的，一排冗长的链接，前面还有相同的词语，那简直是灾难
用户只会在界面上浏览，而不会阅读，通过浏览来导航
以开发人员为中心的文字：
开发人员文字积累出来的软件犹如外语版本(Geek)，而且没有替代的母语版本
比如说： mode(模式)， buffer, do a compare, finish an edit, user default value.
User Authetication == Login
Database == public Shared
Local == Private
Tree == Menu
Radio Button === Choice
Dialog == Message Box
String== Description String和dialog永远不能出现在程序的信息当中
Argument 容易被误解的词语
Recource Object 或者 client， Thin - Client Rich - Clinet
另外一种行话是： 将动词用作名词，
sells, buys （交易的股票）
catchs (捕获的鱼)
Find功能
find preference: --> Perference of Finding 查找属性， 查找功能的属性
Compare功能
Compare Difintion功能 --> Definition of Compare 比较功能 比较功能的属性
在做需求的时候就要特别注意用户的概念列表， 对于提到的对象（名词）， 所作的动作（动词）， 和对象的属性（形容词）都要有一个概念
列表将其记载
程序员的实现，其实最好也跟界面的术语保持一致，这样和用户沟通的时候能够更加方便
在用户界面中，不能将用户称作User, 而应该采用My来代替。（Visiter, Customer, Memeber）等可以用来代替User，user实际上是我们在实
现中使用的一种称呼
无用的消息，不应该显示给用户看， 比如“null” , type error, type exception等
没有指出错误原因的消息，比如用户文件未传导致的解析错误， 显示的是解析错误，用户并不知道是文件没传导致的。
采用通用的组件，提示的信息过于一致，没有明确出错误的原因
比如： File contain error character. 但是并不说，哪些不能包括，已经包括了哪些
好的错误提示消息，应该采用任务术语来表达错误的信息，另外还必须提供操作建议。错误信息中，也可以提供detail的系统消息，给关心它
的系统程序员使用，用户可以看，也可以不看。
底层的错误消息可以有两种处理方式：
1.翻译后，上传给用户
2.偶然因素引起的错误，重新执行一次操作
不同的错误信息，面向不同的对象：
最终用户
系统管理员
开发人员
错误处理框架应该明确的区分消息，用以确保其只能让固定类别的操作者看到。
最严重的消息错误：
1.显示了与情况不一致的消息， 比如用户输入了未来日期导致错误， 我们却提示他检查 是否输入了不合格日期，如 2月30日等
2.比如后台数据库宕机，导致不能查询，我们却说不支持这个词语的查询，当前的的查询不支持等。
确保正确的消息能够得到正确的提示。
测试数据库down, tomcat down, 网络down，数据库无数据，数据库数据错误的情况，确保能够得到正确的错误提示。
文字独立有意义：
比如三项 search now， 另外一项为 search， 那就会引起用户思考，这2个区别， search是用于以前数据的search吗？
按钮上省略号的标准在于， 点击后，在下级菜单中，会有输入性的界面。
界面布局的禁忌：
用户注意力的问题， 用户的注意力一般集中在光标闪烁周围的一小块地方，重要的信息，或者提示信息不能跑的太远（顶部，或者底部），注
意力以外的地方很难被用户观察到。
0.建立视觉层次结构，有逻辑关联的，视觉上也要关联在一起
1.采用高亮显示重要的信息，区别其他次要的信息。 高亮显示完毕，获取注意后，应该及时消除高亮的效果，以免造成噪音干扰，获取不到其
他信息
2.显示在视觉范围以内
3.消除干扰，不要显示很多雷同的信息，不然容易淹没重要的信息， 比如，很多normal,normal,normal中出现一个abnormal， 很容易被忽略
。
4.采用有效地图形或者符号，如告警产生的红色大叉
另外还有一些需要慎用的：
弹出窗口
声音
动画： 动画需要能够自动停止，很快停止，不然造成太大干扰
不仅仅显示数据， 更重要的是现实信息：
比如，显示一些成功率的信息， 与其给出一堆百分数，不如给出一个图表。
窗口控制按钮布局问题：
按钮一般包括两种： 数据操作按钮 add remove edit 等， 窗口操作按钮， help save ok cancel等
这两类按钮绝对不能放在一起， 在视觉上要有显著地差异才行
组合框的使用规则：
1.组合框是分组用的，所以里面必须包括多个元素， 只有1个元素的情况是不可以用组合框的
2.组合框没有必要嵌套，一个窗口的组合框，只能有1层
3.整个窗口就是一个组合框也是多余的
关键点就是，需要区分边界的时候就使用组合框
单选按钮：
1.选择按钮之间距离不能太大，可能会不像同一组
2.单选按钮和后面的文字不能太近，容易误会
3.并列的几排单选按钮要用组合框或者分割线区别，不然容易混淆其分组规则
标签与数据字段的距离：
1.左对齐，右对齐均可， 但是关键是 标签和字段的距离不能太长。
2.遇到特别长的标签，可以换行。或者就在这一行，减少数据字段的长度。防止少数标签影响长度。
3.数据字段不能和其他的标签挨着。要能够明显区分开来
4.或者将标签放置在数据字段的上面。
标签的对齐方式，在整个网站里面要保持一致，要么全部左对齐，要么全部右对齐
窗口显示的位置：
1.子窗口显示在父窗口的内部
2.新开的非子窗口，不能遮盖原来的窗口，必须向右下角偏出一部分位置，至少能看到，点击到父窗口。
字体不能太小：
CSS里面最好使用相对字体，而不是绝对字体，至少可以上用户控制字体， 而版面不会遭到破坏。
交互的原则：
1.不偏离用户的任务轨道
不能给出晦涩的程序语言提示，或者错误信息， 导致让用户像程序员一样思考，这样就偏离了任务轨道。主要体现在术语的选择，提示信息。
不能因为编码简单，而让用户来接受奇怪的，勉强可用的解决方案。
减少不必要的限制条件， 比如输入框中的密码格式， 没有太多必要的情况下不能太复杂。再有就是数据库限制的长度， 或者是特殊字符的包
含等。
2的次方限制, 输入的数据长度显示, 特殊字符限制,
程序员多花1，2小时的时间来解决限制的问题，可以为用户节省几十小时，甚至很多天的时间，这些时间里面，很多用户都被困扰
概念模型不清晰，导致的概念重复，影响思维模型，进而不知道怎么操作。新增的概念要有明确的目的，要删除和原有概念重叠的部分，一个
功能的两种实现会造成功能竞争，用户会因此而疑惑不解。增加学习成本。
2.减少不必要的步骤
程序员应该不怕麻烦，做竟可能多的事情来保证用户能够尽可能少的步骤来操作整个流程。
1.记录用户曾经输入过的东西，避免再次重复输入
2.有些数据可以计算出来，就可能省略用户的输入。比如 输入zipcode的地方就不因该再输入省份地名，因为这可以查询出来。
3.有些数据对后台可能有好处，但是对于用户的任务来说不是必须的，所以也要减少这种数据输入的需求。这是营销类的数据，可以单独开来
防止，可选区域
4.任何数据都不能是必须的，除非没有它就不能继续工作，不然获得的大部分是虚假数据
4.一个系统的登录，只应该有一次， 授权可以多次，但是登录应该只能有1次
减少用户操作步骤是一个很难的事情，实现很难，但是这是一个很重要的业务决策，需要去完成。如果开发人员不重视这个问题用以节省开发
时间和开发成本，那么将带来其他的错误的决策。
6.千万不要让用户给出一个随机数
不要让用户作出不必要的选择：
1.如果选项是用户所不知道的，用户不知道怎么选，就不要让用户选。这类选项是很难发现的，需要做易用测试
2.如果选项之间没有什么区别，或者是档案很显然的，就不要让其选择，直接给出答案。 能省略选择就省略
3.不能提供错误的答案选项，这是没有意义的选项。即使出现，也要标明其失效。而不是用户操作后，最后发现其失效了。
3.不能增加用户的记忆负担
1.界面功能设计中，不要试图让用户记住ID，比如随机的账号密码，PIN码等
2.不合理的密码约束，有些密码根本不能记住，必须写下来。
3.安全问题，提供有限的安全问题，用户无法回答。 用户的安全问题，必须是自己能够设置问题，然后设置答案才行，不然这个功能是无效的
。
重要的说明性文字， 向导， 步骤等， 需要能够一直显示，以确保用户在任务执行过程中能够一直看到。 别指望用户看完之后能够全部记在
脑子里面。 比如说： 操作有4步，第一步是关闭当前窗口， 第二步打开XXX界面，.. 用户关闭后，就不知道怎么做了。
去掉不必要的模式，采用无模式的替代方案。 模式的存在： 用户容易忘记模式的切换而操作失误。模式就是用户设置一个值，然后影响相同
操作所获得的结果。
弹性载入，是模式最好的体验。比如，按住shift 然后操作，就进入了一种模式， 放开shift就回到了原来的模式
4.不能夺走用户的控制权
用户的控制权体现在：
1.自动进行多余的排序
2.提示信息里面只有单一的选项按钮，不能拒绝。 所有选项都是错误的， 所需要的按钮是被禁用的。
3.控件不受控制地移动，菜单变动，自动移动窗口，光标变型， 选项卡自动跳动
4.标示不清晰的按钮文字，比如反向命令， not cancel 一个 取消安装的操作。
5.如果出现不能恢复的操作，the data is lost, shut down? 采用 understand, got it， 而不是ok
6.取消按钮需要能够有undo的作用，
比如编辑窗口里面，cancel可以取消所有编辑，而不是更改后台数据。
选项卡中的cancel可以undo所有tab中的编辑。
向导操作中的cancel可以退出所有的向导，下次还从头开始。
多层的对话框，比如修改密码， 子窗口确认了，父窗口的cancel可以cancel这次修改
程序响应禁忌：
响应性不是我们所说的性能，或者速度。 在有限的性能或者速度下，提高响应性
1.冗长的操作，需要有进度的提示，而且是真实的进度提示，不是虚假的。
2.冗长的操作，需要有一个cancel的方式，不能让用户无限制等待。
3.用户开始操作后，可以禁止掉接下来的操作，以免发生重复操作。至少让用户知道，这个操作已经在执行。 点击以后，要立刻有提示信息。
4.不能将暂时还没加载完成的界面提供给用户操作，即便只有十几秒也不行。
响应性不好会导致全盘皆输的效果，使得软件的其他特性变得无法吸引用户。
1. 专注于用户的任务，Task，而不是所谓的技术。
2. 时刻清楚谁是最终用户，最终用户使用你的软件所需要服务的对象是谁。
3. 软件做什么用的，支持什么活动，解决什么问题，提供什么价值
4. 当前的客户他们所面对的问题是什么，对于目前的工作，他们喜欢什么，不喜欢什么。
5. 当前的客户具备什么样的知识水平，是否有学习的意愿，他们经常怎么去学。
6. 对于新软件所要管理的数据，或者信息，客户有什么是最担心的。
7. 客户习惯怎样的工作方式，新软件是否会与这些工作习惯合拍，或者是客户将要围绕这个软件做什么样的改变。
8. 用户有些什么样的习惯用语，表达什么样的意思。
分析你的用户：
用以下三个尺度来衡量你的用户：
1. 电脑操作知识
2. 业务理解知识
3. 系统认知
4. 是否有动力去学习这个系统
5. 是工作需要的，还是生活需要的, 还是用在客户那里的
6. 用户是否还有其他的选择
7. 用户的工作岗位，职位高低
8. 用户的教育程度
9. 用户的人品
衡量完成后，对于用户群体建立一个 user profile，用户档案
找出任务：
从以下几个方面可能可以找出用户所需要完成的Task
任务：（做幻灯片，填写营业报表，审批资金等）可以用 动词+名词的方式将其列出来。这些任务会符合以下的一些特性：
1.组织的策略目标，反映创立者，高层和股东的利益
2.雇员的期待
3.历史的工作任务
4.任务与目前的资产，流程 或者基础设施相关
5.任务能够反映用户对现有市场机遇的感知
分析任务：
对任务进行研究：
1.这些任务对于达成应用程序的总目标有什么作用
2.这些任务里面，哪些是通用的任务，哪些是独特的任务。
3.任务的优先级有哪些
4.每个任务的步骤有哪些
5.任务的输出是什么
6.任务的输入时什么，任务中怎么去应用这些输入.
7.任务分别是又谁负责
8.任务中经常会遇到什么样的问题，有些什么常常会遇见的错误，原因是什么，破坏性有多大
9.执行这些任务需要有些什么技能
10.任务之间有些什么联系
11.任务对某些人或者事有依赖性
获取Task以后，和用户Interview, 并且观察他们所做的工作。获取Task的详细目标可以采用以下的样例：
1.你在做这个Task的时候，是一个什么角色
2.是你自己亲自做这个Task，还是监督别人做的
3.做这个Task你需要的总工作量有多少
4.这个Task你是为谁而做的
5.这个Task有什么质量检查指标体系吗
6.有标准的格式或者模板可以采用吗
7.你用什么软件来完成这个Task
8.你只有一个软件，还是一组软件来完成的
9.谁来决定你用这个软件
10.你喜欢什么软件，或者是不喜欢什么软件
11.你可能需要什么软件来让Task更好完成
12.这个Task包含了什么步骤
13.怎么样才算完成了这个Task
14.你会需要重用到以前的数据来完成现在这个Task吗
15.怎么来跟踪这个Task的效果
设计的时候需要放眼软件最后即将是使用的环境，在全局的观点来审视这个设计。学习并研究那个环境。环境是指这个软件周围的人，流程，
场合或者是周围人使用的其他的系统
UI的原则二， 先考虑功能，再考虑展现。
功能的考虑，相信通过上面那组巨大的问题，已经描绘的差不多了，接下来该整理这些功能，抽象出功能，形成一种观念
先考虑的功能包括如下几个要素：
1.要展现的观念是什么 （观念：也就是我们所说的domain model，这些domain model的能力，属性，以及被操作的方式：如被展现，被查询等
鞥）
2.信息如何组织 （domain model之间的关系如何，比如继承，依赖，聚合，组合，等）
3.功能是什么
4.可定制性如何
最重要的是观念，先整理观念，以及各个观念之间的联系，然后再考虑怎么来体现这些观念。
回答另外一些问题：（采用域建模的方式）
和用户一起编排出一个词典
从用户的任务提取出该概念对象
确定概念对象之间的关系，比如继承关系，拥有关系
确定对概念对象的操作，执行
指定操作概念的场景
最后由场景发展出用户操作界面
和用户的观点保持一致， 不让用户执行和任务目标没有明显联系的操作。 让人生厌，并不容易记住
不要让用户做不自然地事情，（比如：多余的步骤，过多的用户私人信息填写）
采用用户熟悉的词汇，而不是开发人员熟悉的词汇，在做需求的时候就要特别注意用户的概念列表， 对于提到的对象（名词）， 所作的动作
（动词）， 和对象的属性（形容词）都要有一个概念列表将其记载
不要将软件的信息暴露给用户，比如软件的异常，软件的log等。 只显示概念模型所涉及到的部分。
减少用户所需要操作的功能，让常用的任务变得简单，是GUI设计的重要目标，做少量的工作，得到很多的结果
1.不让每个用户都从0开始，采用封装模板的方式。
2.采用恰当的默认值 比如生成schedule， 就可以copy/paste方式
3.采用指南性的路径和向导，比如银行客户端中的，汇款
4.比如配置MSP的lineup的时候，只让用户输入最简单，最必要的 headendId和networkId,而不需要手动去查询或者选择
zoneName,adcachename,以及channelName。输入的时候自动过滤掉那些已经存在的配置，避免错误。而不是用户输入错误之后再提示重新输入
。
对于所有的功能，都要定义出常用功能的范围：（对功能的重要程度进行排序，用以确定设计，或者界面。 不重要的功能稍微多些步骤没关系
，常用的功能一定要集中精力设计）
1.有多少人用这个功能
2.功能的使用频率是多少
3.功能越重要，使用时所需要点击的次数要越少
4.重要功能要非常明显
不要为边缘的情况，付出太多的工作， 比如我们的active, 我们的delete, add, update schedule. 核心场景是人们使用你程序的主要原
VISTA 用户体验是个失败的经典，它让用户过多的参与了安全的工作，让人生厌烦
讨论过程中不能分散用户的注意力，用户使用软件的时候应该是停留在业务层面上，而不应该来考虑界面怎么使用（比如说，讨论登录的时候
，不必要讨论指纹登录，还是输入框登录，或者是软键盘登录，以及加入标识码）。不能占用思维带宽
不要让用户去解决技术问题，不能让用户通过排除法来猜测软件是怎么工作的
促进学习：
界面需要能够促进学习这个软件；保证图解，文字，标签的明确性。提供一个低风险的环境，让用户尝试，学习。低风险的定义就是出错能随
时回到初始化的地方，比如一个logo的链接，导航，上下文链接，后退按钮等等
传递信息，而不是数据：
显示成用户了解的信息，而不是计算机了解的数据
1.通过视觉焦点，视觉顺序体现信息，比如说高亮。 但是高亮的时候，只能是最需要关注的部分高亮，关注结束要取消。
2.前后的一致性，描述的正确性，图解，标签的适当。细节体现在，注解前后一致， 描述的正确性，图标的适当精致，标签的效果，以及标签
的操作方式（比如closeOthers）
满足响应性：
用户对速度的理解是，感觉的速度，而不是实际速度。
响应时间： 交互软件可以有很高的响应事件，而很低的速度，响应是提高用户满意度的重要指标,响应差的实例有：
1.对于按下的按钮，滚动条，或者对象操作，反应迟钝：
2.阻碍其他活动的费时操作，不能停止
3.无线索,没有明确表示出操作花费的时间
4.不连贯的动画
5.软件内部任务执行时，忽略用户输入，让用户等待
响应佳的系统必须具有以下几个特性：
1.所有操作，不管完成与否，必定做出回答
2.用户知道系统何时忙碌，何时空闲
3.等待期间，用户可以做其他操作
4.用户可以结束冗长的操作
5.动画流畅，不一帧帧显示
6.用户能够判断操作需要花多少时间
通过用户的的测试，发现错误，这是极其有用的，但多数情况，用户发现错误，都是有代价的。
易用性测试，或者称为可用性测试，只是一种重要的开发方法，开发工具。 而不是评估GUI开发人员的方式。 开发人员不能抵触易用性的测试
。
第一章所总领的原则有：
1.研究你的用户，研究用户的任务，观念。考虑功能，概念，最后才是界面
2.不要让用户做不自然地事情，比如下棋的时候要切换模式...，不分散用户注意力
3.界面要能促进学习，采用习惯用法的图标，和表述，采用用户的模式
4.传递出来的应该是信息，而不是一堆数据，不要包含表现的技巧
5.具有很好的响应性，比起提高速度，成本低很多
整本书按照如下的思维行文：
1. 总领所有的原则， 研究用户，研究任务，研究领域，创建概念模型，衍生出界面
2. 控件的使用禁忌
3. 导航规则的禁忌
4. 文字描述的使用禁忌
5. 界面布局的规则
6. 用户交互的一些规则，任务焦点，多余步骤，暴露过多信息
7. 响应性的禁忌
8. GUI开发管理的禁忌
控件的禁忌
1.单选，复选禁忌
避免单个单选的按钮 (radio: yes i agrees)
避免一组复选按钮互斥 (checkbox: 100. checkbox: 200 checkbox:300)
避免将复选框当做单选 （checkbox :yes checkbox no）
避免非开关类的复选框 (checkbox: red)
避免使用反向复选框 （checkbox: Not open the dialog）, 同时使用正向和反向复选会使用户疑惑，分散用户注意力
2.正确使用命令按钮作为开关
命令按钮开关是一类比较容易出错的控件， 其必须有非常明显的，持久化的状态表示命令的执行状况。 明显非常重要，要符合用户的习惯用
法， 比如：文件夹的展开，合拢；按钮按下去但并未弹起来， 再按就弹起来；等等
3.Tab Panel不能被用作单选面板使用， Tab Panel是将一个大页面组织布局的方式，作为导航的控件来使用，而不是用来单选界面。
Tab的真正作用是导航，以及渐进式的使用，将界面隐藏起来，直到用户真正需要的时候再打开。
用户选择Tab本身的时候，不应该对后台数据产生任何影响，它只是起到导航的作用
Tab项目太多也不好，多个层次的跳动，比如widnow的property， 让用户很困惑。这种情况，在软件中，可以采用acorshion的方式，竖向折叠
卡+Tree菜单来解决(ADM的Menu), 或者是分类列表，比如amazon的分类列表
4.输入控件，不能用在只读的模式下，比如说Text Field只显示文字， Checkbox来表示状态， 应该换成Text，以及icon
对于冗长的不可编辑的文字，采用TextField是不得以的做法，比如安全条款，很多页的说明等。
另外就是在读数据的地方，输入数据，不另外使用界面也是交互的一个重要原则。
不能因为编码的方便而滥用输入文本框， 是用文本框之前，要好好考虑是否有更好，更便于用户使用的控件（比如 输入日期， 比如输入
email采用三段，名zzhonghe+公司sohu+域com）,我们应该非常保守地使用文本框进行输入。用于非结构化，自由格式的数据。 如： 描述，密
码定义，注释, 名称等。
输入框不能采用过于严格的控制，比如空格，符号的禁用。 借口是易于编码， 给用户造成的困惑就是难于输入，容易放弃。
5.动态菜单的使用，这是绝对不允许，而且是吃力不讨好的事情，给用户会造成相当大的困惑。 不能动态增加或者减少菜单子项目。 菜单子
项目可以被disable/enable，菜单栏目也可以增加或者移除。
6.默认值对于控件来说，最好要有一个合适的初始值。包括输入框，单选按钮，复选框，下拉框等等。 对于确实没有合适，并有意义默认值
的情况，可以加上None,other等来默认，或者采用下拉框，默认内容为提示选择的信息。为用户提供尽可能多的匹配。
不恰当的默认值比没有默认值危害大很多，所以要非常斟酌
导航的禁忌：
导航成功的目标：
用户目前在哪里
用户到过哪里
用户能去哪里
1.调用的窗口，不能没有名称，比如enter 框，输入某些数据， 要提示title，标题。知道目前在做什么， 而且要和点击的按钮名称一致。
目标就是不要求用户思考，并记住其已经调用的功能。 浏览器的title来标示，没有效果，它的作用只在于最小化的时候，能够识别
采用标示的CSS在导航栏中标记，这种做法也是可以的，采用多种方法，多次标示，这总是不会错的。
标题名应该是唯一的，不同的窗口，应该显示不同的标题名。编程的规则是： 将这些消息都整理在一个消息文件中集中管理，这样就不会轻易
重复
经常遇到的情况是，create 的窗口，和update的窗口，标题出现了重复，而没有处理
2.界面的目标应该明确，引导用户达到这个目标，并排除过多的干扰。比如，要点击某篇文章中的链接，然后进行续约， 但是在文章中出现了
N多其他的链接，会导致这个界面的目标失效。因为，很少有用户会仔细地阅读这篇文章。
所以界面应该主题明确，进行正确的引导。
提交的信息，比如submit, continue, ok 等等，最好只出现一次， 不能被其他链接干扰，导致用户点击失误，而白白填写表单
用户任务开始后，最好提供用户通道，让用户知道目前的进度，比如列出所有步骤等等。
ADM中，用户进行配置的时候，需要给出给出如下的步骤：
1.配置相关的headendId，根据MSP所支持的ZoneName来填写,同时也可以填写上zoneName的description
2.配置相关的channelName，检查是否重复，或者多个channelName其实是表示同一个channel，这个一般没问题。添加channelName的
description
3.由channelName,ZoneName,MSPName来配置headendId
用户可以随时退回到上面一个步骤，或者进入下一个步骤，中途数据不会丢失
3.导航栏中不应该显示自身的链接， 比如--> aa-->bb的最后一项，应该不是活动链接，而是不能点击的
4.界面中的对话框层次不应该太多， 一二级导航条显示具体页面， 三级功能按钮， 四级功能选项就到极限了。 5级是不能接受的。
层次太多，会分散用户的注意力。不知道如何返回
界面可以提供一个网站结构图来描述宏观视图，让用户有整体印象
对话框不能超过两层，功能指定参数确认等
如果确实有很多层次的话，可以采用detail面板（论坛里面那种）， 或者是将对话框插入到menu里面去
4.搜索功能不能冲突，最好只能出现一个，两个同时出现会让用户产生疑惑。如果确实搜索功能不同，而且需要同时出现，必须很明显得标示
出不同点。或者合并成一个搜索框，提供不同的模式
搜索框竞争将分散用户的注意力。
专门针对自己领域的搜索，需要把搜索的外观做得不同，容易通过图片，或者词语，暗示用户区分开来。
搜索结果需要分页，然后能够轻易跳转到任何页面
搜索结果应该将重要类容，能够区分出其他结果的内容放在最前面， 有意义的关键字词，放在最前， 而不是分类，链接等等， 命中结果应该
显示不同的内容，显示和强调重要的信息，最大限度地减少单击的次数。 很多软件的搜索结果很多，但是都显示得没有意义，没有关键词，让
用户无法找到有用的搜索结果。
搜索结果尤其需要注意到这一点，重点信息，有区别的信息放在最显眼的地方， 不然的话， 太容易给雷同的分类，关键字淹没了。
文字的禁忌：
不利于交流的文字：
1.术语表达了不同的意思，不同的术语表达了同一种意思。 我们需要一个message文件，然后将所有文字集中管理。这样做的原因是，我们的
用户会非常严格地从字面意义来考虑术语和意义。
好的做法是，创建1个词典， 公共概念使用行业术语。
词典需要专人去开发，维护，用户测试。
以下是一些经常用到的不一致的术语，我们的软件中会犯错的：
1. properties, atrribures, parameters, settings, recources
2. welcome window, introduction window
3. version revision
4. FAO, QNA
5. find, search, query, inquiry
6. server, service
7. exit , quit
8. order size, order quantity
9. stock symbl, instrument ID, instrument instr
10. task, step
11. specify , define
所以在定义这些常用的术语的时候，最好有个文档，message recourse, 然后所有的值，都从这个文档上面取。 这样便于所有程序员之间进行
沟通和维护。
常见的原因是使用了表单的数据库字段的名称，而没有使用输入标签上的文字:
比如提示密码，用户名不匹配的时候， 说username和password不匹配， 而不是会员账号和会员密码不匹配。 这样会照成用户误解，或者不必
要的思考。
另外一种原因是开发的疏忽，代码copy后，没有修改标签的术语，或者title的术语。如： update的用在了insert的表单里面。
如select， 只应该赋予一种含义： 选择，而不应该再用作selected， selection等，如我们的itemselecter的右边标签，改成to be present
会更加贴切。
总之，select经常会被乱用，值得好好注意。
用户不会知道memeber和record是指同一事物，而且可能不知道record在界面中是一个名词。
比如用户在查询时候，会去寻找有Search的文字，而对query产生疑问，或者会对其视而不见。
创建的词典，应该来源于任务的描述，而不是实现的描述。
创建的词典可以拿给用户进行测试， 让其在术语和含义之间进行连线，测试其思考的时间，如果一个术语，等用户扫描完所有的描述后，还没
有答案，说明术语有问题。即使用户多看几次描述连线正确，也需要修改这个术语。
含义不清的术语：
refuse 表示垃圾，或者拒绝
enter表示进入，或者输入数据
这时应该将不同的意思，采用不同的术语区分开来。
delete 和 remove只用一个
copy和duplicate只用一个
Find和search只用一个
目的是为了减少用户思考，不让用户混淆，这两个其实都是指示同一事物。
重合的概念，让用户很难去学习这个软件，避免同义词，避免模糊用语， 确定模糊用语要根据用户的术语测试来修复。
用词语的书写的一致体现在如下的一些地方：
1.大小写。Menu，Title,Command，Label。所有单词，第一个字母都大写，或者都不大写
2.全部加冠词，the An, a或者都不加
3.同一种类型的动作，采用相同的命令： show Detail, 或者全部 properties
4.消息，提示信息，句子末尾全部加上句号，或者全部都不加
5.要么都用简洁的词语，要么都用小句子
冗长的信息也会给用户造成麻烦，造成了文字噪音污染，让用户很难抓住重点。 用户一边急于操作，一边从文字中挑出几个字进行理解
冗长的链接也是难以接受的，一排冗长的链接，前面还有相同的词语，那简直是灾难
用户只会在界面上浏览，而不会阅读，通过浏览来导航
以开发人员为中心的文字：
开发人员文字积累出来的软件犹如外语版本(Geek)，而且没有替代的母语版本
比如说： mode(模式)， buffer, do a compare, finish an edit, user default value.
User Authetication == Login
Database == public Shared
Local == Private
Tree == Menu
Radio Button === Choice
Dialog == Message Box
String== Description String和dialog永远不能出现在程序的信息当中
Argument 容易被误解的词语
Recource Object 或者 client， Thin - Client Rich - Clinet
另外一种行话是： 将动词用作名词，
sells, buys （交易的股票）
catchs (捕获的鱼)
Find功能
find preference: --> Perference of Finding 查找属性， 查找功能的属性
Compare功能
Compare Difintion功能 --> Definition of Compare 比较功能 比较功能的属性
在做需求的时候就要特别注意用户的概念列表， 对于提到的对象（名词）， 所作的动作（动词）， 和对象的属性（形容词）都要有一个概念
列表将其记载
程序员的实现，其实最好也跟界面的术语保持一致，这样和用户沟通的时候能够更加方便
在用户界面中，不能将用户称作User, 而应该采用My来代替。（Visiter, Customer, Memeber）等可以用来代替User，user实际上是我们在实
现中使用的一种称呼
无用的消息，不应该显示给用户看， 比如“null” , type error, type exception等
没有指出错误原因的消息，比如用户文件未传导致的解析错误， 显示的是解析错误，用户并不知道是文件没传导致的。
采用通用的组件，提示的信息过于一致，没有明确出错误的原因
比如： File contain error character. 但是并不说，哪些不能包括，已经包括了哪些
好的错误提示消息，应该采用任务术语来表达错误的信息，另外还必须提供操作建议。错误信息中，也可以提供detail的系统消息，给关心它
的系统程序员使用，用户可以看，也可以不看。
底层的错误消息可以有两种处理方式：
1.翻译后，上传给用户
2.偶然因素引起的错误，重新执行一次操作
不同的错误信息，面向不同的对象：
最终用户
系统管理员
开发人员
错误处理框架应该明确的区分消息，用以确保其只能让固定类别的操作者看到。
最严重的消息错误：
1.显示了与情况不一致的消息， 比如用户输入了未来日期导致错误， 我们却提示他检查 是否输入了不合格日期，如 2月30日等
2.比如后台数据库宕机，导致不能查询，我们却说不支持这个词语的查询，当前的的查询不支持等。
确保正确的消息能够得到正确的提示。
测试数据库down, tomcat down, 网络down，数据库无数据，数据库数据错误的情况，确保能够得到正确的错误提示。
文字独立有意义：
比如三项 search now， 另外一项为 search， 那就会引起用户思考，这2个区别， search是用于以前数据的search吗？
按钮上省略号的标准在于， 点击后，在下级菜单中，会有输入性的界面。
界面布局的禁忌：
用户注意力的问题， 用户的注意力一般集中在光标闪烁周围的一小块地方，重要的信息，或者提示信息不能跑的太远（顶部，或者底部），注
意力以外的地方很难被用户观察到。
0.建立视觉层次结构，有逻辑关联的，视觉上也要关联在一起
1.采用高亮显示重要的信息，区别其他次要的信息。 高亮显示完毕，获取注意后，应该及时消除高亮的效果，以免造成噪音干扰，获取不到其
他信息
2.显示在视觉范围以内
3.消除干扰，不要显示很多雷同的信息，不然容易淹没重要的信息， 比如，很多normal,normal,normal中出现一个abnormal， 很容易被忽略
。
4.采用有效地图形或者符号，如告警产生的红色大叉
另外还有一些需要慎用的：
弹出窗口
声音
动画： 动画需要能够自动停止，很快停止，不然造成太大干扰
不仅仅显示数据， 更重要的是现实信息：
比如，显示一些成功率的信息， 与其给出一堆百分数，不如给出一个图表。
窗口控制按钮布局问题：
按钮一般包括两种： 数据操作按钮 add remove edit 等， 窗口操作按钮， help save ok cancel等
这两类按钮绝对不能放在一起， 在视觉上要有显著地差异才行
组合框的使用规则：
1.组合框是分组用的，所以里面必须包括多个元素， 只有1个元素的情况是不可以用组合框的
2.组合框没有必要嵌套，一个窗口的组合框，只能有1层
3.整个窗口就是一个组合框也是多余的
关键点就是，需要区分边界的时候就使用组合框
单选按钮：
1.选择按钮之间距离不能太大，可能会不像同一组
2.单选按钮和后面的文字不能太近，容易误会
3.并列的几排单选按钮要用组合框或者分割线区别，不然容易混淆其分组规则
标签与数据字段的距离：
1.左对齐，右对齐均可， 但是关键是 标签和字段的距离不能太长。
2.遇到特别长的标签，可以换行。或者就在这一行，减少数据字段的长度。防止少数标签影响长度。
3.数据字段不能和其他的标签挨着。要能够明显区分开来
4.或者将标签放置在数据字段的上面。
标签的对齐方式，在整个网站里面要保持一致，要么全部左对齐，要么全部右对齐
窗口显示的位置：
1.子窗口显示在父窗口的内部
2.新开的非子窗口，不能遮盖原来的窗口，必须向右下角偏出一部分位置，至少能看到，点击到父窗口。
字体不能太小：
CSS里面最好使用相对字体，而不是绝对字体，至少可以上用户控制字体， 而版面不会遭到破坏。
交互的原则：
1.不偏离用户的任务轨道
不能给出晦涩的程序语言提示，或者错误信息， 导致让用户像程序员一样思考，这样就偏离了任务轨道。主要体现在术语的选择，提示信息。
不能因为编码简单，而让用户来接受奇怪的，勉强可用的解决方案。
减少不必要的限制条件， 比如输入框中的密码格式， 没有太多必要的情况下不能太复杂。再有就是数据库限制的长度， 或者是特殊字符的包
含等。
2的次方限制, 输入的数据长度显示, 特殊字符限制,
程序员多花1，2小时的时间来解决限制的问题，可以为用户节省几十小时，甚至很多天的时间，这些时间里面，很多用户都被困扰
概念模型不清晰，导致的概念重复，影响思维模型，进而不知道怎么操作。新增的概念要有明确的目的，要删除和原有概念重叠的部分，一个
功能的两种实现会造成功能竞争，用户会因此而疑惑不解。增加学习成本。
2.减少不必要的步骤
程序员应该不怕麻烦，做竟可能多的事情来保证用户能够尽可能少的步骤来操作整个流程。
1.记录用户曾经输入过的东西，避免再次重复输入
2.有些数据可以计算出来，就可能省略用户的输入。比如 输入zipcode的地方就不因该再输入省份地名，因为这可以查询出来。
3.有些数据对后台可能有好处，但是对于用户的任务来说不是必须的，所以也要减少这种数据输入的需求。这是营销类的数据，可以单独开来
防止，可选区域
4.任何数据都不能是必须的，除非没有它就不能继续工作，不然获得的大部分是虚假数据
4.一个系统的登录，只应该有一次， 授权可以多次，但是登录应该只能有1次
减少用户操作步骤是一个很难的事情，实现很难，但是这是一个很重要的业务决策，需要去完成。如果开发人员不重视这个问题用以节省开发
时间和开发成本，那么将带来其他的错误的决策。
6.千万不要让用户给出一个随机数
不要让用户作出不必要的选择：
1.如果选项是用户所不知道的，用户不知道怎么选，就不要让用户选。这类选项是很难发现的，需要做易用测试
2.如果选项之间没有什么区别，或者是档案很显然的，就不要让其选择，直接给出答案。 能省略选择就省略
3.不能提供错误的答案选项，这是没有意义的选项。即使出现，也要标明其失效。而不是用户操作后，最后发现其失效了。
3.不能增加用户的记忆负担
1.界面功能设计中，不要试图让用户记住ID，比如随机的账号密码，PIN码等
2.不合理的密码约束，有些密码根本不能记住，必须写下来。
3.安全问题，提供有限的安全问题，用户无法回答。 用户的安全问题，必须是自己能够设置问题，然后设置答案才行，不然这个功能是无效的
。
重要的说明性文字， 向导， 步骤等， 需要能够一直显示，以确保用户在任务执行过程中能够一直看到。 别指望用户看完之后能够全部记在
脑子里面。 比如说： 操作有4步，第一步是关闭当前窗口， 第二步打开XXX界面，.. 用户关闭后，就不知道怎么做了。
去掉不必要的模式，采用无模式的替代方案。 模式的存在： 用户容易忘记模式的切换而操作失误。模式就是用户设置一个值，然后影响相同
操作所获得的结果。
弹性载入，是模式最好的体验。比如，按住shift 然后操作，就进入了一种模式， 放开shift就回到了原来的模式
4.不能夺走用户的控制权
用户的控制权体现在：
1.自动进行多余的排序
2.提示信息里面只有单一的选项按钮，不能拒绝。 所有选项都是错误的， 所需要的按钮是被禁用的。
3.控件不受控制地移动，菜单变动，自动移动窗口，光标变型， 选项卡自动跳动
4.标示不清晰的按钮文字，比如反向命令， not cancel 一个 取消安装的操作。
5.如果出现不能恢复的操作，the data is lost, shut down? 采用 understand, got it， 而不是ok
6.取消按钮需要能够有undo的作用，
比如编辑窗口里面，cancel可以取消所有编辑，而不是更改后台数据。
选项卡中的cancel可以undo所有tab中的编辑。
向导操作中的cancel可以退出所有的向导，下次还从头开始。
多层的对话框，比如修改密码， 子窗口确认了，父窗口的cancel可以cancel这次修改
程序响应禁忌：
响应性不是我们所说的性能，或者速度。 在有限的性能或者速度下，提高响应性
1.冗长的操作，需要有进度的提示，而且是真实的进度提示，不是虚假的。
2.冗长的操作，需要有一个cancel的方式，不能让用户无限制等待。
3.用户开始操作后，可以禁止掉接下来的操作，以免发生重复操作。至少让用户知道，这个操作已经在执行。 点击以后，要立刻有提示信息。
4.不能将暂时还没加载完成的界面提供给用户操作，即便只有十几秒也不行。
响应性不好会导致全盘皆输的效果，使得软件的其他特性变得无法吸引用户。
2254
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
