从交互的角度讲讲弹窗（下）

3. 操作弹窗的“弹窗叠弹窗”

“弹窗叠弹窗”，或者“父子级弹窗”是一种古老的交互形式，在PC应用程序设计场景下，所有的任务都在弹窗的前身——窗口或窗体（window）下完成，因此窗口相互重叠是不可避免的。

应用程序端的窗口重叠有两种情况：物理上的重叠与层级上的重叠。

用户在windows和mac或者其他操作系统上可以打开多个窗口，但用户不可能同时和所有的窗口互动，因此窗口拥有的一项特性：当存在多个窗口时，只有最顶层的窗口是正在与用户互动的窗口，称为“活动窗口/当前窗口 active window”。用户的输入焦点、键控都仅对当前活动窗口生效。

我们从这种设计中可以发现在窗口物理上有重叠的情况下，系统虽然允许用户快速切换窗口，但事实上限制了每次和用户交互的窗口。

同时，在桌面端上也允许存在从属于某个主弹窗的次级弹窗。这种“次级弹窗”更类似于网页端所讲的“模态弹窗”，如果你不关闭它就无法与其父级弹窗交互，所以我把这种弹窗的重叠称之为“层级上的重叠”。

虽然“弹窗叠弹窗”这种设计形式历史悠久，但是问题也颇多。其中最明显的两个问题如下：

1. 弹窗层级过多，不容易找到可交互的活动窗口
2. 多层嵌套弹窗的生效模式比较反直觉，并且经常在网页端被错误应用

第一个问题我相信大部分用过windows的人多少碰见过。windows的次级窗口（ owned window ）可以随意拖动，位置并不固定，而且部分windows版本中并不展示在底部栏taskbar上，所以有时并不容易一眼发现到底应该操作哪里。

因此Mac改进了它的次级窗口样式，使其紧贴父级窗口的标题栏，这样窗口的从属关系比较明确，一眼容易发现可操作的位置。

类似的问题在网页端上也比较容易出现。当弹窗层级过多，而当前最顶层的模态弹窗容器又比较小时，页面噪音就过多了。

这个时候用户就要费好大的劲儿从一堆弹窗中找到最顶层那个的可交互弹窗，不说交互体验如何，视觉上就不太简洁，也就丢失了弹窗“引导用户注意力”的基本价值。

第二个问题其实发生得很普遍。举个例子，假如你现在在做一款人力资源管理系统，现在有一个“编辑员工角色”的弹窗长成这样：

前端一看哎呀太好了，我们刚好之前做了一个“新增角色”弹窗，直接往这个“编辑员工角色”弹窗上一放就解决问题了，甚至还不打断用户的工作流，我看体验非常好：

此时假如用户点击“确认新增”，就对输入的字段进行校验，没问题了那么角色就在后端保存上了。

此时回到上一级“编辑员工角色”弹窗，用户立刻就能在“角色”下拉框中找到自己刚刚新增的角色，但美中不足的是假如用户在“编辑员工角色”弹窗上点击“取消”，那只是取消了对员工角色的编辑，角色的新增操作已经生效了。好像没什么问题是吧？

然后我们举第二个例子：假如我们作为HR正在新增一群员工，每个新员工可以有自己的花名和备注，但我们也可以现在不填，等以后再说。新增员工的弹窗长这样昆明蓝v代运营优势：

假如花名和备注因为填写频率不太高，所以被放在了二级弹窗上，那么：

现在点一下“确定”，前端校验仍然可以做，但员工徐莉莉的花名和员工备注只是在弹窗上暂存，除非用户在“新增员工”弹窗上点一下“确认新增”，否则这批新员工的数据都不会提交后端保存（毕竟员工花名和备注大概率是和员工姓名存在一张表上的选填字段）。

上面两个例子讲到这里不难发现，虽然它俩看起来长得一模一样，但是数据的提交方式却存在差异。当出现这种问题时，就非常难以简洁地和用户解释为什么类似的交互形式造成了截然不同的后果。

一般来讲，我们做父子级弹窗+延迟生效模式时，（不清楚什么叫延迟生效模式也请看前篇）采用第2个例子数据提交方式，即子级弹窗的数据仅作暂存，当父级弹窗提交时才一起生效；另外假如存在第1个例子的情况时，一般以导航的形式打开新的网页窗口引导用户前往“新增角色”模块进行操作，而避免和第2个例子造成混淆。

但总体而言，应该尽量在网页上避免操作弹窗叠操作弹窗的设计方式，并且完全杜绝2级以上操作弹窗的重叠，因为大部分用户很难理解这其中的弯弯绕绕。

4. 流程弹窗/多级弹窗

流程弹窗的历史和多级弹窗其实都是在同一个弹窗容器上做内容的变化，它俩的差异是：

• 流程弹窗有步骤上的顺序（上一步、下一步），并且一般与延迟生效模式搭配，在最后一步统一提交信息。
• 多级弹窗没有步骤上的顺序，且往往与即时生效模式搭配（尽量避免与延迟生效模式搭配，否则会存在与弹窗叠弹窗一样的问题）

不管你用哪一种弹窗类型，注意弹窗只有一个容器，因此右上角的“X”是对流程/多级弹窗起全局作用的关闭按钮。近年来B端/工具型产品的形态愈发复杂，多级弹窗也变成了一个比较常规的设计方式，建议大家cctv1次广告费花点时间搞搞清楚。

比如说飞书的【分享】功能，就有这么一个非模态的、介于context menu和dialog之间的东西，也符合我们【层级高于页面、容器是方形】的弹窗定义。

5. 连续弹窗

一般不存在多个不同的操作弹窗衔接在一起，但是因为种种原因，连续给用户弹多个反馈/再确认弹窗还是挺常见的。我们在这里就简短地带过一下这种情况。总体而言，我把连续弹反馈弹窗分成两种类型：

把用户当大傻子型：意图用多重再确认来阻止用户进行一件事情（一般是卸载软件），我们都知道这体验很差，假如用户体验并不是你的产品主要的考量点，那么当我没说。

绝大部分的场景下，合理设置再确认弹窗能够避免99%的误触，虽然亦有意见表示用户可能日常关闭各种弹窗已经形成了肌肉记忆，只有一次的再确认弹窗可能顺手就被关闭了，可能并没有起到防错的作用。

所以极少数误触造成问题比较严重的场景下，可以用输入文字等方式提高再确认弹窗的操作成本，但绝大多数产品的绝大多数场景只需要1个常规的再确认弹窗就够了。

产品各干各的型：当一个模块有多个产品经理负责时很容易出现这种情况，每个产品都提出了自己的再确认措施，并且各调各的接口，每个弹窗的触发规则都有点差别。

那么这种情况就需要交互去协调同一个产品的不同再确认弹窗弹出逻辑，尽量把这些弹窗的重点信息整合在一个弹窗上，并且优先展示阻断性的问题，建议、不那么急迫的事情优先级适当往后调。

到这里弹窗篇彻底写完了，非常感谢大家的支持。

本文由 @白话说交互 于，，。

题图来自unsplash，基于 CC0 协议