“确定”与“取消”按钮 - UCD大社区

确认框的设计

小轰同学 — 2011-07-27 22:10:18

确认框，顾名思义，对关键的用户行为进行确认，比如“询问是否删除”，“告知已删除”。根据网上的观察，发现有的网站对确认框的设计缺乏合理性。本文谈谈自己的思考。

类别

根据触发目的，确认框分为两类：询问和告知。

询问

转推的确认框

询问，类似 Javascript 里的 confirm()，即：是否去做？

告知

Flickr 的告知

告知，类似 Javascript 里的 alert()，即：做的状态。

必要性

任何阻碍（打断）用户行为的动作，都应该三思而后行。冷静下来，我们真的、一定、必须打断用户的动作吗？不妨思考下面三个问题，来考量“必要性”。

行为是否主动

是。既然是用户自己主动做了这个决定，那么确认框有设计过度之嫌
不是，但用户容易误操作。先解决“误操作‘的问题，再来谈确认框吧
不是。剔除确认框

结果能否挽回

不能。真的不能吗？难道不知道这对于用户来说非常重要吗
真的不能。使用确认框
能。剔除之

信息可否忽略

不可以。真的不可以吗？流程上不能再优化了吗
真的不可以。使用确认框
可以。剔除之

必要性（上新浪微博，下腾讯微博）

两大微博都只能最多添加10个标签，超出限制后，它们的确认框如上。孰优孰劣？

设计

做确认框，就要保证其可用性。

可控

根据可控的程度分为：原生和弹出层两种。

Javascript 原生类型

JS 代码原生的 confirm() 确认框好处只有一个，那就是编码方便。弊端有：

样式因操作系统（和浏览器）而异
体验无法与全站融洽
无法更改按钮文案和样式
没有档次
没有情感

弹出层类型

注意：这里谈的不是弹出层，而是弹出层类型的确认框。

弹出层，因为是纯手工编写，完全可控，宏观上有：

遮罩。使用遮罩，因为确认框里的内容很重要。颜色则取决于网站的情感基调，与重要性无关（因为真的很重要）；保持遮罩层颜色的统一
位置。相对居中
标题。不设置标题
内容格式。左对齐，具体格式依内容而定
按钮格式。居中或右对齐
图片。没有，或者最多一个
移动。可以移动，并保持滚动
退出响应。必须点击某个按钮才能做出相应响应，因为确认框很重要。同理，不设置右上角的 “×”
快捷键。可以考虑，记得照顾视觉障碍的用户

文案

不多一个字

说匹配用户教育程度的语言
写出文案后，逐字删除，除非造成歧义
照顾用户的情感。这里多一个字，胜一万字

条理清晰

格式清晰
逻辑清晰

是的，有时候脑袋一热，逻辑就乱了。清晰的格式有助于理顺（自己和用户的）逻辑。

注明后果

再说一遍，真的很重要。

不使用判断词和代词

仅仅写“是”和“否”不如写“删除”和“取消”直接。

按钮

摆放

Flickr 混乱的按钮顺序

我们习惯说“是否”，我们说“Yes or No”，那么，就按照这个顺序来设置按钮的摆放顺序。（反过来也行，）务必在全站统一，不要一会左一会右，你叫用户点哪？

样式

与全站按钮的样式统一。不推荐使用 HTML 内置的按钮，毕竟已经到这一步了，再多做一点吧
分清主次。鼓励用户点击的按钮使用突出 / 鲜明的颜色，反之使用常色，或者干脆使用文字链接的形式

“取消”按钮看上去就不能点

避免使用灰色。因为灰色看上去无法点击。白色亦不赞同

选例分析

选取了三个“拖入到黑名单（阻止该人）”的例子。

正例1

豆瓣：把某人拖黑

亮点：

不多一个字
逻辑清晰
注明后果
确定=确定，避免了不能改动按钮文案的硬伤

正例2

谷歌+：阻止某人（把某人拖黑）

亮点：

囊括了豆瓣的全部亮点
体验统一
格式清晰
分清主次（更推荐使用醒目的红色）
不使用代词
可以挽回
通过照片唤起情感

反例

知乎：把某人拖黑

延伸阅读

小轰《可用性案例分析》 http://cuikai-wh.com/blog/1543

确定？没法确定！

