确认框的设计

标签: 设计 | 发表时间:2011-07-28 09:09 | 作者:小轰同学 Jacky
出处:http://ucdchina.com/rss/all

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

类别

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

询问

转推的确认框

转推的确认框

询问,类似 Javascript 里的 confirm(),即:是否去做?

告知

Flickr 的告知

Flickr 的告知

告知,类似 Javascript 里的 alert(),即:做的状态。

必要性

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

行为是否主动

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

结果能否挽回

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

信息可否忽略

  • 不可以。真的不可以吗?流程上不能再优化了吗
  • 真的不可以。使用确认框
  • 可以。剔除之
必要性(上新浪微博,下腾讯微博)

必要性(上新浪微博,下腾讯微博)

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

设计

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

可控

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

Javascript 原生类型

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

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

弹出层类型

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

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

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

文案

不多一个字

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

条理清晰

  • 格式清晰
  • 逻辑清晰

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

注明后果

再说一遍,真的很重要。

不使用判断词和代词

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

按钮

摆放

Flickr 混乱的按钮顺序

Flickr 混乱的按钮顺序

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

样式

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

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

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

选例分析

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

正例1

豆瓣:把某人拖黑

豆瓣:把某人拖黑

亮点:

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

正例2

谷歌+:阻止某人(把某人拖黑)

谷歌+:阻止某人(把某人拖黑)

亮点:

  1. 囊括了豆瓣的全部亮点
  2. 体验统一
  3. 格式清晰
  4. 分清主次(更推荐使用醒目的红色)
  5. 不使用代词
  6. 可以挽回
  7. 通过照片唤起情感

反例

知乎:把某人拖黑

知乎:把某人拖黑

延伸阅读

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

相关话题:“确定”与“取消”按钮 源地址:http://cuikai-wh.com/blog/1924

相关 [设计] 推荐:

为了设计而设计

- - 幻风阁|kent.zhu'sBlog
我有个习惯,每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实,强调功能的实用性,后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎,各类App纷纷上演换装游戏,一个比一个做的精美,即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊,我说目前的移动产品设计可以分为2类,一类是做给用户用的,一类是做给设计师们欣赏与收藏的.

杯盖设计

- Yu - 创意设计-有趣、时尚、另类的创意
微向上的设计,在倒水完毕的时候可以让水滴顺着杯盖回流到杯子中,而不会随意的滴下来. 虽然是细小的设计,但是考虑的却是生活的便利.

再设计Redesign

- Mark - 腾讯CDC
  一个网站的核心是它的功能和内容,而设计则决定了这些功能、内容如何被组织和展现出来.   对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上,尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路,一是对现有问题挖掘然后改进,二是提出完全创新的想法.

简约设计

- - 淘宝网通用产品团队博客
写下这个标题,那么首先得要明确什么叫简约. 简约就是让用户操作简单,让用户更快的达到自己的目的. 一个产品在于解决一个需求,如何让用户最好的完成需求就成为一个产品经理首先得要解决的问题. 那么在日常工作中,我们又有什么可以做的呢. 在《简约至上》里面有四种策略,但是有的东西太高级了,在平时的工作未必能够用得上,所以我自己来提炼一下,看看日常工作中能够遇到并且可以解决问题的方法.

再设计Redesign

- 小趴 八足趴 八足 ramener - 互联网的那点事...
一个网站的核心是它的功能和内容,而设计则决定了这些功能、内容如何被组织和展现出来. 对已成功的网站进行再设计——重新构造它的组织和展现形式是具有挑战性的. 偏偏有设计师喜欢迎难而上,尝试对facebook、google这些著名网站进行概念设计. 他们通常有两条思路,一是对现有问题挖掘然后改进,二是提出完全创新的想法.

HBase表设计

- - 互联网 - ITeye博客
默认情况下,在创建HBase表的时候会自动创建一个region分区,当导入数据的时候,所有的HBase客户端都向这一个region写数据, 直到这 个region足够大了才进行切分. 一种可以加快批量写入速度的方法是通过预先创建一些空的regions,这样当数据写入HBase时,会按 照 region分区情况,在集群内做数据的负载均衡.

ODS设计

- - 开源软件 - ITeye博客
在一般的数据仓库应用系统中,根据系统体系结构的不同,数据仓库设计的内容和范围不尽相同,并且设计方法也不尽相同,下面的两幅图示分别表示带有ODS的 数据仓库应用系统体系结构和不带ODS的数据仓库应用系统体系结构. 本文将说明两个体系结构上的差异以及这种差异造成的设计方法的不同,并且重点介绍带有 ODS的体系结构中数据仓库的设计方法.

HBase Schema 设计

- - IT瘾-dev
HBase 与传统关系数据库(例如MySQL,PostgreSQL,Oracle等)在架构的设计以及为应用程序提供的功能方面有很大的不同. HBase 权衡了其中一些功能,以实现更好的可扩展性以及更灵活的模式. 与关系数据库相比,HBase 表的设计有很大的不同. 下面将通过解释数据模型向您介绍 HBase 表设计的基础知识,并通过一个例子深入探讨 HBase 表的设计.

HBase RowKey 设计

- - IT瘾-dev
1.1 RowKey对查询的影响. HBase中 RowKey 用来唯一标识一行记录. 在 HBase 中检索数据有以下三种方式:. 通过 get 方式,指定 RowKey 获取唯一一条记录. 通过 scan 方式,设置 startRow 和 endRow 参数进行范围匹配. 全表扫描,即直接扫描整张表中所有行记录.