登录
3、命令结构和录入
这里只处理实现中的缺陷。（即假定程序员对风格的选择是合理的）
不一致性
增加永真规则的数量可以缩短学习时间，并减少文档，而且使程序看上去更专业。不一致性如此的普遍，是因为它需要规划并进行斗争来选择能一直遵循的操 作规则。每个微小的不一致性都是不重要的，但是一旦达到了一定量，一个本来构想很好的产品有可能会变得难以使用，甚至变成废品。从开发人员本身来讲，也体 现出其开发本身的严密性。一个好的测试实践要标注出所有发现的不一致性，无论多么微不足道都要如此。
“最优化”
程序员有时候会有意引入不一致性来对程序进行优化。的确很吸引人，但是也要注意优化所带来的风险和一些优化的必要性：保存一两次按键操作是否与学习时间的增加或信任度的减少价值相当？未必。
――不一致的缩写
如果没有很明确的缩写规则，缩写就不能容易地被记住。把Delete缩写为Del，把Grep缩写为Grep，是没有任何意义的。
――不一致的终止规则
程序应该为多重键录入要求终结符。
――不一致的命令选项
如果一个选项对两个或者更多的命令有意义，那么它就应该对这些命令都可用（都不可用），它应该具有同样的名称，并且应该在两种情况下以同样的顺序被调用。
――名称相似的命令
如果两个命令名称相似，就很容易搞混。尽量不要使用相似的名称命名命令。这个问题在中文界面的软件中表现得尤为突出。
――不一致的大写
如果命令录入是区分大小写的，所有命令的第一个字符都应该使用大写（小写）。命令中嵌入单词的第一个字符应该一直大写（小写）。另外，如非必要，不要在一个命令中使用多国语言。
――不一致的菜单位置
如果同一命令在不同子菜单中出现，那么要在不同菜单的同一位置保留同一命令是很困难的。这句话不是很好理解，不过把话说白了就好理解很多：要保持命令在同一子菜单中的位置，而不是让它东搬西迁在其他的子菜单中停留。
――不一致的功能键用途与其说明
功能键的意义在程序中应始终保持一致（颠倒或是功能冲突是不能接受的）。
――不一致的错误处理规则
当程序检测到一个错误之后，它可能会公布该错误，或者尝试更正错误。任何一个程序的行为都应该是可预测的。如果当提交错误数据时没有任何的提示或尝试更正错误的说明，那么用户就无法确认数据是否是干净的。
――不一致的编辑规则
当你输入或稍后检查任何数据时，同样的键和命令应该可以用来对其进行修改。
――不一致的数据保存规则
应该在每处都以同样的方式，在同样的时间和范围内保存数据。它不应该在每个区域输入数据时保存数据，而其他时间则在一个记录、一组记录的末尾保存数据，或恰好在退出前保存数据。
――浪费时间
看起来为了浪费时间而进行的设计会激怒每个人，应该把时间花在更有意义的事情上去。
――曲折路径
如果为了到达想要的命令，你必须一个接一个做出选择。结果到最后发现，该命令不存在、不能实现或者要求你先完成某件事甚至几件事后才能使用――明显 的欺诈行为！相信客户的不满和你（测试人员）的不满几乎没有任何区别。举个例子说：当用户辛辛苦苦填满了整整一页的数据，最后提交时发现：该页数据中的某 项已经被使用了时，用户的焦躁可想而知。
――不能采用的选择
事实上没有任何接口在一个不能建立的菜单中包含选择项。如果没有任何数据存在，你如何评审、保存和擦除数据？没有打印机，如何打印文档？有的命令不 适合出现在某些条件下（虽然对使用没有什么影响），但是开发人员可能为了图方便而保留了此类命令（很遗憾地说：这太不专业了）；有时候，程序会提示寻求帮 助，而当你真的去使用的时候，程序却告诉你“您没有使用帮助的权限”――面对可望而不可及的东西，很多人宁愿选择不去看见。这种情况很常见，至于常常被开 发人员和测试人员共同忽略――但这是不应该存在的错误。
――你真的，真的确定么？
严重毁坏数据的命令需要这样重复的确认。是的，这是必须的，如：对一个写满数据的硬盘进行格式化的确需要多次确认。但是没有必要对每个细小的删除操 作进行繁复的确认操作，用户会变得不耐烦，其结果有可能是：当用户真的在进行严重毁坏性命令时，无视屏幕提示，造成不可预计的后果。
――模糊不清或者带有个人风格的命令
命令名应该明确指示该命令的作用。不要让用户一边使用软件，一边查询用户手册中关于该命令的解释。调查表明：大多数用户在使用软件产品的时候只对软 件手册做大概的了解，甚至根本不阅读。别指望用户会很完整地阅读手册，那是我们的工作。没有任何理由在发布的程序中生成如：finger等带有明显个人风 格的命令，当然，如果在程序中出现了脏话，我希望（仅仅是希望）客户没有气到火冒三丈。
菜单
菜单应该尽量简洁，当存在了太多风格不一，冗长和拙劣的图标或命令名，以及当选择隐藏在不明显的主题之下的子项时，理解它们将会变得非常复杂。一个菜单覆盖的命令越多，无论如何规划，都会变得复杂，如果没有良好的规划，这对用户的使用将是一大障碍。
――过于复杂的菜单层次
如果必须在最后到达你想要的命令之前很吃力地通过一个又一个菜单，那么我想我会选择使用另外一个功能相近的程序。创建深层菜单树的程序员所引用的设 计规则表明，没有哪个菜单应该具有七个以上的选项，这一点对新手来说可能时最好的。有经验的用户更倾向于每个菜单级别有更多选择，犯更少错误并更快速有效 的做出反应，只要选项能合理组织，整齐排版，而且没有可笑的拥挤或拼写错误就行了。
－不适当的菜单导航系统
即使在一个最适当的深层菜单系统中，你也必须能够返回到前一菜单，或者移到菜单结构的顶层，并能在任何时刻离开程序。
――太多路径到达相同位置
如果许多命令在菜单中重复出现，那么程序就需要重新组织。让一个命令在不同位置重复可能会很便捷，但是存在一定的限制。如果感觉上你可以从程序的任何位置到达另一个任意位置――那就得重新考虑下程序的内部结构和可靠性。
――相关的命令被归属到不相关的菜单
把一个复杂菜单中对命令或主题进行分组并不是一件容易的事情。人们都很容易忽视两项之间明显关系，并把它们分配到分开的菜单中去，当需要对此进行调整时，我们需要做的是：解释两项之间的关系，并建议两者都应属于哪个菜单。
――不相关命令被放置到同一菜单下
有些命令被扔到了完全无关的菜单下，这样并不好，宁可重新选择一个更高级别的标题并重新组织这些命令也不要那么做――如果那样做导致的混乱比较严重的话。
――键盘不能正确使用
不能正确使用键盘无论在何时都是一个问题。
――无法使用编辑键或功能键
如果一个程序从某些其他没有这些键的机器上移植过来，那没关系。相反可能就不行。要确保程序可以使用已有的编辑键和功能键。
――光标和编辑键的非标准使用
这些键应该按照他们通常在该机器上工作的方式进行工作，而不是按照他们通常在其他某个机器上工作的方式来工作。
――功能键的非标准使用
如果大多数程序用F1作为帮助键，那么如果在程序中将它定义为其他的功能，那将是不合适的。
――不能过滤无效键
程序应该能挡住并抛弃无效字符，比如进行数字相加时输入的字母。它不应该做出回应。与错误消息相比，这样做更快更有效。
――未能指示键盘状态的改变。
键盘上的灯或屏幕信息应该告诉你何时你的Num Lock键和其他类似的状态转换特征是开着的。
――未能扫描功能键或快捷键
你应该能够告诉计算机从它正在进行的工作中退出；程序应该总是能辨别出任何其他系统指定的键――即那些本机上的程序通常可以很快识别出来的键。
