当前位置： 文江博客话题详情

切换“确定-取消”和“取消-确定”以强制用户交互？

发布于 2024-07-11 05:31:10 字数 373 浏览 8 评论 0原文

这是受到问题确定-取消还是取消-确定？的启发。

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

这真的有道理吗？ 这是强迫用户“先思考/阅读，然后单击”的好方法吗？ 还有其他概念适用于这种情况吗？

我特别想到与安全相关的应用程序，在该应用程序中，出于习惯而轻率地按“确定”可能会导致潜在的危险情况，而“取消”则会导致安全状态。

原文

This is inspired by the question OK-Cancel or Cancel-OK?.

I remember reading somewhere about the concept of switching OK-Cancel/Cancel-OK in certain situations to prevent the user from clicking through information popups or dialog boxes without reading their content. As far as I remember, this also included moving the location of the OK button (horizontally, left to right) to prevent the user from just remembering where to click.

Does this really make sense? Is this a good way to force the user to "think/read first, then click"? Are there any other concepts applicable to this kind of situation?

I am particularly thinking of a safety-related application, where thoughtlessly pressing OK out of habit can result in a potentially dangerous situation whereas Cancel would lead to a safe state.

如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论， 你可以免费 注册 一个本站的账号。

评论（21）

梦途 2024-07-18 05:31:11

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

支持确认机制说明了实施的简单性。 从程序员的角度来看，这是将责任转移给用户的最简单方法：“嘿，我已经问过你是否真的想搬起石头砸自己的脚，不是吗？现在除了你自己，没有人可以责怪...... 。

从用户的角度来看：

  1. 即使实际错误只占操作总数的一小部分，但每次都必须确认操作两次，任何按钮的切换、打破习惯的工作流程或插入暂停都会降低生产力 确认只会增加惩罚。
  2. 对于那些反应快于意识的频繁用户来说，该机制并没有真正提供太多的安全网。 就我个人而言，我曾多次做过一系列复杂的动作，但在观察后果时才意识到我的大脑不知何故走错了路！

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

  • 在可能的情况下提前传达该操作将对系统产生的确切影响（例如 Stack Overflow 在上面显示消息预览） “发布您的答案”按钮）。

  • 一旦操作发生，立即提供反馈以确认（SO 突出显示新提交的答案，gmail 在发送消息时显示确认等）。

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

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

The problem is better solved with a combination of good feedback, communication of a system model and built-in tolerance.

In favor of the confirmation mechanism speaks the simplicity of implementation. From programmer's point of view it's the easiest way of shifting responsibility onto user: "Hey, I've asked you if you really want to shoot yourself into the foot, haven't I? Now there is no one to blame but yourself..."

From user point of view:

  1. There is a productivity penalty of having to confirm operation twice every time even though actual mistakes take up just a fraction of total number of actions, any switching of buttons, breaking the habitual workflow or inserting a pause into confirmation just increases the penalty.
  2. The mechanism doesn't really provide much safety net for frequent users whose reflexes work ahead of the concious mind. Personally I have many times done a complex sequence of actions only to realise a moment later when observing the consequences that my brain somehow took the wrong route!

A better for the user, but more complex (from software development point of view) solution would be:

  • Where possible communicate in advance what exact affect the action is going to make on the system (for instance Stack Overflow shows message preview above Post Your Answer button).

  • Give an immediate feedback to confirm once the action took place (SO highlights the freshly submitted answer, gmail displayes a confirmation when a message is sent etc).

  • Allow to undo or correct possible mistake (i.e. in SO case delete or edit the answer, Windows lets restore a file from recycle bin etc). For certain non-reversible actions it's still possible to give an undo capability but for a limited timeframe only (i.e. letting to cancel or change an online order during the first 10 minutes after its submission, or letting to recall an e-mail during the first 60 seconds after its been "sent", but actually queued in the outbox etc).

Sure, this is much more initial work than inserting a confimation message box, but instead of shifting the responsibility it attempts to solve the problem.

回复 原文
提笔书几行 2024-07-18 05:31:11

但如果“确定”/“取消”不一致，可能会令用户感到厌烦或不安。

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

如果他们真的需要阅读它，也许在按钮出现之前应该发生短暂的延迟？ 这也可能会让用户感到烦恼，但如果这是一个非常关键的问题，那么这是值得的。

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

But if the OK/Cancels are not consistent, that might throw off or upset the user.

And don't do like some EULAs where a user is forced to scroll a panel to the bottom before the Agree button becomes clickable. Sometimes you just won't be able to get a user to read everything carefully.

