不知道大家对交互设计中的控件持一个什么样的态度，反正我自己入行的时候其实是挺“怕”这玩意的。这些东西好像都来头不小，让我一个不小心就犯很多体验错误。但现在来看这样的心态其实很不必要，因为尽管控件设计有很多约定俗成的规则，但严格来说控件的应用不该讲“对”和“错”，只讲一致性与更好地贴合场景。面对控件时态度放松一点，也能让人更好地去思考未来改进的可能性。
另外，由于市面上已经存在很多比较基础的、移动端场景下或者 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 的这个侧边栏，虽然也是设置，但采用了非模态面板+即时生效。
前言产品经理：我觉得这里要加个弹窗，你去设计吧。
阅读文章 >欢迎关注作者微信公众号：「白话说交互」
本篇来源：优设网
原文地址：https://www.uisdc.com/popup-design
广告
