最近关于Ars Technica的一篇文章讨论了北卡罗来纳州立大学心理学系最近进行的一项研究,该研究表明用户倾向于不惜一切代价摆脱对话框以回到他们手头的任务。他们中的大多数会单击“确定”或“是”,最小化对话框或关闭对话框,而不管显示的消息如何。显示的对话框有些是真实的,有些是假的(例如那些冒充防病毒警告的网页显示的弹出窗口)。响应时间表明这些用户并没有真正阅读这些对话框。
那么,知道了这一点,这将如何影响您的设计,以及您会尝试做些什么(如果有的话)?
最近关于Ars Technica的一篇文章讨论了北卡罗来纳州立大学心理学系最近进行的一项研究,该研究表明用户倾向于不惜一切代价摆脱对话框以回到他们手头的任务。他们中的大多数会单击“确定”或“是”,最小化对话框或关闭对话框,而不管显示的消息如何。显示的对话框有些是真实的,有些是假的(例如那些冒充防病毒警告的网页显示的弹出窗口)。响应时间表明这些用户并没有真正阅读这些对话框。
那么,知道了这一点,这将如何影响您的设计,以及您会尝试做些什么(如果有的话)?
我尝试将应用程序设计为在面对意外时保持稳健——无论是滑倒(无意操作,例如单击错误的位置)或错误(认知错误,例如单击对话框上的确定与取消)。一些方法是:
这归结为两个核心内容:(1)防御性编程,以及(2)尽可能让用户了解情况。如果系统的界面易于使用,并且行为符合他们的期望,那么当出现烦人的对话框时,他们更有可能知道单击哪个按钮。
我也非常非常努力地避免使用任何模式,因此用户可以忽略我必须使用的大多数对话框,至少在一段时间内(当他们真的需要注意它们时,他们有足够的信息知道如何处理它)。
使系统完全万无一失是不可能的,但我发现上述技术朝着正确的方向走了很长一段路。(并且它们已被纳入用于开发 Surprise Explain Reward 和其他经过广泛用户研究审查的工具的系统中。)
首先,颜色和图标的使用应该帮助用户在视觉上了解问题的严重性,红色表示异常,黄色表示警告,白色表示信息。
其次,在对话按钮上使用动词可以让用户了解他们在告诉系统做什么,即使他们没有阅读对话文本。
最后,如果您有兴趣研究完全不同的通知范例,请查看在 Firefox 和 Internet Explorer 中实现的信息栏或通知栏。StackOverflow 使用相同类型的机制在用户获得新徽章时通知他们。
信息栏不显眼,并停留在屏幕顶部等待用户注意。我认为这是一个很好的设计隐喻。
这里有几个实现教程:
这是微软关于对话框设计的指南,它也涉及到信息栏的概念。
Jef Raskin 的人性化界面值得一读。对话框是最后的手段,也是设计不佳的标志。大多数都是不必要的,正如您所发现的,用户都忽略了。
为什么会有对话框?解决这个问题——不要要求用户确认操作,而是让撤消操作变得容易。不要弹出一个宣布错误的对话框 - 无论如何都要进行任何恢复(或任何可能的恢复)。绝对不要显示只有一个结果的对话框(只有“确定”的框是魔鬼),在应用程序中不显眼地显示信息。
几个建议
一个.NET Rocks插曲浮现在脑海中(我相信第 338 集,“Mark Miller on the Science of Good UI”) 讨论这个话题。我认为整个讨论的关键在于,这是基本的 UI 设计太过分了。模态曾经是一种可接受的通信方式,但我们现在发现它已成为编程失礼。用户明白,十分之六的信息没有足够的相关性让他们担心。结果,他们以同样的方式对待所有情态——习得性无助。如果出现一个模式并告诉我发生了应用程序错误 X 并且我只能单击“确定”——即使我认为它不是“确定”,我也会学习一种特定的行为。我将模态与我可能对它们无能为力的想法相关联,但如果我单击“确定/是”,那么我可以回到我需要的东西。
那么,为什么还在使用呢?也许开发人员试图避免这样一个事实,即应用程序开发不仅仅是一个基本界面,而用户需要流畅的 UI 设计——旧的备用设备很难放弃......
我认为这里的关键是要理解,好的 UI 设计现在表明中断(即使是对于最新手的计算机用户)也是一种烦恼,我们需要努力获得无缝的用户体验,其中应用程序的重点是用户——而不是通过提示和错误报告来满足应用程序的需求——不允许用户进入他们不关心的情况。
开发人员经常使用模式对话框只是因为它易于编码。
但是,非模态通知通常更方便用户处理。
一个建议:
有时这很难......你如何处理打开文件?有时这很容易……您真的需要警告用户他们将要覆盖文件吗?很有可能,如果我盲目地单击“确定”,我将不会注意任何警告。
如果您必须使用对话框,请在对话框内的按钮上添加描述性标题。
例如,让他们说“发送发票”和“返回”,而不是“确定”和“取消”按钮,或者在对话上下文中适当的任何内容。
这样,文本就在他们的光标下,他们有很好的理解机会。
Mac OS X 大部分时间都是这样做的。 这是一个示例图像。
编辑:
这是一个更好的图像,我在 Apple Human Interface Guideline 网站上找到了它,这是一个很好的参考,并且非常易读。 该网站上的这份文档都是关于 Dialogs 的。
错误的问题。“你将如何处理用户”的开头是错误的。
正确的问题是“鉴于对话会分散用户对手头任务的注意力,还有什么更好的选择?”。
在为实现目标或完成任务而努力时,我们可以区分三种情况:
(1) 应用程序得出的结论是,它无法采取任何行动来使用户实现目标。弹出一条消息,用一个按钮将其关闭。你不在乎读者是否理解它,因为无论如何结果并不重要。
(2) 您只能采取一种行动,或者替代方案与用户无关。完全不要打扰他。
(3) 有两种或两种以上的方式来实现目标。让用户在这些之间进行选择。不要将此表述为是/否问题。(Vista 将其作为一个通用对话框提供,以替换消息框。)如果可能,请不要将此作为不可逆转的选择。
此规则的例外是用户期望是/否问题的情况。但实际上,如果是这样的话,那么为什么问题不是正常工作流程的一部分呢?对话框超出了正常的工作流程。
您可以做的一件事是禁用“确定”按钮 3 秒钟。
Firefox 会在您安装扩展程序时执行此操作。
编辑:好吧,有些人觉得这很烦人。我仍然认为大约 1 秒就可以了。它会抑制人们(包括我自己)所具有的立即点击 OK 的本能,并强制进行双重拍摄。当然,如果你的对话不是他们真正需要阅读的内容,即使这样也会惹恼他们。
我想您可能想阅读这篇论文: “高强度协商式中断对最终用户调试的影响”,TJ Robertson、Joseph Lawrance 和 Margaret Burnett,Journal of Visual Languages and Computing 17(2), 187- 202,2006 年 4 月。
它问了一个类似的问题。结果是,让用户知道你想要他们的注意力,然后坐下来等待用户回应。但是不要打断用户,那不是他或她想要的。
[Lightbox]( http://en.wikipedia.org/wiki/Lightbox_(JavaScript))模态对话框在某些情况下似乎是一种有效的技术(web 2.0 派生,但可以在其他上下文中实现)。
还有一点:如果您可以放弃撤消功能的对话框(Gmail 将这一概念视为标准的 webapp 行为),这是需要考虑的事情。
上面有很多好的建议。我只是想在书中添加推荐——Joel Splosky 的《程序员的用户界面设计》这本书值得一读:
如果您必须使用对话,请用有趣的同情甚至讽刺和非常简短的解释性文字奖励用户。如果你偶尔发布一些可笑的丑闻,他们会阅读所有内容。
用户的常识低得危险。请删除此用户并插入另一个用户。
我对不阅读花费我大量时间和精力来开发的用户没有耐心:1)应用程序 2)说明除此之外,如果您不阅读并且只是“不惜一切代价”去做,那么您就是靠自己。我事先声明。我将我的应用程序设计为尽可能直观,但仍然有人会突然拨打支持电话,就像一个孩子在不应该在课堂上脱口而出一样。我对此无法容忍。阅读手册,阅读对话框——99% 的问题的答案就在那里。
首先,愚蠢应该会受到伤害,但通常不会如此......
下一个最好的事情是包含一个试图传达问题严重性的图标。如果对话框的图标看起来不祥,那么一部分不阅读的人可能会改变他们的习惯。无论如何,一些百分比不会阅读它。
在对话框的末尾包括一个多项选择测验,用户必须选择表明他们确实阅读并理解文本的答案。随机切换选项的顺序,这样他们就不能总是点击同一个。
更改措辞和对话的工作方式会有所帮助。例如,拥有确定/取消按钮往往会让用户忽略大部分对话框。如果您删除普通按钮并将其替换为更冗长的命令链接,则用户更有可能阅读每个按钮,因为“快速,离开”选项不可用。
我称之为“自动驾驶”问题。
不要使用确认(您确定吗?是/否),但使用撤消。
不要弹出会阻塞的警告,因为用户会尝试尽快重新开始工作,而忽略消息并单击它。使用 Internet Explorer 中的信息栏之类的东西,它不会阻止。
您可以避免一起使用对话框!在某些程序中,有一个显示错误和警告的小缓冲区。除此之外,它还可能会问你一件事,你必须在哪里输入你想做的事情。这是一个非常干净和不错的解决方案,我更喜欢它而不是菜单栏。
但是如果你真的必须使用对话框,试试这个:
我对对话框有什么看法?简而言之:它们是愚蠢而愚蠢的东西。使用它们的程序让我上路,并用它们愚蠢的无意义的问题拖慢我的速度。此外,通常使用对话框的程序相当愚蠢。