If they really need to read it, maybe a short delay should happen before the buttons appear? This could also potentially be annoying to the user, but if it is a very critical question, it'd be worth it.

Edit: Or require some sort of additional mechanism than just clicking to "accept" the very important decision. A check box, key press, password, etc.

回复 原文
成熟的代价 2024-07-18 05:31:11

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

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

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

I recommend informing the user that this is a critical operation by using red text and explaining why is this an unsafe operation.

Also, rather than two buttons, have two radio buttons and one "Ok" button, with the "don't continue" radio button selected as default.

This will present the user with an uncommon interface, increasing cognitive load and slowing him down. Which is what you want here.

回复 原文
初吻给了烟 2024-07-18 05:31:11

与任何与用户交互有关的事情一样，帮助用户和烦人之间的距离很小。 我不知道你的确切要求，但你的想法对我来说似乎不错（双关语）。

As always with anything with user interaction, you have a small space between helping the user and being annoying. I don't know you exact requirements but your idea seems OK(pun intended) to me.

回复 原文
北渚 2024-07-18 05:31:11

听起来您的用户正在安全应用程序中经历某种输入向导。

一些替代移动按钮的想法。

  1. 在按最后的“确定”之前，有一个最终屏幕来检查所有输入。

  2. 点击“确定”后有一个确认框，解释此操作的结果。

  3. 免责声明，要求您通过选中复选框表示同意，然后用户才能继续。

It sounds like your user is going through a type of input wizard in the safety app.

Some ideas as alternatives to moving buttons.

  1. Have a final screen to review all input before pressing the final ok.

  2. Have a confirmation box after they hit ok explaining what the result of this action will be.

  3. A disclaimer that require you to agree to it by checking a box before the user could continue.

回复 原文
等风也等你 2024-07-18 05:31:11

不要改变它——你只会带来更多的困惑，而不是提供帮助。

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

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

请记住，正如那个人所说：你无法解决愚蠢的问题。

Don't switch it around - you'll only confuse more than you'll help.

Instead, do like FireFox and not activate the control for 5 sec. - just make sure you include a timer or some sort of indicator that you're giving them a chance to read it over. If they click on it, it cuts off the timer, but requires they click one more time.

Don't know how much better it will be, but it could help.

Just remember, as the man said: You can't fix stupid.

回复 原文
瘫痪情歌 2024-07-18 05:31:11

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

我看到另一个强制用户在点击之前“阅读”的好例子：Firefox总是使按钮变灰（也称为禁用）“确定” “按钮。因此，用户必须等待大约 5 秒才能继续执行任何操作。我认为这是我在强制用户阅读（和思考）方面所见过的最好的

努力可以在安装程序的“许可和协议”页面中看到，其中一些要求用户向下滚动到页面末尾，然后才能继续下一步。

