确认框的设计

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

类别

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

询问

转推的确认框

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

告知

Flickr 的告知

告知，类似 Javascript 里的 alert（），即：做的状态。

必要性

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

行为是否主动

是。既然是用户自己主动做了这个决定，那么确认框有设计过度之嫌

不是，但用户容易误操作。先解决“误操作‘的问题，再来谈确认框吧

不是。剔除确认框

结果能否挽回

不能。真的不能吗？难道不知道这对于用户来说非常重要吗

真的不能。使用确认框

能。剔除之

信息可否忽略

不可以。真的不可以吗？流程上不能再优化了吗

真的不可以。使用确认框

可以。剔除之

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

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

设计

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

可控

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

Javascript 原生类型

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

样式因操作系统（和浏览器）而异

体验无法与全站融洽

无法更改按钮文案和样式

没有档次

没有情感

弹出层类型

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

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

遮罩。使用遮罩，因为确认框里的内容很重要。颜色则取决于网站的情感基调，与重要性无关（因为真的很重要）；保持遮罩层颜色的统一

位置。相对居中

标题。不设置标题

内容格式。左对齐，具体格式依内容而定

按钮格式。居中或右对齐

图片。没有，或者最多一个

移动。可以移动，并保持滚动

退出响应。必须点击某个按钮才能做出相应响应，因为确认框很重要。同理，不设置右上角的 “×”

快捷键。可以考虑，记得照顾视觉障碍的用户

 更多关于 云服务器， 域名注册， 虚拟主机的问题，请访问 西部数码官网： www.west.cn