为了设计而设计
- - 幻风阁|kent.zhu'sBlog我有个习惯,每天晚上睡前会搜罗一遍最新的App用用. 最开始的时候ios的App还相对比较朴实,强调功能的实用性,后来不知何故吹起一阵ios的App必须足够精美的怪风. 于是乎,各类App纷纷上演换装游戏,一个比一个做的精美,即使是一个很工具性的应用也把自己浓妆艳抹的往坐台小姐的风格搞……. 上周末跟Tony和Angela在下厨房喝茶闲聊,我说目前的移动产品设计可以分为2类,一类是做给用户用的,一类是做给设计师们欣赏与收藏的.
确认框,顾名思义,对关键的用户行为进行确认,比如“询问是否删除”,“告知已删除”。根据网上的观察,发现有的网站对确认框的设计缺乏合理性。本文谈谈自己的思考。
根据触发目的,确认框分为两类:询问和告知。
转推的确认框
询问,类似 Javascript 里的 confirm(),即:是否去做?
Flickr 的告知
告知,类似 Javascript 里的 alert(),即:做的状态。
任何阻碍(打断)用户行为的动作,都应该三思而后行。冷静下来,我们真的、一定、必须打断用户的动作吗?不妨思考下面三个问题,来考量“必要性”。
必要性(上新浪微博,下腾讯微博)
两大微博都只能最多添加10个标签,超出限制后,它们的确认框如上。孰优孰劣?
做确认框,就要保证其可用性。
根据可控的程度分为:原生和弹出层两种。
JS 代码原生的 confirm() 确认框好处只有一个,那就是编码方便。弊端有:
注意:这里谈的不是弹出层,而是弹出层类型的确认框。
弹出层,因为是纯手工编写,完全可控,宏观上有:
是的,有时候脑袋一热,逻辑就乱了。清晰的格式有助于理顺(自己和用户的)逻辑。
再说一遍,真的很重要。
仅仅写“是”和“否”不如写“删除”和“取消”直接。
Flickr 混乱的按钮顺序
我们习惯说“是否”,我们说“Yes or No”,那么,就按照这个顺序来设置按钮的摆放顺序。(反过来也行,)务必在全站统一,不要一会左一会右,你叫用户点哪?
“取消”按钮看上去就不能点
选取了三个“拖入到黑名单(阻止该人)”的例子。
豆瓣:把某人拖黑
亮点:
谷歌+:阻止某人(把某人拖黑)
亮点:
知乎:把某人拖黑
延伸阅读
- 小轰 《可用性案例分析》 http://cuikai-wh.com/blog/1543