kent.zhu — 2009-09-27 21:07:52

      “确定”与“取消”按钮应该可以算是Web应用里最无敌的组合了，你可以随处看到他们以及他们的姊妹组合“完成”/“取消”、“是”/“否”….当然，他们也不是每次都表述的是同一个交互动作，但是我们总会遇到。

       为什么会有“确定”与“取消”的组合？
      这个问题似乎是个废话。因为，Web应用中几乎你所有的动作都是可以取消的，这也是为什么每个浏览器都会有“后退”按钮的原因。
      当然，有的时候我们也会只看到“确定”在单飞。比如，波希米亚同学收集了国内30个著名网站的注册表单，我们看到只有雅虎中国、MSN中国、TOM和优酷的注册表单中有“取消”/“重置”按钮。
      也许是处于商业因素的考虑，他们只给用户单一方向的指引，系统限制用户回头；也许是产品人员认为用户完全可以在一页长的表单里手动清除掉填写错误的信息或者借助浏览器的“后退”按钮来解决自己遇到的麻烦。
      但是，在基本都是一页长的表单里没有“取消”或“重置”按钮显然是不够友好的。用户有权利结束自己的操作同时也有权利被允许重新开始自己的操作。一个“取消”按钮显然会比使用浏览器的“后退”按钮或者是“F5”刷新浏览器成本小的多。
     所以，从这点来看这30个表单中给我体验最好的无疑是优酷的注册表单。虽然雅虎中国提供了取消按钮，但是在点击取消的时候出现了下面尴尬的一幕….

      什么时候才会同时出现确定、取消
      确实，有的时候我们不需要取消按钮。比如评论框的表单里，我们只需要一个“提交评论”就足够了，因为我们没有可以取消的东西，你可以选择关闭页面停止浏览，你也可以选择点击链接进入下一篇文章的阅读。
      取消，主要用在对用户进行警示、询问用户操作这2个场景中。比如用户选择了进行了某项不可逆的操作的时候，我们需要警示用户是否确定要进行这项操作；用户选择了我们其实并不想让他进行的操作，比如删除帐户，我们希望用户三思。

      确定与取消不是万能的，需要更完美
      “确定”与“取消”按钮在大多数情况下都可以正常工作，但是意义更明显的按钮标记能更好的帮助用户建立对点击结果的期望。
      比如QQ邮箱的注册表单，单击这个“确定”按钮会发生什么呢？保存了我填写的信息还是把我注册为新的QQ邮箱用户？很明显，对于用户而言这个期望是模糊的。
      当然，我们很高兴的看到大多数网站的注册表单上都把“确定”按钮换成了一个更加明显的提示了，比如“注册”、“现在就加入”、….不过在软件领域里似乎这种令人生厌的做法已经持续了很久且一直没有改观，典型代表就是我们的浏览器弹窗提示…..
      直接使用“确定”与“取消”，是一个懒惰的设计师的表现与设计手法。这是一个值得注意与琢磨的细节，因为你的一个错误的提示可能会诱发N多用户错误的点击。

没法确定的确定按钮
比如下面的这个界面提示，我是点确定呢还是取消呢？我没法确定…..

比如，某博客网站在发布文章的时候可以选择全屏编辑器，他们会在屏幕的右下角设置一个“取消”按钮，这个取消是怎么个意思呢？取消本次的编辑退回到我的博客首页还是退出本次的全屏编辑进入到普通的编辑状态？我没法确定……

        关于确定与取消的按钮摆放
      目前流行的做法是遵照“费茨法则”，一个人在使用鼠标移动指针时，屏幕上目标的某些特征会使得点击变得轻松或者困难。目标离得越远，到达就越费劲；目标越小，就越难点中。设计成一个大的“确定”与一个小的“取消”组合或者一个大的“确定”按钮与一个超链接的“取消”组合。
      另外，关于是“确定”在左还是“取消”在左，mac系统与Win系统是个相反的做法，这是另外一个话题，有兴趣的同学可以研究一下。
      这里，UCDchina翻译小组的一篇文章中说到了这个问题：“确定”与“取消”按钮如何正确排序？

      最后，在寻找本文的例证的时候浏览几个网站后编的一个小段子
      问：一个网站如果弹出“是”、“否”、“取消”，你该选哪个？答：右上角的×。因为，他才懒的管你选的是哪个，他判断有鼠标点击动作就给你强奸了，所以先×它才是正确的！

