最近一篇关于Ars Technica的文章讨论了北卡罗来纳州立大学心理学系最近进行的一项研究,该研究表明用户倾向于尽一切可能摆脱对话框以回到他们手头的任务.无论显示何种消息,大多数人都会单击"确定"或"是",最小化对话框或关闭对话框.显示的一些对话框是真实的,其中一些是假的(就像那些冒充防病毒警告的网页显示的弹出窗口).响应时间表明这些用户并没有真正阅读这些对话框.
所以,知道这一点,这将如何影响你的设计,你会尝试做些什么(如果有的话)？
我尝试将应用程序设计为在事故面前变得强大 - 无论是滑动(无意中的操作,例如在错误的位置点击)还是错误(认知错误,例如在对话框上单击"确定"和"取消").一些方法是:
无限(或至少多步)撤消/重做
通过动态工具提示和其他上下文敏感的沟通方式将文档与界面集成(一篇特别相关的论文是关于'惊喜,解释,奖励'(直接链接:SER) - 使用典型的心理反应来预测意外行为用户)
将系统状态合并到所述文档中(使用当前用户的数据作为示例,并通过使用他们现在可以看到的数据使文档具体化)
预计用户错误.如果某人有可能尝试写入:\,当没有磁盘时,则实施超时,以便系统可以正常失败,并提示其他位置.将数据保存在内存中,直到它在磁盘上等是安全的.
这归结为两个核心问题:(1)防御性程序,以及(2)尽可能保持用户的信息.如果系统的界面易于使用,并且按照他们的期望行事,那么当出现恼人的对话框时,他们更有可能知道要点击哪个按钮.
我也非常非常努力地避免任何模态,因此用户可以忽略我必须使用的大多数对话框,至少有一段时间(当他们真正需要关注它们时,他们有足够的信息知道如何处理它).
制作一个完全万无一失的系统是不可能的,但我发现上述技术在正确的方向上有很长的路要走.(并且它们已被纳入用于开发惊喜解释奖励的系统以及经过广泛用户研究审查的其他工具.)
首先,颜色和图标的使用应该有助于用户对问题的严重性有一些视觉意识,红色表示异常,黄色表示传达警告,白色表示信息传达.
其次,在对话框按钮上使用动词可以让用户了解他们告诉系统要做什么,即使他们没有阅读对话框的文本.
最后,如果您有兴趣研究完全不同的通知范例,请查看Firefox和Internet Explorer中实现的信息栏或通知栏.StackOverflow使用相同类型的机制在用户获得新徽章时通知用户.
信息栏非突兀,位于屏幕顶部,等待用户注意.我认为这是一个很棒的设计比喻.
以下是一些实现教程:
C#
JavaScript的
这是微软关于对话框设计的指导,它也触及了信息栏的概念.
想到史蒂夫克鲁格的书" 不要让我思考".
在对话框的设计,状态消息返回给用户等时,最好使用图标和颜色提示来确定单词的实际含义.
因此,突出显示错误消息红色,警告黄色等.
杰夫拉斯金的人文界面值得一读.对话框是最后的手段,也是设计不佳的标志.大多数都是不必要的,正如您发现的那样,用户都会忽略它们.
为什么有对话框？解决该问题 - 不要求用户确认操作,而是轻松撤消操作.不要弹出一个宣布错误的对话框 - 做任何你要做的恢复(或任何可能的事情).绝对不要显示只有一个结果的对话框('OK'只有框是恶魔),不显眼地在应用程序中显示信息.
一些建议
只在绝对必要时使用盒子.
始终将默认选项设置为最不危险的选项
一个.NET岩石插曲想到的(我相信插曲338,"马克·米勒好UI的科学")讨论这个话题.我认为整个讨论的关键在于这是基本的UI设计.如果模态曾经是一种可接受的交流方式,我们现在发现它已成为编程失误.用户理解,10次中有6次信息不足以让他们担心.结果他们以同样的方式对待所有模态 - 学会无助.如果一个模态出现并且告诉我发生了应用程序错误X并且我可以点击的所有内容都是"OK" - 即使我不认为它是"OK"我也会学习一个特定的行为.我认为莫代尔的想法是我可能对它们做不了多少,但如果我点击确定/是,那么我可以回到我需要的东西.
那么,为什么还在使用呢？也许开发人员已经尝试避免这样一个事实,即应用程序开发不仅仅是一个基本的界面,而且用户需要流畅的UI设计 - 旧的备用设备很难放弃......
我认为关键在于理解良好的UI设计现在表明中断(即使是最新手的计算机用户)也是烦恼,我们需要努力获得无缝的用户体验,其中应用程序的重点是用户 - 而不是通过提示和错误报告来满足应用程序的需求 - 不允许用户进入他们不关心的情况.
开发人员经常使用模态对话框,因为它很容易编码.
但是,非模态通知通常更便于用户处理.
京公网安备 11010802040832号 | 京ICP备19059560号-6 