This will give me headache. Especially when I accidentally close the application and forget to save my file :(

I see another good example of forcing user to "read" before click: Firefox always grayed out the button (a.k.a disable) the "OK" button. Therefore the user have to wait around 5 seconds before he can proceed to do anything. I think this is the best effort I have seen in forcing user to read (and think)

Another example I have seen is in "License and Agreements" page of the installer. Some of them required the user to scroll down to the end of the page before he/she can proceed to next step.

回复 原文
始于初秋 2024-07-18 05:31:11

键盘快捷键仍然会像以前一样工作（并且您会惊讶地发现很少有人真正使用鼠标（尤其是在 LOB 应用程序中）。Vista

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

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

Keyboard shortcuts would still behave as before (and you'd be surprised how few people actually use mice (especially in LOB applications).

Vista (and OSX IIRC) have moved towards the idea of using specific verbs for each question (like the "Send"/"Don't send" when an app wants to crash and wants to submit a crashdump to MS)

In my opinion, I like the approach used by Outlook when an app tries to send an email via COM, with a timer before the buttons are allowed to be used (also affects keyboard shortcuts)

回复 原文
栖迟 2024-07-18 05:31:11

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

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

  • 向用户询问内容。 如果您单击“确定”，则表示您同意选项 1，或者如果您单击“确定”，则表示您同意选项 2。如果他们选择正确的答案，则允许该操作。
  • 这会惹恼用户，因此如果您可以跟踪用户，则每条消息只对他们跟踪一次。

If you use Ok and Cancel as your interface you will always be allow the user to just skip your message or screen. If you then rearrange the Ok and Cancel you will just annoy your user.

A solution to this, if your goal is to insure the users understanding, is:

  • Question the user about the content. If you click Ok you are agreeing to Option 1, or if you click Ok you are agreeing to option 2. If they choose the correct answer, allow the action.
  • This will annoy the user, so if you can keep track of users, only do it to them once per message.
回复 原文
我不在是我 2024-07-18 05:31:11

这就是我对提交/重置按钮订单问题的回复我认为这里也可以使用同样的原则。 只要确保用户可以区分这两个按钮，顺序并不重要。 过去我所做的是使用（提交/确定）按钮的按钮和（重置/取消）按钮的链接。 用户可以立即看出这两个项目在功能上是不同的，因此可以这样对待它们。

This is what I responded to Submit/Reset button order question and I think the same principle can be used here. The order does not really matter as far as you make sure the user can distinguish the two buttons. In the past what I have done is used a button for (submit/OK) button and used a link for (reset/cancel) button. The users can instantly tell that these two items are functionally different and hence treat them that way.

回复 原文
ζ澈沫 2024-07-18 05:31:11

我并不是真的赞成“确定/取消”。 它被过度使用，需要你阅读胡言乱语才能说出你同意或取消的内容。 遵循 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)

它比“确定/取消”更具沟通性，您的问题几乎变得多余，也就是说，您只需要保持最右边的按钮处于活动状态，这似乎是标准的。

因为它涉及您提出的原始问题。 永远不要这样做。 曾经。 即使是在枪口下也不行。 一致性是 GUI 的一个重要前提。 如果不一致，就会破坏用户体验，并且您的用户很可能将其视为错误而不是功能（实际上，这将是一个错误）。 一致性非常重要。 要打破它，你必须有很好的理由，并且不能有其他不同的、标准的方法来达到相同的效果。

I am not really for OK/Cancel. It's overused and requires you to read the babbling in order to say what you are OKing or Canceling. Follow the idea of MacOSX UI: the button contains a simple, easy phrase that is meaningful by itself. Exampleç you change a file extension and a dialog pops up saying:

"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)

It is way more communicative than OK/Cancel, and your question becomes almost superfluous, that is, you just need to keep active the rightmost button, which seems to be the standard.

As it concerns the raw question you posed. Never do it. Ever. Not even at gunpoint. Consistency is an important requisite for GUIs. If you are not consistent you will ruin the user experience, and your users will most likely to see this as a bug than a feature (indeed it would be a BUG). Consistency is very important. To break it, you must have very good reason, and there must not be another different, standard way to achieve the same effect.

回复 原文
悲凉≈ 2024-07-18 05:31:11

我想知道您是否正在考虑 Visual Basic 中存在的选项，您可以在其中设置各种提示和响应选项； 一个选项是允许您根据默认值切换“取消”和“确定”； 所以用户只需按回车键，大多数时候就会得到正确的操作。

如果你真的想朝这个方向前进（我认为这是一个坏主意，并且我相信在经过一番反思并阅读所有其他帖子后你也会这样做），那么包含验证码显示会更好。

I wonder if you're thinking about the option that exists in Visual Basic where you can set various prompts and response options; and one option is to allow you to switch Cancel and OK based on which should be the default; so the user could just hit enter and most of the time get the proper action.

If you really want to head in this direction (which I think is a bad idea, and I'm sure you will too after little reflection and reading all the oher posts) it would work even better to include a capcha display for OK.

回复 原文
￡噩梦荏苒 2024-07-18 05:31:10

除非您真的、真的、真的确定绝对需要这样做，否则请不要这样做。 这是一个试图通过技术手段来解决粗心和愚蠢问题的案例，而这种事情几乎永远不会奏效。

您可以做的是使用动词或名词而不是典型的 Windows“确定”/“取消”按钮标题。 这将为您带来即时的注意力优势，而不会牺牲可预测性。

Please don't do this unless you are really, really, really sure it's absolutely required. This is a case of trying to fix carelessness and stupidity by technological means, and that sort of thing almost never works.

What you could do is use verbs or nouns instead of the typical Windows OK / Cancel button captions. That will give you an instant attention benefit without sacrificing predictability.

回复 原文
各自安好 2024-07-18 05:31:10

不哦哦哦哦！

在我们的一款产品中，我们有一个用户选项，要求使用 Ctrl+Click 来执行与安全相关的命令。

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

NOOOOOOOOOOOO!

In one of our products we have a user option to require Ctrl+Click for safety related commands.

But startling the user with buttons that swap place or move around is bad design in my book.

回复 原文
两仪 2024-07-18 05:31:10

不。 如果您让用户更难错误地单击“确定”并强迫他们思考，他们仍然只会更加努力地思考如何单击“确定” - 他们不会考虑他们实际要做的事情试图进行。 请参阅可用性专家 Aza Raskin 的文章：当您想要撤消时切勿使用警告。 引用:

发出警告怎么样
不可能被忽视？ 如果它是
人类方面的习惯，即
造成这个问题，为什么不设计
我们无法形成的界面
一个习惯。 这样我们就永远是
被迫停下来思考之前
回答这个问题，所以我们会
始终选择我们想要的答案。
这样就可以解决问题了，对吗？

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

  1. 它使我们专注于手头不习惯的任务，而不是
    我们是否想扔掉
    我们的工作。 就这样
    无法忽视的警告很少
    比正常警告更好：我们结束
    不管怎样都会失去我们的工作。 这
    （失去工作）是最糟糕的
    软件可能有罪。
  2. 这非常烦人，因为它总是需要我们
    注意力，它必然会分散我们的注意力
    来自我们的工作（这是第二个
    最糟糕的软件罪）。

  3. 它总是比标准速度慢且工作强度更大
    警告。 因此，它承诺了第三个
    最严重的罪过——要求我们做更多的工作
    比必要的。

[如果你想要一本 Microsoft 风格的书，这个是 .NET 人员写的MSDN 上也说了同样的话！]

NO. If you make it harder for the user to click OK by mistake and force them to think, they will still only think harder about how to click OK -- they will not think about the actual thing they're trying to carry out. See usability expert Aza Raskin's article: Never use a warning when you mean Undo. Quote:

What about making the warning
impossible to ignore? If it’s
habituation on the human side that is
causing the problem, why not design
the interface such that we cannot form
a habit. That way we’ll always be
forced to stop and think before
answering the question, so we’ll
always choose the answer we mean.
That’ll solve the problem, right?

This type of thinking is not new: It’s
the
type-the-nth-word-of-this-sentence-to-continue approach. In the game Guild Wars, for
example, deleting a character requires
first clicking a “delete” button and
then typing the name of the character
as confirmation. Unfortunately, it
doesn’t always work. In particular:

  1. It causes us to concentrate on the unhabitual-task at hand and not on
    whether we want to be throwing away
    our work. Thus, the
    impossible-to-ignore warning is little
    better than a normal warning: We end
    up losing our work either way. This
    (losing our work) is the worst
    software sin possible.
  2. It is remarkably annoying, and because it always requires our
    attention, it necessarily distracts us
    from our work (which is the second
    worst software sin).
  3. It is always slower and more work-intensive than a standard
    warning. Thus, it commits the third
    worst sin—requiring more work from us
    than is necessary.

[If you want a Microsoftish one, this one by a .NET guy on MSDN says the same thing!]

回复 原文
我最亲爱的 2024-07-18 05:31:10

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

例如，不要使用“确定”和“取消”按钮，而是让它们说“发送发票”和“返回”，或者任何适合对话框上下文的内容。

这样，文本就位于他们的光标下方，他们就有很好的机会理解。

Apple 人机界面指南网站是一个很好的参考资料，而且非常可读。 该网站上的此页面讨论了对话框。

这是示例图像：带有命名按钮的模态
（来源：apple.com< /a>)

If you must use a dialog, put descriptive captions on the buttons within the dialog.

For example, instead of OK and Cancel buttons, have them say "Send Invoice" and "Go Back", or whatever is appropriate in the context of your dialog.

That way, the text is right under their cursor and they have a good chance of understanding.

The Apple Human Interface Guideline site is a great reference, and very readable. This page on that site talks about Dialogs.

Here is an example image: Modal with named buttons
(source: apple.com)

回复 原文
明媚殇 2024-07-18 05:31:10

不，这没有意义。 你不会“让”用户阅读。 如果这个决定如此重要，那么你最好找到一种方法来减轻危险，而不是给一个假定粗心的用户一把上膛的枪。

无论如何，将“安全”按钮设为默认值（由回车/空格键/等触发）是一个好主意，因为如果它们让用户感到惊讶，那么针对预期窗口的击键就不会意外触发意外操作。 但即使在这种情况下，您也必须意识到，当用户意识到他们所做的事情时，选择已经消失（以及对话框中的任何解释性文本）。 同样，您最好找到另一种方式向他们提供信息。

No, it doesn't make sense. You're not going to "make" users read. If the decision is that crucial, then you're better off finding a way to mitigate the danger rather than handing a presumed-careless user a loaded gun.

Making the "safe" button default (triggered by enter/spacebar/etc.) is a good idea regardless, simply because if they surprise the user then a keystroke intended for the expected window won't accidentally trigger the unexpected action. But even in that scenario, you must be aware that by the time the user has realized what they've done, the choice is already gone (along with any explanatory text on the dialog). Again, you're better off finding another way to give them information.

回复 原文
酒儿 2024-07-18 05:31:10

在某些情况下，我所做的是将消息框显示的时间与消息框被关闭的时间进行比较。 如果少于“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

What I've done in some instances was to compare the time of the message box being shown with the time of it being dismissed. If it was less than 'x' amount of seconds, it popped right back up. This forced them, in most cases, to actual read what was on the screen rather than just clicking through it blindly.

Fairly easy to do, as well....

Something like this:

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
回复 原文
浊酒尽余欢 2024-07-18 05:31:10

归根结底，您不能强迫用户做他们不愿意做的事情...他们总会找到一种方法来绕过它

  • 快捷键来绕过将鼠标移动到移动按钮的要求。
  • 向下滚动到 EULA 底部而不阅读它以继续。
  • 启动软件，然后去喝茶，同时等待导航屏幕启用“确定”按钮。

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

在将用户的行为责任归咎于用户之前，您只能走这么远。 告诉用户他们的行为被记录下来会让他们更加小心——如果他们被追究责任，他们就更有可能做正确的事情。 特别是如果有一条精心设计的消息，内容如下：

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

然后是一个带有“是的，我接受对我的行为负责”的复选框和两个按钮：

  • “是的，我想删除它”只有在选中该复选框时才应启用此按钮。
  • “哦，糟糕，这不是我的意思”这个按钮总是可以启用的。

如果他们删除了该表并且公司陷入停顿，他们就会被解雇。 然后备份恢复，每个人都像拉里（无论拉里是谁）一样高兴。

At the end of the day you can't force a user to do something they're unwilling to do... they will always find a way around it

  • Short cut keys to bypass the requirement to move the mouse to a moving button.
  • Scrolling down to the bottom of the EULA without reading it to enable to continue.
  • Starting the software and then going to get their cup of tea while waiting for the nag screen to enable the OK button.

The most reliable way I've seen this done is to give a multiple choice question based on what is written. If they don't get the answer correct, they can't continue... of course after a couple of times, they'll realise that they can just choose each of the answers in turn until the button enables and then click it. Once again meaning they don't read what was written.

You can only go so far before you have to put the responsibility on the user for their actions. Telling the user that their actions are logged will make them more careful - if they're being held accountable, they're more likely to do things right. Especially if there's a carefully crafted message that says something like:

This is being logged and you will be held accountable for any
repercussions of this decision. You have instructed me to delete
the table ALL_CORPORATE_DATA. Doing so will cause the entire company's
database to stop working, thus grinding the whole company to a halt.
You must select the checkbox to state that you accept this responsibility
before you can choose to continue...

And then a checkbox with "Yes, I accept the responsibility for my actions" and two buttons:

  • "YES, I WANT TO DELETE IT" this button should only be enabled if the checkbox is checked.
  • "OH CRAP, THAT'S NOT WHAT I MEANT AT ALL" this button can always be enabled.

If they delete the table and the company grids to a halt, they get fired. Then the backup is restored and everyone's happy as Larry [whoever Larry is] again.

回复 原文
情话已封尘 2024-07-18 05:31:10

请不要这样做。 这不会产生任何积极效果：您试图避免人们单击“确定”而不是“取消”，方法是使他们可能单击“取消”而不是“确定”（好吧，他们可能会再试一次）。 但！ 当人们确实想取消时，你不妨让他们单击“确定”，这可能是一场真正的灾难。 这只是没有好处。

Do NOT do it, please. This will have no positive effect: You are trying to AVOID people's clicking OK instead of Cancel, by making them potentially click Cancel instead of OK (okay, they may try again). But! you might as well achieve people's clicking OK when they really want to cancel and that could be a real disaster. It's just no good.

回复 原文
薄荷梦 2024-07-18 05:31:10

为什么不重新设计 UI，使 OK 成为“安全的选择”？

Why not reformulate the UI to make the OK the "safe choice"?

回复 原文
~没有更多了~

关于作者

旧人

暂无简介

0 文章
0 评论
25 人气
发私信

相关话题

更多

热门标签

操作系统 程序设计 IT运维 Linux系统管理 JavaScript 服务器应用 solaris C/C++ PHP Shell BSD Vue.js aix Oracle Python HTML 系统管理 HTML5 CSS 前端
更多

推荐作者

书间行客

文章 0 评论 0

我ぃ本無心為│何有愛

文章 0 评论 0

神妖

文章 0 评论 0

undefined

文章 0 评论 0

38169838

文章 0 评论 0

彡翼

文章 0 评论 0

更多

友情链接

文江博客
    我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站，即表示您同意使用 Cookies 和您的相关数据。
    原文