取消按钮是否应该要求确认？ [关闭]答案

【问题标题】：Should a cancel button ask for confirmation? [closed]取消按钮是否应该要求确认？ [关闭]
【发布时间】：2025-11-24 01:15:01
【问题描述】：

如果用户点击取消按钮，是否会弹出对话框要求确认？

如果是这样，应该一直这样，还是只在表单上有未保存的更改时？

【问题讨论】：

标签： winforms user-interface

【解决方案1】：

没有，除非它是非常重要/可能有害的东西。弹出窗口后面跟着弹出窗口很烦人。

【讨论】：

【解决方案2】：

如果取消操作会破坏数据或设备，是的。例如，在升级某些设备的固件过程中取消。

如果正在执行的操作需要很长时间并且意外取消需要重新开始，是的。

例如，当我决定关闭一个标签而不是对我的一个问题进行编辑时，我不发现 * 上的弹出窗口很烦人。

【讨论】：

+1 表示耗时操作。虽然我不同意“取消操作会破坏数据”。几乎所有的表单都接受用户的一些输入，如果按下“取消”，就让它成为“取消”！

【解决方案3】：

“取消”是指在行动开始之前放弃。如果该操作已经开始，则该命令应命名为“Stop”。这让用户清楚地知道该按钮可能会在中途中断某些内容。

真正的取消操作不需要确认，因为它不会导致任何问题。停止动作可能，但前提是中途停止可能会使事情处于混乱状态。（在这种情况下，您应该考虑找到一种方法让停止退出所有已经进行的更改，以便状态恢复到操作开始之前的状态。当然，这并不总是可能的，例如如果您要删除文件。）

【讨论】：

【解决方案4】：

这真的取决于情况。

例如对视频进行编码，一个可能需要数小时的过程，应该得到确认，因为您可能不小心按到了 99% 的按钮。

另一方面，安装程序或其他应用程序的初始化过程不需要确认，因为它通常可以足够快地重新启动并且不需要很长时间。

如果单击“取消”会启动一个可能需要很长时间的过程（假设它需要撤消更改），则应通知用户这一点，可能会通过弹出窗口通知用户，但按钮旁边的一些文本也可能就足够了.

一般规则是尽可能减少确认对话框，例如，如果可以将其替换为撤消操作。不过，我认为这不适用于大多数“取消”按钮。

【讨论】：

【解决方案5】：

使用以下算法来确定问题的答案：

if (1-p)*w > p*a then ask for confirmation

在哪里

p 是用户真正想要取消的概率（0.7 左右）
w 是由于无意取消而损失的（工作）时间量
a 是由于烦人的确认而损失的时间（5 秒左右）

当然，你必须估计 p、w 和 a。使用我的默认值，当无意取消会花费用户超过 10.5 秒的时间时，您应该要求确认。因此，在长时间操作的情况下，例如编码视频，您不应该询问用户是否在开始该任务后的 10 秒内单击取消。在数据录入的情况下，不要问表单是否还完全为空，而要问用户是否已经录入了数据。

【讨论】：

【解决方案6】：

让操作无需确认即可轻松完成（不要惹恼您的用户！）。但是，也可以轻松撤消。阅读 Alan Cooper's About Face 以获得许多好的 UI 建议。

【讨论】：

是我的问题还是 SO 的链接插入机制很臭？
只有你。不是每个人都会把垃圾扔进链接。

【解决方案7】：

基本上，如果撤消取消操作困难、耗时或不可能，您应该提示用户。当用户做了一些他们可能希望保留的操作（例如，写博客文章和关闭选项卡、更新硬件设备上的固件、运行系统更新、安装大型软件）而不是仅仅删除时，通常会出现这种情况当前状态。毕竟，有时可能会意外单击取消按钮。您只需要使用常识来确定如果操作被意外取消（这将需要取消提示）是否会给用户带来非常糟糕的体验，或者他们是否可以轻松地重新启动意外取消的任何操作而不会造成太大损失.我用来解决这些问题的策略是设身处地为用户着想，即把自己想象成这个程序的用户。如果我不小心点击了取消，我会有什么感觉？？？如果这种心态很严峻，请添加提示以防万一。

【讨论】：

【解决方案8】：

最好不要提示，但如果可能的话，一旦取消取消就很容易撤消。 GMail 在这方面做得很好。您单击“删除”，它会删除，但您会在顶部看到一个链接说“撤消删除”。

【讨论】：

【解决方案9】：

我认为答案是数据。

如果用户对数据进行了更改，而不是在界面上单击某处，则应要求用户确认退出。但如果没有发生变化，就没有理由确认。因为确认是用户的努力。

【讨论】：