当用户或系统出错时与用户交互

在理想世界里，软件与硬件都会无故障地一直工作下去，用户也从不出错。而现实中错误总是难免的。决定当事情出毛病时应用程序如何响应，是用户界面设计的一部分。

常用的响应是显示一个对话框，要求用户输入应用程序该如何处理这个问题。不太常用（但更好）的响应是简单地解决问题而不打扰用户。毕竟，用户主要关心的是完成任务，而不是技术细节。在设计用户界面时，考虑可能出现的错误，并判断哪一个需要用户交互作用，哪一个可以按事先安排的方案解决。

创建容易理解的对话框

偶尔应用程序中会出现错误，需要为解决这种情况做出判断。这通常作为代码的分支出现－ If...Then 语句或者 Case 语句。如果这个判断需要与用户交互，此问题通常用对话框来提交用户。对话框是用户界面的一部分，象界面的其他部分一样，它们的设计在应用程序可用性中发挥了作用。

有时有这样的感觉，好象许多程序对话框的设计员，不会讲使人容易理解的话。比如这样的消息：“硬盘 C 的扇区被损坏或不能访问。中止、重试、忽略？”（见图 6.22 ）这对一般的用户而言不大好理解。这等于有侍者问顾客：“我们没有汤或者厨房正在生火，中止、重试、忽略？”您会如何回答呢？以用户能理解的方式或短语描述问题（和选择）是重要的。在前面的例子中，更好的消息可以是“在 C 盘上存文件有问题，请把文件存于 A 盘。存不存文件？”

图 6.22 哪个对话框表示的消息最明确？

当为应用程序创建对话框时，心里想着用户。这个消息给用户传达了有用的信息吗？它容易理解吗？命令按钮表示的选择明确吗？这选择适合给定的条件吗？记住，仅仅一个讨厌的消息框就会使用户对应用程序产生坏印象。

如果正在设计自定义对话框，尽量坚持用标准类型。如果与标准消息框布局相差太远，用户可能不会把它认作是对话框。

详细信息 关于对话框的详细内容，请参阅本章前面的“对话框”。

不用对话框的错误处理

当错误出现时不一定要打断用户。有时更可取的是不通知用户而用代码来处理错误，或者以不停止用户工作流程的方法来提醒用户。这个技术的很好的例子是 Microsoft Word 中的“自动更正”功能：如果普通单词拼错了，Word 自动修改它；如果不常用单词拼错了，在其下划一条红线提醒用户以后改正。

有大量的技术可以使用；哪些技术适用于应用程序应由自己决定。这里有几个建议：

• 在“编辑”菜单中添加“撤消”功能。对于删除等情况，与其用“确定”对话框来打断用户，还不如确保他们作出正确的决定并提供“撤消”功能以备他们以后改变主意。
  
  
• 在状态栏或图标上显示消息。如果错误不影响用户当前的任务，不要停止应用程序。使用状态栏或亮色警告图标来警告用户— 当他们准备好后可以处理该问题。
  
  
• 改正问题。有时错误的解决办法很显然。例如，当用户试图存文件时磁盘已满，则在其他驱动器中检查系统寻找空间。如果空间可用，则保存该文件；在状态栏中显示一条消息告诉用户做了些什么。
  
  
• 保存消息等候处理。因为不是所有的错误都是紧要的，或要求马上注意的；考虑把这些记录到文件中，当用户退出应用程序时或其他方便的时候再把它们显示给用户。如果用户发生输入错误（如：把 Main St. 写成 Mian St.），记录它。添加“Review Entries”按钮和显示差异的函数，以便用户可以改正它们。
  
  
• 不要作任何事。有时错误并不重要，不足以成为警告的原因。例如，LPT1 上的打印机的纸张没准备好这一事实，在准备打印之前并没有多大关系。等待，直到消息合乎当前的任务。

详细信息 关于错误处理技术的详细内容，请参阅“调试代码与处理错误”。