切换OK-Cancel和Cancel-OK以强制用户交互？

Question

这受到问题OK-Cancel or Cancel-OK?的启发。

我记得在某些情况下阅读有关切换OK-Cancel / Cancel-OK的概念，以防止用户在不阅读其内容的情况下点击信息弹出窗口或对话框。据我记忆，这还包括移动OK按钮的位置（水平，从左到右），以防止用户只记住点击的位置。

这真的有意义吗？这是强制用户“先思考/先读，然后点击”的好方法吗？还有其他概念适用于这种情况吗？

我特别想到一个与安全相关的应用程序，在这种情况下，不加思索地按出习惯会导致潜在的危险情况，而取消则会导致安全状态。

Answer 1

请不要这样做，除非你真的，真的，确实确定它是绝对必要的。这是一个试图通过技术手段解决疏忽和愚蠢的案例，而这种事情几乎从不起作用。

您可以使用动词或名词代替典型的Windows确定/取消按钮标题。这将在不牺牲可预测性的情况下为您提供即时的关注效益。

Answer 2

NOOOOOOOOOOOO！

在我们的某个产品中，我们有一个用户选项，需要按Ctrl + Click才能获得与安全相关的命令。

但是，在我的书中，用交换位置或移动的按钮让用户吃惊是不好的设计。

Answer 3

NO。如果你让用户更难以错误地点击OK并强迫他们思考，他们仍然只会更加思考如何点击OK - 他们不会考虑他们的实际情况试图进行。请参阅可用性专家Aza Raskin的文章：Never use a warning when you mean Undo。引用：

<强>

<强>

的   

如何发出警告   不可忽视？如果它是   适应人性的习惯   导致问题，为什么不设计   界面使我们无法形成   一个习惯。那样我们永远都是   被迫停下来思考之前   回答这个问题，所以我们会   总是选择我们的意思。   那会解决问题，对吧？

     

这种想法并不新鲜：它是   该   这个句子到第二个词 - 这个句子继续的方法。在游戏激战中，为   例如，删除一个字符需要   首先单击“删除”按钮   然后输入字符的名称   作为确认。不幸的是，它   并不总是有效。特别是：

     

的   
1. 它使我们专注于手头的非常规任务，而不是   我们是否想要扔掉   我们的工作。就这样   不可忽视的警告很少   比正常警告更好：我们结束了   失去我们的工作无论如何。这个   （失去工作）是最糟糕的   软件犯罪可能。
  
2. 非常讨厌，因为它总是需要我们的   注意，它必然会分散我们的注意力   从我们的工作（这是第二个   最糟糕的软件罪。）
  
3. 它总是比标准更慢，更耗费工作量   警告。因此，它承诺第三个   最糟糕的罪 - 需要我们更多的工作   比必要的。   
  

[如果你想要一个微软的，this one by a .NET guy on MSDN说同样的话！]

Answer 4

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

例如，代替“确定”和“取消”按钮，让他们说出“发送发票”和“返回”，或在对话框的上下文中适当的任何内容。

这样，文本就在他们的光标下，他们很有可能理解。

Apple人机界面指南网站是一个很好的参考，非常易读。 This page on that site talks about Dialogs.

以下是示例图片：
_{（来源：apple.com）}

Answer 5

不，这没有意义。你不打算“让”用户阅读。如果决定是至关重要的，那么你最好找到一种方法来减轻危险，而不是把假装粗心的用户交给装满枪的。

默认设置“安全”按钮（由输入/空格键/等触发）是一个好主意，只是因为如果他们让用户感到惊讶，那么用于预期窗口的按键不会意外触发意外动作。但即使在这种情况下，您必须意识到，当用户意识到他们已经完成了什么时，选择已经消失（以及对话框上的任何解释性文本）。再一次，你最好找另一种方式给他们信息。

Answer 6

我在某些情况下所做的是将显示的消息框的时间与被解除的时间进行比较。如果它小于'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

Answer 7

在一天结束时，你不能强迫用户做他们不愿意做的事情......他们总能找到解决办法

