从交互的角度讲讲弹窗(上)

3 评论 12907 浏览 124 收藏 15 分钟

编辑导读:弹窗是吸引注意力的一种方式,不管是PC端还是移动端都广泛使用。本文作者从交互设计的角度,对弹窗进行分析,与你分享。

过去几周我们都在讲一些非常玄学的设计理论相关内容,这周换一下口味,我们继续来讲基础控件。

不知道大家对交互设计中的控件持一个什么样的态度,反正我自己入行的时候其实是挺“怕”这玩意的。这些东西好像都来头不小,让我一个不小心就犯很多体验错误。但现在来看这样的心态其实很不必要,因为尽管控件设计有很多约定俗成的规则,但严格来说控件的应用不该讲“对”和“错”,只讲一致性与更好地贴合场景。面对控件时态度放松一点,也能让人更好地去思考未来改进的可能性。

另外,由于市面上已经存在很多比较基础的、移动端场景下或者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的这个侧边栏,虽然也是设置,但采用了非模态面板+即时生效。

本文由 @白话说交互 原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 我觉得这些弹窗还在我都可接受范围内。而且文章讲的很好啊!对我来说很有意义

    来自广东 回复
  2. 昨天刚看到一篇文章说弹窗有法律限制了哈哈。

    来自广西 回复
  3. 每天起床最害怕的就是一连接到网络就有无数弹窗,打得我措不及防,一气之下全给关了

    来自广东 回复