不知道大家对交互设计中的控件持一个什么样的态度,反正我自己入行的时候其实是挺“怕”这玩意的。这些东西好像都来头不小,让我一个不小心就犯很多体验错误。但现在来看这样的心态其实很不必要,因为尽管控件设计有很多约定俗成的规则,但严格来说控件的应用不该讲“对”和“错”,只讲一致性与更好地贴合场景。面对控件时态度放松一点,也能让人更好地去思考未来改进的可能性。
另外,由于市面上已经存在很多比较基础的、移动端场景下或者 UI 角度的弹窗文章,所以这一篇我将着重讲一讲 PC 端那种特复杂的大弹窗怎么做,内容比较多,所以会分两期。
想象一下你去一家意大利餐馆吃晚饭,正餐刚端上来你正吃的高兴呢,一个服务生空着手走到你旁边戳戳你:“这位客人,外面有个人叫你,你站起来跟我过去一下。”你不得不(很不情愿地)暂停吃饭,站起来跟他走了。
同一个吃晚饭的场景,假如这次服务生端着托盘走了过来,你一抬头,他“啪”一下把托盘上的罩子打开,盘子上放着一个小纸条,并且示意你拿起来看看。
在交互设计中,假如把全页面的跳转类比成那个叫你“站起来跟我走”的服务生,弹窗就是那个端着托盘的服务生。他用一个新的任务或信息(托盘里的纸条),打断了用户原本的任务(吃饭),但是并没有把用户从桌子上拽起来,完全离开当前场景——也就是饭桌。
因此可以这么说:网页与移动端设计中,弹窗本质上是一种对用户注意力的引导形式。它弱于全页面跳转、可能具有打断性,要求用户从原来的场景中抽出一部分精力来应对它。
既然弹窗是引导注意力的一种形式,那是不是所有引导注意力的控件,都能叫弹窗呢?
在 PC 应用程序设计的时代,所有的任务都是在窗体或者窗口 (window)上面完成的。因此实际上不存在所谓“全页面”和“弹窗”的差异,只有“这种窗口”和“那种窗口”的差异。比如在我的这篇文章里出现过的两种“弹窗”,在 windows 7 中同属于 dialog box 类;而除了这种窗口(弹窗),当时还定义了 wizard、property sheet 等多种不同的窗口样式。每种窗口都有一个主要的解决问题与标准样式。
PC 设计从应用程序进入网页时代后,用户不再在多个窗口之间跳来跳去,而是在一个网页窗口下完成任务。因此在网页状态下,设计师模仿继承了“窗口”的样式与交互形式,产生了我们熟悉的“弹窗”。
随着网页/移动端设计的不断发展,我们也发现,其实不用完全依照应用程序设计窗口的那一套来做弹窗或者做触达,因此网页/移动端产生了很多独有的设计样式。这些样式虽然起源于窗口,但更灵活多变、和传统意义上的“窗口”有一些差异。
由于中文表达的含糊和不清晰,现在国内设计界倾向于把这些形形色色的触达/操作形式全部都统称为“弹窗”,但细究起来,我们甚至可以画一张九宫格:
你是弹窗原教旨主义者吗?
我在这里无意于给“弹窗”这个概念正本清源,但为了下文能够更有指向性,我们这里只把“层级高于页面的”、“容器大概是个方形”的控件纳入接下来“弹窗”的概念范围。并且由于 callout/tooltip 的一些变体和 menu 菜单不太好区分,为了方便,这期就不讲这些比较小的非模态控件了。
同时我也认为,大家日常工作中特别是做控件的时候,可以去思考一下控件的具体定义,以防沟通起来鸡同鸭讲。
还是承接上文那个吃饭场景,那个端着托盘的服务走后,你急急忙忙放下刀叉,把字条从托盘里拿出来:展开一看发现上面写的是——
气不气人?
你可能当场就想跳起来大骂服务生:这点事情需要这时候来打扰我吗?
同样的道理,既然弹窗只是一种形式,那么是否选择这种形式,必然是由其实质内容(也就是场景与任务)决定的。我基于我自己的经验把弹窗的作用分成三种(当然你也可以分得更细,比如 IBM 就把他们的弹窗组件分成 5 种):
触达弹窗:这个弹窗是由系统触发的,而非用户主动触发的,一般用作信息通知,可能附带简单操作
信息展示弹窗:用户主动触发,一般用来收纳全页面上放不下的信息详情
操作弹窗:用户主动触发或受用户的操作触发,可能用来承载复杂操作(比如表单)
在决定要设计一个弹窗时,至少要思考三个关于弹窗内容的问题:
是否急迫:假如这是一个触达弹窗,用户是否需要马上处理/查看弹窗上的内容/任务?
具体情境:假如这是一个操作或信息展示型弹窗,用户在处理这个内容/任务时,是否需要对照或查看其他内容?这个内容/任务是否反复发生/需要反复处理?
生效方式:假如这是一个操作弹窗,用户是否需要对照自己处理的结果,再次对内容进行调整?
1. 是否急迫
这个问题决定了你需要占用多少用户注意力,是否要选择“弹窗”作为你的触达方式。
就像我们上面提到的,触达弹窗不是由用户自己触发的,因此这个弹窗肯定不在用户预期之内,这意味着用户有很大可能性不会去看这个弹窗。
对于触达弹窗来说,假如这件事情不那么急迫,不需要用户马上进行处理、或者用户根本处理不了,那么你可以考虑用以下方式弱化、降级触达:
- 降低视觉音量:模态弹窗变成非模态弹窗,或者设置弹窗消失时间
- 主动触达降级为被动展示:将触达弹窗变成用户主动点击查看
由于触达本身是个很大的话题,我们这里不做赘述。未来讲触达的时候再细讲。
2. 具体情境
对于操作或信息展示弹窗来说,这个问题决定我们选择组件的层级、以及是否需要阻断用户和页面其他内容的交互(也就是模态/非模态)。
想象这么一个场景:假如你是一个中学老师,你正在给每个小朋友写期末评语。学校提供的写评语系统长这样:
你发愁了:班上有 50 个孩子,每个人的期末评语得按照他们的平时表现和期末成绩来写。为了写这个评语,你得打开期末成绩 excel、打开学生档案,再打开百度搜索评语模板,一边复制、一边粘贴:
再来一个场景:假如你是一个第一天上岗的客服,用户来找你咨询:“这件衣服有几个码呀?我能穿上吗?”
你一愣,“等等哦,我给你去查查”,然后打开了商品链接一通翻找。等你找到了,关闭商品页正准备回复呢,这时候客户也消失了。
这就叫完成任务时,需要“对照或查看”其他内容。这种情况下假如设计一个模态弹窗,的确好像起到了“引导注意力、让用户专注当前任务”的效果,但也严重影响了用户完成任务的能力。对此,我们一般有以下几种方式来解决:
- 尝试不用弹窗,而采用侧边栏来承载信息或任务
- 使用各种形式的非模态弹窗,来让用户在完成任务的同时,可以自由行动、甚至允许暂时中断任务
比如第二个案例里,我们可以尝试用侧边栏承载商品信息,这样客服就不需要离开当前聊天页面,而可以直接通过侧边栏获取商品规格,直接给到顾客及时的反馈。
而在第一个案例中,也许我们可以尝试在学生的单人信息页上打开侧边栏,或者做成停驻窗口(docked window)的形式。这样即使在输入中,用户也可以去查阅完成任务所必要的信息,降低任务的完成难度。
这个案例之所以我们不使用侧边栏,而采用了层级高于页面本身的面板来完成,主要还是考虑到写“期末评语”这个情景比较偏向长文本输入、一次性提交后不再支持编辑,所以相对于页面内输入,面板感觉起来比较“郑重”。这个就纯属个人习惯了。
3. 生效方式
这个问题在操作型弹窗非常多见。设计师用 Mac 的多,不知道平时打开系统偏好设置的时候,有没有注意过不同的菜单,右下角一会有“应用”和“复原”按钮,一会儿又没有。
很明显,这两种弹窗的生效方式(或者叫生效模式)是不同的。有提交按钮的弹窗,在你没有真正点击“提交”之前,所有的修改都只是暂存,并没有真正生效。而右边这种没有提交按钮的弹窗,在你与弹窗内容区交互时,就已经即时生效了。windows 给这两种模式起了名字:前者叫延迟提交模式 delate commit model,后者叫即时提交模式 immediate commit model。
我们大部分在网页端能见到的常规模态操作弹窗,都应该采用有提交按钮、需要再次确认的延迟提交模式:它的潜台词是,你可以仔细思考一下你键入的内容、选择的选项,随意修改到符合你的想法之后,再提交生效。相比起效率,这种模式更加关注准确性,填错了可能造成一些后果。
但假如你的任务本身操作量不大,但是变更很频繁,比起准确性、更关注效率,那么就应该思考是否可以采用非模态弹窗或者侧边栏+即时提交模式,来创造相对高效、轻量的体验。比如 windows edge 的这个侧边栏,虽然也是设置,但采用了非模态面板+即时生效。
欢迎关注作者微信公众号:「白话说交互」
复制本文链接 文章为作者独立观点不代表优设网立场,未经允许不得转载。
发评论!每天赢奖品
点击 登录 后,在评论区留言,系统会随机派送奖品
2012年成立至今,是国内备受欢迎的设计师平台,提供奖品赞助 联系我们
AI时代的设计师生存手册
已累计诞生 642 位幸运星
发表评论 已发布3条
↓ 下方为您推荐了一些精彩有趣的文章热评 ↓