logo标签列表

将OK-Cancel和Cancel-OK交换以强制进行用户交互？

user-interfaceusability
9

这个问题的灵感来自于OK-Cancel 或 Cancel-OK？。

我记得在某处读到过一个概念，即在某些情况下切换 OK-Cancel/Cancel-OK 可以防止用户在未阅读内容的情况下点击信息弹出窗口或对话框。据我所知，这还包括水平移动“确定”按钮（从左到右）以防止用户仅记住点击位置。

这样做真的有意义吗？这是一种迫使用户“先思考/阅读，再点击”的好方法吗？还有其他适用于这种情况的概念吗？

我特别考虑了与安全相关的应用程序，在这种程序中，不经思考地按下“确定”可能会导致潜在的危险情况，而按下“取消”则会导致安全状态。

5
仅仅通过交换它们的位置，你会冒着某个人想要取消却误按了确认键的风险。 - Arjan Einbu
我想起了霍默用那只喝水鸟来完成他的工作。防止崩溃是Y还是N？ - Jon B
我同意Arjan的观点，你只会让用户感到困惑，导致做出不当选择，这比盲目地在所有对话框上点击“确定”还要糟糕。 - Bryan Denny
对于非常关键的决策，我见过一些软件让你写一些类似于人类验证码的内容。 - Vitim.us
21个回答
31
请不要这样做，除非您真的、真的、真的确定这是绝对必要的。这是试图通过技术手段修复粗心和愚蠢之举，而这种做法几乎从来没有奏效。
您可以使用动词或名词代替典型的 Windows“确定”/“取消”按钮标题。这将给您带来即时的关注优势，而不会牺牲可预测性。
3
同意，实际上我进来的目的就是回答同样的事情 - 最好用有意义的值来替换Ok/Cancel，这样用户在使用前会更加需要思考。 - Jay
1
或者你可以使用复选框或其他肯定的标记方式来标记某些内容为“已确认”。因此，您需要单击复选框，然后单击“确定”。 - Astra
1
我们在工作中有一些软件可以实现这个复选框的技巧。我非常讨厌那个愚蠢的复选框。我先是点击我想要做的操作，然后第二次再勾选该框并再次点击。我不建议使用这种方式。 - HitScan
14

不要啊！

在我们的某个产品中，我们有一个用户选项来要求使用Ctrl +单击进行安全相关命令。

但是，在我的看法中，通过交换位置或移动按钮来惊吓用户是糟糕的设计。

9
不行。如果你让用户更难意外地点击"确定"，并强迫他们思考，他们仍然只会更加努力地考虑如何点击"确定"，而不会考虑实际要执行的事情。请参考可用性专家Aza Raskin的文章：Never use a warning when you mean Undo。引用如下：
“怎么样才能让警告变得不可忽略？如果人类习惯性地造成了问题，为什么不设计界面，使我们无法形成习惯。这样，我们将总是被迫在回答问题之前停下来思考，因此我们将总是选择我们的意图。这样就解决了问题，对吧？”
这种思维方式并不新鲜：这是“打字继续”的方法。例如，在游戏《激战》中，删除角色需要先点击“删除”按钮，然后输入角色名称进行确认。不幸的是，它并不总是有效。特别是：
1. 它让我们集中注意力于非习惯性的任务上，而不是关注我们是否想要丢掉我们的工作。因此，不可忽略的警告与普通警告相比几乎没有什么区别：我们最终会失去我们的工作。这是最严重的软件错误。
2. 它非常烦人，因为它总是需要我们的注意力，所以必然会分散我们的注意力，从而使我们无法专注于工作（这是第二个最严重的软件错误）。
3. 它总是比标准警告慢和更费力。因此，它犯了第三个最严重的错误 - 要求我们做出比必要更多的工作。
[如果你想要一个微软式的，这篇来自MSDN的.NET人士的文章也说了同样的事情！]
这并不一定是一个坏主意，特别是对于那些可能是错误且具有不可挽回后果的罕见事件，当用户没有在工作时。它对于删除公会战争角色非常有效。至于其他事情，我就不太确定了。 - David Thornley
嗯，在《公会战争》中是如何工作的呢？在我玩过的所有其他大型多人在线游戏中，人物角色被标记为“已删除”，根本不需要任何愚蠢的确认，而且在特定时间内（比如7天）同样可以轻松地恢复已删除的角色……这对我来说更合理。 - Oskar Duveborn
7
如果必须使用对话框，请在对话框内的按钮上放置描述性标题。例如，不要使用“确定”和“取消”按钮，而应该使用“发送发票”和“返回”，或者根据对话框的上下文选择适当的标题。这样，文本就在他们的光标下方，他们有很好的理解机会。苹果人机界面指南网站是一个很好的参考，非常易读。该网站上的此页面讨论了对话框。以下是一个示例图像：Modal with named buttons
（来源：apple.com）
4
不，这并没有意义。你不能强迫用户阅读。如果决定如此重要，那么最好找到一种减轻危险的方法，而不是把一个被认为是粗心的用户交给他们手中的“有子弹”的枪。
将“安全”按钮设置为默认（通过enter/spacebar等触发）是个好主意，因为如果它们让用户感到惊讶，那么预期窗口的按键操作不会意外触发意外的动作。但即使在这种情况下，你必须意识到，当用户意识到自己所做的事情时，选择已经消失了（连同对话框上的任何解释文本）。再次强调，最好找到另一种方式来向他们提供信息。
3
在某些情况下，我比较了消息框显示的时间和消失的时间。如果小于“x”秒，它就会立即弹出。这迫使他们在大多数情况下实际阅读屏幕上的内容，而不是盲目地点击。这很容易做到。
类似这样：
Dim strStart As DateTime = Now
While Now < strStart.AddSeconds(5)
    MessageBox.Show("Something just happened", "Pay Attention", MessageBoxButtons.OK)
    If Now < strStart.AddSeconds(5) Then strStart = Now Else Exit While