• 快捷键，可以绕过将鼠标移动到移动按钮的要求。
• 向下滚动到EULA的底部而不读取它以继续。
• 启动软件，然后在等待唠叨屏幕启用OK按钮的同时喝杯茶。

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

在您必须对用户的行为负责之前，您才能走得太远。告诉用户他们的行为被记录将使他们更加小心 - 如果他们被追究责任，他们更有可能做正确的事情。特别是如果有一个精心设计的消息，如下所示：

  

这是记录，你将被追究任何责任   这个决定的影响。你已经指示我删除   表ALL_CORPORATE_DATA。这样做会导致整个公司的   数据库停止工作，从而使整个公司陷入停顿   您必须选中该复选框以声明您接受此责任   在你可以选择继续之前...

然后是一个复选框，上面写着“是的，我接受我的行为的责任”和两个按钮：

• “是的，我想删除它”只有选中复选框才能启用此按钮。
• “OH CRAP，这不是我想要的”这个按钮总是可以启用。

如果他们删除了表格并且公司网格停止了，他们就会被解雇。然后备份恢复，每个人都很高兴拉里[拉里是谁]。

Answer 8

请不要这样做。这将没有任何积极的影响：你试图避免人们点击OK而不是取消，让他们可能点击取消而不是OK（好吧，他们可能会再试一次）。但！当他们真的想取消时，你可能会让人们点击确定，这可能是一场真正的灾难。这没什么好处。

Answer 9

为什么不重新制定用户界面以使OK成为“安全选择”？

Answer 10

通过良好的反馈，系统模型的通信和内置容差，可以更好地解决问题。

支持确认机制说明实施的简单性。从程序员的角度来看，这是将责任转移到用户身上的最简单方法：“嘿，我问你是否真的想要自己投入脚，不是吗？现在除了你自己之外没有人可以责怪...... 。“

从用户的角度来看：

1. 每次必须确认操作两次，即使实际错误仅占操作总数的一小部分，任何按钮切换，打破惯常工作流程或插入暂停确认只会增加罚款，都会产生生产力损失
2. 这种机制并没有真正为频繁使用的用户提供太多的安全网，他们的反应能够提前思考。就个人而言，我曾经多次做过一系列复杂的行动，只是为了在观察到我的大脑以某种方式走错路线的后果后才意识到这一点！

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

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

• 一旦行动发生，立即给予反馈确认（SO突出显示新提交的答案，gmail在发送消息时显示确认信息等）。

• 允许撤消或更正可能的错误（例如，在删除或编辑答案的情况下，Windows允许从回收站恢复文件等）。对于某些不可撤销的操作，仍然可以提供撤消功能，但仅限于有限的时间范围（即，在提交后的前10分钟内允许取消或更改在线订单，或者在第一次提交期间让他们回忆电子邮件“发送”后60秒，但实际上在发件箱中排队等等。

当然，这比插入一个混淆信息框要多得多，但不是转移责任而是试图解决问题。

Answer 11

听起来您的用户正在安全应用中使用一种输入向导。

一些想法作为移动按钮的替代方案。

1. 在按下最终确定之前，有一个最终屏幕来查看所有输入。

2. 在他们点击确定后会有一个确认框，说明此操作的结果。

3. 免责声明，要求您在用户可以继续之前选中一个框，同意该协议。

Answer 12

与任何具有用户交互的内容一样，您在帮助用户和烦人之间有一个小空间。我不知道你的具体要求，但你的想法对我来说似乎没问题（双关语）。

Answer 13

不要切换它 - 你只会比你的帮助更容易混淆。

相反，请像FireFox一样，不要激活控件5秒。 - 只需确保包含一个计时器或某种指示器，让他们有机会阅读它。如果他们点击它，它会切断计时器，但需要再点击一次。

不知道会有多好，但它可能会有所帮助。

请记住，正如男人所说：你无法修复愚蠢。

Answer 14

这会让我头疼。特别是当我不小心关闭应用程序并忘记保存我的文件时：（