相关话题：“确定”与“取消”按钮源地址：http://www.ikent.me/blog/1946

什么时候需要有“取消”按钮？

西贝 — 2009-02-16 03:29:51

在浏览web的时候，我们往往发现这样的一些组合：“确定”“确定取消”“确定关闭”“关闭”“取消”。到底哪个组合是对的呢？什么时候需要有“取消”按钮呢？

————————————————————实例使用篇————————————————————-

先来看实例：

这是写一篇新日志的页面。整个页面主要的内容就是写一篇新日志所涉及到的各种操作。有提交按钮、提交所输入的信息。有取消按钮，表示不要写日志了，要撤销刚才点击“写日志”按钮的这个操作。点击取消按钮，页面跳转至日志列表页。

发表评论功能是跟在一篇日志的最下面，整个页面上发表评论功能并不是主要内容（主要内容是日志正文），这里的取消按钮如果也像上面写日志页面上的取消按钮一样，页面跳转到日志列表页，显然就不对了。而如果和写日志中的取消按钮功能不同也不好，因为这两处实在太像了，两处相同样子的按钮功能却不同，显然也不对。
这里实际上不需要取消，因为没什么可取消的。之前的操作是“打开这篇日志的详情页”，而不是“发表评论”，“打开…”这个操作不需要取消按钮撤销。
“发表评论”这里的“取消”按钮实际功能是清空评论内容。那么这个按钮不应该叫“取消”，应该叫“清空”之类的。而在这个地方有这样一个清空功能似乎更多时候会使用户误操作，所以，这个按钮就该去掉了。这是另外的错误引发的另外的分析，不是这回主要要说的，到此为止。

对比这两个页面，写日志是需要撤销的，而发表评论是不需要的。

写日志页面有这样几个特点：
1. 用户主动点击了一个叫做“写日志”按钮后引出来的；
2. 按钮“写日志”表述为一种操作的；
3. 页面上充满表单元素，需要用户填写、提交。
那么，在写日志页面上，要为 “写日志”按钮提供相应的撤销操作的功能——取消按钮。

当然写日志页面上的取消按钮细研究起来还是有些问题的。在整个网站中，“写日志”按钮不止在日志列表页一个页面上出现过。那么点取消按钮返回日志列表页就不是很严谨了。如果取消按钮换做“返回日志列表页”这样一个链接，似乎就更准确了。类似下面这样：

“返回你的相片页面”——这种表现也可以理解为取消按钮的一种变型。

另外一种变型——页面右上角的叉子按钮：

————————————————————提示使用篇————————————————————-

还有就是一些标准信息提示页面用到的“取消”按钮！

! 警告性信息
界面元素：警告信息图标一定少不了，还有”是”、”否”、”取消”按钮，及相应的询问文字。
应用场景：用户由于误操作产生不可逆转的影响。对用户可能因为疏忽而没有进行的一些重要操作进行提示。所以需要采取提供提示的功能保护用户操作。警告icon表示将来会引起问题的情况。“警告不等于被弱化的错误”——对这句话的理解是，警告不能使用到不严重的错误。这里的“取消”按钮是不可缺少的！

? 询问性信息
界面元素：包含询问的信息图标、确认、取消按钮，及相应的询问文字。
应用场景：为避免用户做出误操作，请用户对其行为进行确认。随之要伴有相关的询问文字，一般来说，说明性和解释性语句不能超过2行，不能超过50个文字。提示性语句不能够太过于专业，尽量使用委婉的语句来表达相关的意思。当然简洁和不能重复也是一个关键的方面，同时记住语气一定要“温和/积极”。这里的“取消”按钮也是不可缺少的！

“确定”与“取消”按钮：如何正确排序？

mocha — 2008-11-11 20:02:35

Article copyright by Tom Tullis
Tom Tullis版权所有
作者：Tom Tullis；译者：UCD翻译小组，mocha
原文地址：http://measuringuserexperience.com/SubmitCancel/index.htm

引言

Web应用中“确定”和“取消”按钮（或者类似的其它按钮）的正确排列顺序这一话题引起了一些Web设计师、关注可用性的人以及一些极客们的讨论。来看几个例子：

