最近在Ars Technica上发表的一篇文章讨论了北卡罗莱纳州立大学心理学系最近进行的一项研究，该研究表明，用户倾向于采取一切措施摆脱对话框以回到手头的任务。他们中的大多数将单击"确定"或者"是"，最小化对话框或者关闭对话框，而不管显示的消息如何。显示的某些对话框是真实的，而有些对话框是伪造的(例如，由网页显示的弹出窗口构成防病毒警告)。响应时间将表明那些用户并没有真正阅读这些对话框。

那么，知道了这一点，这将如何影响设计？我们打算如何做(如果有的话)？

解决方案

史蒂夫·克鲁格(Steve Krug)的书《不要让我思考》立刻浮现在脑海。

在对话框的设计中，状态消息会返回给用户，等等。对于单词的实际含义，最好使用图像和颜色提示。

因此，请以红色突出显示错误消息，以黄色突出显示警告。

首先，颜色和图标的使用应有助于使用户对问题的严重程度有一些视觉上的了解，红色表示特殊，黄色表示警告，白色表示信息。

其次，在对话框按钮上使用动词可使用户感觉到他们在告诉系统要执行的操作，即使他们不阅读对话框的文本也是如此。

最后，如果我们有兴趣研究完全不同的通知范例，请查看在Firefox和Internet Explorer中实现的信息栏或者通知栏。当用户获得新徽章时，StackOverflow使用相同类型的机制来通知用户。

信息栏不显眼，位于屏幕顶部，等待用户注意。我认为这是一个很棒的设计隐喻。

以下是一些实施教程：

• C＃
• 的JavaScript

这是Microsoft的对话框设计指南，它还涉及信息栏的概念。

几点建议

• 仅在绝对必要时使用盒子。
• 始终将默认选项设置为最不危险的选项

我们可以做的一件事是禁用"确定"按钮3秒钟。

当我们安装扩展程序时，Firefox会执行此操作。

编辑：好的，有些人觉得这很烦人。我仍然认为大约1秒钟就可以了。它将抑制人们(包括我自己)所具有的立即单击的直觉，并迫使人们采取双重行动。当然，即使对话不是他们真正需要阅读的内容，即使这样也会使人们感到烦恼。

我认为我们可能想阅读这篇文章：
"高强度协商式中断对最终用户调试的影响"，T。J. Robertson，Joseph Lawrance和Margaret Burnett，视觉语言与计算杂志17(2)，187-202，2006年4月。

它提出了类似的问题。结果是，让用户知道我们想要他们的关注，然后坐下来等待用户响应。但是，请勿打扰用户，这不是他或者她想要的。

首先，愚蠢的人应该受到伤害，但通常情况并非如此。

接下来最好的事情是包括一个试图传达问题严重性的图标。如果对话框的图标看起来不祥，则有一些不识字的人可能会改变习惯。一定比例的人不会阅读它。

开发人员通常使用模态对话框只是因为它易于编写代码。

但是，非模式通知通常更方便用户处理。

如果必须使用对话框，请在对话框内的按钮上添加描述性标题。

例如，让它们说"发送发票"和"返回"，而不是"确定"和"取消"按钮，或者在对话框的上下文中合适的选项。

这样，文本就在他们的光标下，并且他们有很好的理解机会。

Mac OS X通常会执行此操作。这是一个示例图像。

编辑：

这是一个更好的图像，我在Apple Human Interface Guideline网站上找到了它，它是很好的参考，而且可读性强。该站点上的该文档全部是关于Dialogs的。

我尝试将应用程序设计为在遇到事故时很健壮-滑倒(疏忽大意的操作，例如单击错误的位置)或者错误(认知错误，例如在对话框上单击确定或者取消)。一些实现此目的的方法是：

• 无限(或者至少是多步)撤消/重做
• 通过动态工具提示和其他上下文相关的交流方式将文档与界面集成(特别相关的一篇论文是关于``惊奇，解释，奖励''(直接链接：SER)的-使用对意外行为的典型心理反应来告知用户)
• 将系统状态合并到上述文档中(以当前用户的数据为例，并使用他们现在可以看到的数据使文档具体化)
• 预期用户错误。如果没有适当的磁盘，如果有人尝试写入a：\，则请执行超时操作，以使系统正常运行，然后提示其他位置。将数据保存在内存中，直到将其安全地保存在磁盘等上为止。

这归结为两个核心内容：(1)进行防御性编程，以及(2)使用户尽可能地了解情况。如果系统的界面易于使用，并且按照他们的期望进行操作，那么当出现令人讨厌的对话框时，他们更有可能知道要单击哪个按钮。

我也非常非常努力地避免任何模态，因此用户可以至少在一段时间内忽略我必须使用的大多数对话框(当他们真的需要关注它们时，他们有足够的信息来知道如何处理)。它)。

要使系统完全傻瓜是不可能的，但是我发现上述技术在正确的方向上有很长的路要走。 (并且它们已集成到用于开发"惊喜说明奖励"和其他工具的系统中，这些工具已通过广泛的用户研究进行了审查。)

Lightbox模态对话框在某些情况下(web 2.0派生，但可以在其他情况下实现)似乎是一种有效的技术。

还有一点：如果我们可以放弃一个"撤消"功能的对话框(Gmail拥护该概念，将其作为标准的Webapp行为)，这是需要考虑的问题。

在对话框末尾包含一个多项选择测验，用户必须选择一个答案，以表明他们确实阅读并理解了文本。随机切换选项的顺序，以使它们不能始终单击同一选项。

