登录
4、遗漏的命令
1）状态转换
大多数程序从一个状态转到另一个状态，在你选择某个菜单项或者提交一个命令之前，程序处于某种状态。为了回应你的选择，程序回到另一个状态。程序员通常会对他们的代码进行足够的测试，以确保你能达到任何你应该可以达到的状态。
――什么都不作就退出（状态返回）
你应该能够告诉应用程序，你做出的最后一个选择有误，并返回到其前一个状态。
――不能在程序中间退出
当使用一个程序但还没有对存储的数据造成不利影响时，你应该能够从中退出；如果你正在编辑的文件出现了预想不到的错误，在中止后应能回到先前保存过的状态。
――不能在命令中间停止
告诉程序停止一个命令很容易，而返回到起始点或选择一个其他的命令也应该不太难。如果其中任何一个方面出现了问题，就需要重新考量先前的设计是否真的合理了。
――不能暂停
如果程序限定了你输入的时间，时间一到，状态就改变，那么当你离开时你就需要它暂停一会儿。这中类型的情况在游戏软件中见得较多，比如说暂停游戏。
2）危机预防
系统故障和用户错误发生了，程序应具备将其后果降到最低的能力。
――没有备份工具
对开发人员而言，为了一个文件做一个额外备份应该不是一件困难的事。如果你正在修改一个文件，计算机应当保留原始版本的一个副本，因此如果你的更改有错误，还能返回到一个已知的好的版本。
――不能撤销
撤销一个你已经发出的编辑命令，至少是一步。恢复被删除的文件是一种受限制的撤销，它能让你恢复错误删除的数据。撤销是可取的，恢复被删除文件也应是必须的。
――没有“你确定吗？“的提示
提交一个大量数据清除的工作，或者提出一个清除少量数据但是会影响其他作业的命令或者很容易错误提交的命令，都需要程序在用户操作时进行确认，不声不响地进行将会带来安全方面的隐患（尤其是在后台进行暗箱操作时，这种危险性更高）。
――没有增量保存
当输入大量文本或数据时，你应该能告诉程序相隔一定时间对你的工作进行保存，至少应该提供用户此类选项。对于突发的掉电和硬件损坏情况这样做将是非常有好处的。
3）由用户进行的错误处理
人们可以捕获自己的错误，而经验告诉我们，他们还容易犯其他的错误。他们应能自理修复错误，并建立自己的错误检查机制。
――没有用户能指定的过滤器
当设计数据录入表格和电子表格模板时，你应该能够让每个区域指定什么样的数据类型有效、程序应忽略或拒绝什么。例如，你可以让程序拒绝数字、字母、不在某个特定范围内的数值，一个有效日期或者与磁盘上匹配的日期等等。
――难用的错误更正
修改一个错误应该很容易。不应该因为犯了错误的数据录入而让整个系统重新启动。在输入一串数据时，你应该能在不重新输入剩余部分的情况下，更正错误的数据。
――不能包括注释
当设计数据录入表格，电子模板，专家系统时，你应该能够为未来参考和调试输入注释信息，这是很必要的。
――不能显示变量之间的关系
录入表格、电子模板中有些变量是相互关联的，应该能很容易的检查任意变量对其他变量的依赖性。这在设计时应该被周密考虑到。在大多数的财务管理系统中，这类应用是较普遍的。
4）其他问题
――隐私和安全性
对于某些特定的程序，需要考虑数据的充分安全性，保护公司，集体或个人的机密和隐私。在多用户系统上，你应该能很好的隐藏你的文件（一般都是通过加密手段实现的），并且能很好的锁定你的文件不被篡改或阅读。
――安全性的困扰
一个程序的安全性控制应尽可能谨慎考虑与实施。
――隐藏菜单
很多程序在顶端、底部或屏幕边缘显示一个菜单（包括我以前测试的大多数应用程序）。它们使用屏幕的剩余部分作为数据录入和处理的区域。菜单只是记忆的辅助物。一旦用户了解了他所需要的所有命令后，就应该给予用户充分的自由，让其选择是否需要保留菜单的权力。
――不支持标准O/S特征
例如：如果系统使用了子目录，那么程序就应该能引用其他子目录。如果操作系统提供了通配符（比如*），那么程序也应该能使用。
――不允许长名称
应当允许使用长名称（只要不是太离谱），毕竟，内存不足和编译器反应迟钝的时代已经成为过去了。别让自己的程序也成了文物。
5、程序僵化
程序有灵活与固定之分。灵活的程序更显个性化一些，而固定僵化的程序一般都是由于业务流程的关系而不得不如此。如借还书的过程，必先借了才能还。别给用户太多的自由，否则程序看起来会让人觉得松散，也不要把程序定得死死的，那看上去给人太多压力了。
1）用户可调整性
――不能关掉噪音
犯错误时，许多程序都会给出“咄”的警告声。而如果每次接触键盘都发声，这简直是不能容忍的――特别是在公共场所。必须关闭没有必要的噪音，至少程序要提供这类控制选项。
――不能关闭大小写区分
一个能区分大小写的系统应该允许你告诉它忽略大小写的问题。
――不能配合手边的硬件
有些程序被锁定针对了特定的输入输出程序。升级或更换了设备的用户可能就无法使用这些功能了。这是令人遗憾的。同时，也会让用户觉得是否是一种商业捆绑的模式而拒绝使用此产品。尽量让开发人员编写通用的硬件接口代码以适应大部分通用的硬件设备。
――不能改变设备初始化
一个应用程序应该能够发送用户定义的初始状态，或者至少应该让它保持现状。每次启动都需要重新配置将会是很烦人的工作。假定你想要向一个打印机发送 控制代码，以转换到压缩字符，如果打印数据的程序不让你初始化打印机，你就不得不从设备来改变打印机的模式和状态，然后重新运行程序。如果程序阻挠了你的 打印机设置，那就是一个设计错误。
――不能关闭自动保存
自动保存是件好事，不过无事生非也是一件糟糕的事情。过于频繁的自动保存可能会让用户觉得程序不可靠。所以还是老老实实加上关闭自动保存的选项吧。
――不能改变滚动速度
严格来说，这不是一个很严重的问题。目前很多的设备驱动中已经提供了此类选项。
――不能重复上次的操作
这样的例子比如Word软件中的Redo。
――无法找到你上次完成的内容
此类问题对数据编辑特别是文本编辑类的程序较为常见。应当提供保存的文件列表，除非用户禁止了它。
――无法执行一个定制的命令
在程序选项中，一旦对其更改，应该立即生效，不需要再次重新启动程序进行加载――特殊情况除外（如果你无法避免）。
――无法保存定制的命令
你不应该只告诉程序此次运行关闭了警告声，而是应该让程序永远可以关闭这些――只要设置没有发生变化。
――特征更改的副作用
这种情况较常见，修改了某一个特征，相关的特征也会改变。如果确实存在副作用，应当在手册和屏幕中提供详实的文档证明和提示。
――无限可调整性
开发人员可以改变某些程序的方方面面。但是在开篇时说过，提供了太多灵活性的程序并非一直都是一件好事。好好斟酌再做决定要比草率地修改来得更好。