在Windows平台下，多年以来的标准是，只要这样的按钮出现在模式窗口的底部，则一定是“确定”在左、“取消”在右的组合。不妨看看这份Vista用户体验指南。Sun公司的Java界面风格设计指南也是这样规定的。这背后的逻辑性似乎建立在西方从左到右的阅读顺序上，因此“确定”按钮（大概因为它比别的按钮更重要或更常用）被首先看到。
在Mac平台下，标准恰恰相反：模式窗口底部的那组按钮是“取消”在左，“确定”在右。详见苹果公司人机界面指南。它背后的逻辑性似乎体现在下方右边的按钮（“确定”）总是与前进联系在一起，就像读书时的翻页动作。
在Web环境中就没有什么明确的标准了。最贴切的例子可能是在一连串相关页面中应用“上一页”和“下一页”按钮，实际的标准是“上一页”在左边，“下一页”在右边，除非最后一页那里变成了“提交”或者“完成”按钮。

所以当Web设计师需要用到“确定”和“取消”两个功能时该怎么办呢？首先，让我们明确这两个功能到底是什么：

“确定”功能：它引发一个将要被执行的动作，比如保存更改的内容或者提交订单。Web上执行这个功能的常见标签有“确定”、“保存”、“提交”和“完成”。
“取消”功能：它引发一个将要被取消的动作，而且用户会返回到前一个状态或者最初的状态。Web上最常见的标签可能就是“取消”。（有时也会用“后退”，但它很可能会和浏览器的那个后退功能混淆。）“关闭”也是一个相关的功能，但它没有放弃将要处理的操作那层含义。

当我看到一个关于可用性的邮件讨论组上出现好几个关于Web应用中如何恰当地排列这些按钮的问题时，我决定做一个可用性和用户体验的网络调查来看看到底怎样的顺序是最佳的。

调查

这个调查使用SurveyMonkey。问卷有4个问题，如下图所示：

（点击图片查看大图。）

4个问题和各自的图片均包含两个变量：

按钮的放置：要么放在一起（第1题和第3题）要么分开放置（第2题和第4题）。
按钮的标签：要么是“确定”和“取消”（第1题和第2题），要么是“提交”和“取消”（第3题和第4题）。

为避免误导，标签（“确定”和“取消”，“提交”和“取消”）的顺序是随机的。如上图3所示，每个选项只能选一个答案。

我把这个调查的链接发到了那个关于可用性邮件讨论组上，同时也发给了我们公司Web设计师和用户体验专家组成的邮件列表。

结果

这个调查问卷在发布后的24小时内有效（2008年2月26号和27号之间）。共有64人参与了调查。4个问题的结果如下：

	A	B
确定	51%	49%
取消	50%	50%

评论：

两个按钮太近了。
但是“确定”应该是默认选项
如果是左撇子选择会相反
我受Windows标准影响太深了。
预期的或者积极的选择应该排在前面
“确定”和前进对应，“取消”和后退对应……
参考Windows的惯例
我更倾向“后退”而不是“取消”，“取消”看起来意味着选择到头了。
参考Windows弹出窗口的实践规范
参考“左页/右页”的惯例，B会翻到下一页
我觉得你可以把它和“前进”、“后退”联系起来，“后退”放在左边，“前进”放在右边。
我希望“提交”按钮或者代表“前进”的别的叫法的按钮放在最右边（就好象翻到下一页）。
在大部分西方惯例中是从左往右、从上往下读的。右下方的按钮应该代表前进。
“取消”这个标签太多地出现在不该出现的地方了。
我们的习惯是比较积极的选择放在右边。
这个问题是mac与pc之争，如果用mac我的回答会相反
对于右撇子，“确定”放在右边会更近。
在我们的文化中，右边的区域用来翻页，代表前进。
我觉得“取消”应该是个链接
不是只有在连环画才会画成这样，Windows平台下一切都是“确定”在左边，“取消”在右边。
应该和早期的Windows应用程序的标准设置相符

	A	B
确定	24%	76%
取消	76%	24%

评论：