我看到另一个强迫用户在点击之前“阅读”的好例子：Firefox总是灰显按钮（a.k.a禁用）“确定”按钮。因此，用户必须等待大约5秒才能继续做任何事情。我认为这是我在强迫用户阅读时所做的最好的努力（和思考）

我见过的另一个例子是安装程序的“许可和协议”页面。其中一些要求用户在他/她可以继续下一步之前向下滚动到页面的末尾。

Answer 15

我建议通过使用红色文本告知用户这是一项关键操作，并解释为什么这是一种不安全的操作。

此外，不是两个按钮，而是有两个单选按钮和一个“确定”按钮，默认情况下选择“不要继续”单选按钮。

这将为用户提供一个不常见的界面，增加认知负荷并减慢他的速度。这就是你想要的。

Answer 16

键盘快捷键仍然会像以前一样运行（你会惊讶地发现很少有人真正使用鼠标（特别是在LOB应用程序中）。

Vista（和OSX IIRC）已经转向为每个问题使用特定动词的想法（例如，当应用程序想要崩溃并希望向MS提交故障转储时，“发送”/“不发送”）< / p>

在我看来，我喜欢Outlook在应用程序尝试通过COM发送电子邮件时使用的方法，在允许使用按钮之前使用计时器（也会影响键盘快捷键）

Answer 17

但是如果OK / Cancels不一致，那可能会使用户失望或沮丧。

并且不要像某些EULA那样，在同意按钮变为可点击之前，用户被迫将面板滚动到底部。有时你只是无法让用户仔细阅读所有内容。

如果他们确实需要阅读它，可能会在按钮出现之前发生短暂的延迟？这对用户来说也可能很烦人，但如果这是一个非常关键的问题，那就值得了。

编辑：或者需要某种额外的机制，而不仅仅是点击“接受”这个非常重要的决定。复选框，按键，密码等

Answer 18

如果您使用确定和取消作为界面，您将始终允许用户跳过您的消息或屏幕。如果您重新排列确定和取消，您只会惹恼您的用户。

如果您的目标是确保用户理解，那么解决方法是：

• 向用户询问有关内容的信息。如果单击“确定”即表示您同意选项1，或者单击“确定”即表示您同意选项2.如果他们选择了正确答案，请允许操作。
• 这会让用户感到烦恼，所以如果你能跟踪用户，每封邮件只对他们做一次。

Answer 19

这是我回复Submit/Reset button order question的内容，我认为这里可以使用相同的原则。只要您确保用户可以区分这两个按钮，顺序就不重要了。在过去，我所做的是使用按钮（提交/确定）按钮并使用链接（重置​​/取消）按钮。用户可以立即判断这两个项目在功能上是不同的，因此可以这样对待它们。

Answer 20

我不是真的好/取消。它过度使用，需要你阅读bab呀学语，以便说出你正在取消或取消。遵循MacOSX UI的想法：该按钮包含一个简单易用的短语，它本身就很有意义。示例更改文件扩展名并弹出一个对话框说：

"Are you sure you want to change the extension from .py to .ps?"
If you perform the change, the document could be opened by a different application.

(Use .ps)   (Keep .py)

这比OK / Cancel更具沟通性，你的问题几乎是多余的，也就是说，你只需要保持最右边的按钮，这似乎是标准。

因为它涉及你提出的原始问题。永远不要这样做。永远。甚至在枪口下也没有。一致性是GUI的重要必备条件。如果你不一致，你将破坏用户体验，你的用户最有可能将此视为一个bug而不是一个功能（实际上它将是一个BUG）。一致性非常重要。要打破它，你必须有充分的理由，并且不能有另一种不同的标准方法来达到同样的效果。

Answer 21

我想知道您是否正在考虑Visual Basic中存在的选项，您可以在其中设置各种提示和响应选项;一个选项是允许您切换取消和确定，基于哪个应该是默认值;所以用户可以点击输入，大部分时间都可以采取适当的行动。

如果你真的想要朝着这个方向前进（我认为这是个坏主意，而且我确信你在经过一些反思和阅读所有其他帖子之后也会这样做），那么包括一个capcha显示更好行。