杰夫·拉斯金(Jef Raskin)的人性化界面值得一读。对话框是最后的选择，这是设计不良的标志。大多数都是不必要的，并且我们发现所有这些都被用户忽略。

为什么会有对话框？解决该问题时，不要求用户确认操作，而是使撤消操作变得容易。不要弹出一个对话框，宣布一个错误，无论如何都要进行任何恢复(或者任何可能的恢复)。绝对不要显示仅具有一个结果的对话框("确定"仅是魔鬼框)，而不会在应用程序内毫不费力地显示信息。

我想到一个.NET Rocks情节(我相信第338集，"关于良好UI的科学的Mark Miller")讨论了这个主题。我认为整个讨论的关键是，这是基础的UI设计。在模态曾经是可以接受的交流方式的地方，我们现在发现它已经成为编程的副手。用户了解到，十分之六的信息并不足够让他们担心。结果，他们以相同的方式对待所有模态-学习到的无助感。如果出现模态并告诉我发生了应用程序错误X，并且我只能单击"确定"，即使我认为不是"确定"，我也会学习特定的行为。我将模态与我可能对它们做的不多的想法相关联，但是如果我单击"确定" /"是"，则可以返回到我需要的东西。

那么，为什么仍然使用它呢？也许开发人员已经尝试避免应用程序开发变得不仅仅是一个基本界面，而且用户需要流畅的UI设计这一事实-旧的备用数据库很难放弃...

我认为这里的关键是要了解，良好的UI设计现在表明，即使对于最新手的计算机用户来说，打扰也是一件令人烦恼的事情，我们需要努力获得无缝的用户体验，其中应用程序的重点是用户，而不是用户。通过提示和错误报告来满足应用程序的需求-不允许用户进入他们无关紧要的情况。

一个建议：

• 不要使用对话框。特别是模态的"确定/取消"对话框。

有时这很难...我们如何处理打开文件？有时很容易...我们真的需要警告用户他们将要覆盖文件吗？很有可能，如果我盲目地单击"确定"，则我不会理会任何警告。

上面有很多好的建议。我只想向书中添加建议Joel Splosky的"程序员的用户界面设计"书值得阅读：

http://www.amazon.com/User-Interface-Design-Programmers-Spolsky/dp/1893115941/ref=pd_bbs_sr_4?ie=UTF8&s=books&qid=1222233643&sr=8-4

更改措辞以及对话框的工作方式会有所帮助。例如，具有"确定" /"取消"按钮往往会使用户忽略大部分对话框。如果我们删除了普通按钮并将其替换为更简单的命令链接，则用户更可能阅读每个按钮，因为"快速，轻松离开"选项不可用。

如果必须使用对话，请给用户提供有趣的同情或者讽刺甚至简短的解释性文字。如果我们偶尔分发有趣的丑闻，他们会阅读所有内容。

User is running dangerously low on
  common sense. Please remove this user
  and insert another one.

我称之为"自动驾驶"问题。

• 不要使用屏幕底部的"确定"，"取消"按钮。查看Vista试图迫使用户做出真正决定的方式。
• 禁用按钮几秒钟，显示"思考时间"计时器/进度栏。因此，用户无法单击自动驾驶仪。用户往往会发现这很烦人。

不要使用确认(确定吗？是/否)，而是使用"撤消"。

不要弹出会被阻止的警告，因为用户将尝试尽快恢复工作，而忽略该消息，只是将其单击即可。使用类似Internet Explorer信息栏这样的东西，它不会被阻止。

错误的问题。 "我们将如何处理用户"从错误的结尾开始。

正确的问题是"鉴于对话使用户分散了手头的任务，还有哪些更好的选择？"。

在努力实现目标或者完成任务时，我们可以区分三种情况：

(1)该应用程序得出的结论是，没有可以采取的使用户达到目标的动作。弹出一条消息，用一个按钮将其关闭。我们不必在乎读者是否理解它，因为结果无论如何都无关紧要。

(2)我们只能执行一项操作，或者其他选择与用户无关。根本不要打扰他。

(3)有两种或者多种实现目标的方法。让用户在这些之间进行选择。不要将其表述为是/否问题。 (Vista将其作为通用对话框提供，以替换消息框。)尽可能不要将其作为不可逆的选择。

该规则的例外是用户期望是/否问题的情况。但是实际上，如果是这样，那么为什么问题不在正常工作流程中？对话框不在正常的工作流程中。

我们可以避免一起使用所有对话框！在某些程序中，有一个显示错误和警告的微型缓冲区。随之而来的是，它可能还会问我们一个问题，我们必须在哪里键入我们想做的事情。这是一个非常干净且不错的解决方案，相对于菜单栏，我倾向于使用它。

但是，如果我们确实必须使用对话框，请尝试以下操作：

• 每个对话框仅一句话
• 最多两个或者三个按钮
• 使对话框内的文本可读(更大，黑白)
• 宁可使用一个对话框，也不要使用许多对话框(提示：列表框)

我如何看待对话框？简而言之：它们是愚蠢而愚蠢的东西。使用它们的程序会困扰我，让他们因愚蠢而毫无意义的问题而放慢我的速度。同样，使用对话框的程序通常很笨。

我对那些不读的用户几乎没有耐心，他们花了我大量的时间和精力来开发：1)应用程序2)指导除此之外，如果我们不阅读而只是做"随便什么"靠你自己。我事先声明。我将应用程序设计为尽可能直观，但仍然有人会突然拨打支持电话，就像一个孩子在不应该的时候在课堂上脱口而出。我对此没有宽容。阅读手册，阅读对话框，就可以找到99％问题的答案。