如果一定要有一个“取消”按钮，就应该放在那。
但是我不会把它们放得间隔那么远，除非它们和其它按钮以某种方式组合在一起。
哪一种都行
我感觉他们看起来是分开的。
“确定”=前进，“取消”=后退
以前看见过它们是这样的排列顺序
再说一遍，“后退”比“取消”好
因为被放在边上，它们看起来更像是导航，因此右边的按钮意味着继续，左边的意味着后退
我从来不会把这两个按钮照这样分开。
我认为这样把它们分开意味着它们的功能更像“上一页”和“下一页”。
这没有意义，“A”是什么跟“B”代表“下一页”没有关系
比上一个图的放置好，因为把它们分开可以减少误操作
你可以把它们放到任何地方，它们的意义还是一样的！这不是“上一页”/“下一页”，而是“确定”/“取消”。
这问题有点伤脑筋。我觉得这要根据向导的上下文。在这个例子中，我主张A=“返回”，回到前一页面，B=“下一步”（到6个步骤中的第2个）。

	A	B
提交	42%	58%
取消	58%	42%

评论：

用Z形模式扫描
除非信息集中在左栏
真难选，有种观点认为要让积极的先出现，但这样就和“取消”矛盾了
我不喜欢“取消”！
用“提交”/“反对”怎么样？[Smart alec!]
“提交”=“确定”，所以我不会改变之前的答案。
用和“确定”/“取消”一样的原则

	A	B
提交	24%	76%
取消	76%	24%

评论：

都行
和之前的评论一样。
再说一遍——这没有任何意义。在这里应该用“下一页”和“上一页”
和第2题的评论一样，我认为这个设计只能用在一步步前进的情况下。否则，会让人迷惑。

讨论

最让我感到意外的是第1题的结果。就是把两个按钮放到一起，给它们“确定/取消”标签，问哪个应该是“确定”哪个应该是“取消”，两种选择的结果旗鼓相当。显然在可用性研究这个圈子里，没有任何一方对此达成一致观点。

把两个按钮分开的两个设计（第2题和第4题）的调查结果是最一致的。两种情况下，都有76%的受调查者认为应该把表示继续的按钮（“确定”或“提交”）放在右边，“取消”放在左边。

把按钮放在一起、用“提交”/“取消”标签（第3题）的那组调查的结果则介于之间：58%的人把“提交”放在右边，“取消”在左边，而另外42%的人选择相反。这与均分概率（50/50）之间的差异刚好成为显著性差异（χ2分布P＝0.05）。

建议

我从这个调查得出的建议主要包括以下几点：

避免在Web应用中把标记为“确定”和“取消”的按钮放在一起（就像第1题那样）。这太有可能让你的用户对“确定”和“取消”的顺序问题产生与你不同的看法了。如果他们赶着做事，他们可能就碰巧选错了。

最好让不同的按钮有视觉上的分隔（可能不必像这个调查中表现出来的那么极端）。两个按钮分开放置时，把表示继续动作的按钮（如“确定”、“保存”、“提交”等）放在右边，可能更符合用户的期望。

Luke Wroblewski有一篇有趣的文章叫做Primary and Secondary Actions in Web Forms，他用眼动议得出的数据分析“确定”和“取消”按钮的顺序。

若您有任何意见，请联系Tom@MeasuringUX.com。

表单中的重置与取消按钮

link — 2008-11-10 16:23:39

Article copyright by Jakob Nielsen

作者：Jakob Nielsen

译者：UCD翻译小组，Link
原文地址：http://www.useit.com/alertbox/20000416.html

大在大部分网页表单中，移除重置按钮会有效提升可用性，同样的，取消按钮对网页的意义也不太大。

启发式的交互设计中最基本的一点是在任何情况下为用户提供“紧急出口”，离开当前环境。撤销功能是最好的解决方法之一，基本原则只是告诉我们要提供撤销功能但并没有告诉我们怎么做。往往，不同的原则适用于不同的用户界面：

在基于窗口环境的用户界面中，取消按钮可以让用户通过对对话框的操作，实现探索性的学习。相比较而言，你在老些的系统中下达了错误的命令往往意味着你将陷入绝境。
在编辑系统中通常会有撤销命令来使文档回复到用户编辑之前的状态。有时，多级撤销和重复命令是很有用但又令人困扰的功能。

网页试图通过重置和取消按钮来复制以上特性，但用户往往更愿意通过浏览器的后退按钮来离开误入的页面。

不要使用重置按钮！