End While
2

说到底，你不能强迫用户做他们不愿意做的事情……他们总能找到绕过它的方法。

  • 使用快捷键绕过将鼠标移动到移动按钮的要求。
  • 不阅读 EULA 的底部就向下滚动以启用继续选项。
  • 启动软件后，去拿杯茶等待提示屏幕出现，然后才点击“确定”按钮。

我见过最可靠的方法是根据所写内容给出多项选择题。如果他们没有正确答案，就无法继续……当然，几次之后，他们会意识到可以依次选择每个答案，直到按钮启用，然后点击它。再一次意味着他们没有阅读所写的内容。

在您必须对用户的行为负责之前，只能走得这么远。告诉用户他们的行为已被记录会让他们更加小心——如果他们要对自己的行为负责，他们更有可能做正确的事情。尤其是如果有一个精心制作的消息，上面写着：

此操作正在记录，您将对此决定的任何后果负责。您已指示我删除 ALL_CORPORATE_DATA 表。这样做将导致整个公司的数据库停止工作，从而使整个公司陷入停顿状态。
在选择继续之前，您必须选中复选框以表明您接受此责任……

然后是一个复选框，上面写着“是的，我对自己的行为负责”，以及两个按钮：

  • “是的，我要删除它”——只有选中复选框时才能启用此按钮。
  • “哦，糟糕，这完全不是我想要的”——此按钮始终可用。

如果他们删除了表格，公司就会陷入停顿状态，他们就会被解雇。然后备份被恢复，每个人都再次变得像 Larry 一样开心。

2

请不要这样做。这样做没有任何积极的效果：您试图避免人们点击“确定”而不是“取消”，但却可能让他们点击“取消”而不是“确定”（好吧，他们可能会再试一次）。但是！你也可能在人们真正想要取消时让他们点击“确定”，这可能会造成真正的灾难。这样做毫无好处。

1
为什么不重新设计用户界面，使“确定”成为“安全选择”？
1

这个问题最好通过良好的反馈、系统模型的沟通和内置容错来解决。

支持确认机制的实现简单性。从程序员的角度来看，这是将责任转移给用户的最简单方法：“嘿，我问过你是否真的想要把自己踢到脚下了，不是吗？现在没有人可以责怪你了......”

从用户的角度来看：

  1. 每次确认操作都需要确认两次，即使实际错误只占总操作数的一小部分，任何按钮切换、打破习惯工作流程或插入确认暂停都会增加生产力惩罚。
  2. 该机制对于经常使用者的安全网并不提供太多保障，他们的反射神经比意识更快。就我个人而言，我曾经多次进行复杂的操作序列，只有在观察后果时才意识到我的大脑某种方式走错了路线！

对于用户来说，更好但更复杂（从软件开发的角度来看）的解决方案是：

  • 尽可能提前沟通该操作对系统的确切影响（例如，Stack Overflow在“发布答案”按钮上方显示消息预览）。

  • 一旦操作完成，立即给予确认反馈（例如，SO突出显示新提交的答案，Gmail在发送邮件时显示确认等）。

  • 允许撤销或更正可能的错误（例如，在SO中删除或编辑答案，Windows可以从回收站还原文件等）。对于某些不可逆转的操作，仍然可以提供撤销功能，但仅限于有限的时间范围内（例如，在提交后的前10分钟内取消或更改在线订单，或在“发送”电子邮件后的前60秒内撤回邮件，但实际上是排队等待发送等）。

当然，这比插入确认消息框需要更多的初始工作，但它试图解决问题而不是转移责任。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接