如果去掉所有重置按钮，网页将变为一片净土。这些按钮非但不能帮助用户，还可能伤害到他们。

重置功能会把用户输入到表单中的所有信息清除掉，但为什么用户要使用这样的功能呢？用户浏览网页的时候会在页面之间频繁转换，他们很少重复访问相同的表单，因此，表单在呈现给用户的时候就是干干净净的。而当用户使用相同的进程重新访问一个表单时，编辑原有的数据往往比重新填写更便捷。

重置按钮会在以下三个方面伤害用户：

最糟糕的问题是用户想点击提交却误点了重置，他们填写的信息将一下子付之东流。
在表单底部提供两个按钮将混淆交互界面并让用户难以搞清下一步要做什么。用户会把一小部分时间浪费在浏览无用的按钮和决定哪一个才是该点的上面。
当用户希望在表单中修改已经填写的信息时，面对额外的按钮会做出以下两个选择：
- 在输入框中修改不正确的内容
- 点击重置，在清空的输入框中重新填写内容

额外的选择会迫使用户进行额外的思考，而使用最佳的交互方式所节省的时间往往小于用户考虑决定使用最常用的方式所花费的时间。这将浪费用户一到两秒的时间来从中取舍，这也是尽量不要让用户选择的原因。（一秒钟听起来没什么了不起，但它意味着每年一亿美元左右的生产力浪费。）

让所有输入可撤销

去掉了重置按钮，我们有必要为用户提供其他的修改错误输入的方式。对于文本框和选择框来说，用户可以随时输入或恢复到最初的状态。

不幸的是，有些使用了非标准风格的单选框（radio button）和下拉菜单的表单并没有提供回到初始状态的选项，而这是网页设计的典型错误之一。往往，一旦用户选择了一个选项，就没有办法作出“什么都不选”的选择。永远别忘了在单选按钮和下拉菜单中加入明确的默认选项，否则你用户的麻烦就大了。（请参考复选框和单选按钮设计的13条军规）

例外：重复输入表单的重置按钮

当同时满足以下两个条件时，重置按钮将发挥它的作用：

表单总是由一个用户反复填写
填写的内容每次都有较大差异

即使某个用户经常使用一个表单，当填入的数据每次都很相似时重置按钮也不是十分必要的。在这种情况下编写原有的数据要比重新来过简单得多。

保守地使用取消按钮

网页并不像软件一样拥有对话框，而是一个用户游走于各个页面之间的导航环境。自从超文本导航成为用户的使用习惯，人们开始依赖后退按钮来逃离窘境。每当用户误入了不想进入的页面，他们就会自然而然地把鼠标放到后退按钮上。

因为后退是网页浏览中很常规的行为，单独的取消功能也就不是那么重要了。如果用户不喜欢当前的页面，可以肯定，后退按钮就要出场了。

当用户害怕自己提交了不想提交的信息时，可以为他们提供取消按钮，这样能够提供给他们比直接退出更安全的的感觉。

在需要多步填写的表单中用户会在超过一个页面上进行输入，这时取消按钮是个不错的选择，因为后退按钮不会撤销之前的输入。

当然，不能指望用户每次都点取消，应该有一个后端/后台逻辑来处理点击后退来中断多步输入的行为。额外的复杂性是我不推荐在网页中加入复杂应用的原因之一，更好的办法是使用另一种形式来实现。

购物车中的移除按钮

很有必要在购物车中添加特殊的按钮来帮助用户移除商品，我们无法知道用户是不是了解他们能够通过购买“0”件商品来取消购物。（但是反正这个小技巧也不影响其它用户，所以还是应该实现出来给懂的人用）

（作者：请参考拙作购物车的可用性，来了解更多表单设计中的规则）

到底什么时候使用用取消按钮就

Lisa Padol 问道：

"当你讨论取消和重置按钮时并没有提及停止（即在载入时停止页面）和刷新按钮，不是吗？

我觉得这不仅是可以接受的，也很必要为比如下载文件的过程加入取消按钮。"

她的假定完全正确，浏览器的“停止”按钮很好地加强了用户的控制权。而对于文件传输和其它一些得花好几秒钟的操作也应该这样做。设计师必须给Applet（网页上的Java应用）和

其它耗时的设计元素都加上停止功能。