3. 操作彈窗的“彈窗疊彈窗”

“彈窗疊彈窗”，或者“父子級(jí)彈窗”是一種古老的交互形式，在PC應(yīng)用程序設(shè)計(jì)場景下，所有的任務(wù)都在彈窗的前身——窗口或窗體（window）下完成，因此窗口相互重疊是不可避免的。

應(yīng)用程序端的窗口重疊有兩種情況：物理上的重疊與層級(jí)上的重疊。

用戶在windows和mac或者其他操作系統(tǒng)上可以打開多個(gè)窗口，但用戶不可能同時(shí)和所有的窗口互動(dòng)，因此窗口擁有的一項(xiàng)特性：當(dāng)存在多個(gè)窗口時(shí)，只有最頂層的窗口是正在與用戶互動(dòng)的窗口，稱為“活動(dòng)窗口/當(dāng)前窗口 active window”。用戶的輸入焦點(diǎn)、鍵控都僅對當(dāng)前活動(dòng)窗口生效。

我們從這種設(shè)計(jì)中可以發(fā)現(xiàn)在窗口物理上有重疊的情況下，系統(tǒng)雖然允許用戶快速切換窗口，但事實(shí)上限制了每次和用戶交互的窗口。

同時(shí)，在桌面端上也允許存在從屬于某個(gè)主彈窗的次級(jí)彈窗。這種“次級(jí)彈窗”更類似于網(wǎng)頁端所講的“模態(tài)彈窗”，如果你不關(guān)閉它就無法與其父級(jí)彈窗交互，所以我把這種彈窗的重疊稱之為“層級(jí)上的重疊”。

雖然“彈窗疊彈窗”這種設(shè)計(jì)形式歷史悠久，但是問題也頗多。其中最明顯的兩個(gè)問題如下：

1. 彈窗層級(jí)過多，不容易找到可交互的活動(dòng)窗口
2. 多層嵌套彈窗的生效模式比較反直覺，并且經(jīng)常在網(wǎng)頁端被錯(cuò)誤應(yīng)用

第一個(gè)問題我相信大部分用過windows的人多少碰見過。windows的次級(jí)窗口（ owned window ）可以隨意拖動(dòng)，位置并不固定，而且部分windows版本中并不展示在底部欄taskbar上，所以有時(shí)并不容易一眼發(fā)現(xiàn)到底應(yīng)該操作哪里。

因此Mac改進(jìn)了它的次級(jí)窗口樣式，使其緊貼父級(jí)窗口的標(biāo)題欄，這樣窗口的從屬關(guān)系比較明確，一眼容易發(fā)現(xiàn)可操作的位置。

類似的問題在網(wǎng)頁端上也比較容易出現(xiàn)。當(dāng)彈窗層級(jí)過多，而當(dāng)前最頂層的模態(tài)彈窗容器又比較小時(shí)，頁面噪音就過多了。

這個(gè)時(shí)候用戶就要費(fèi)好大的勁兒從一堆彈窗中找到最頂層那個(gè)的可交互彈窗，不說交互體驗(yàn)如何，視覺上就不太簡潔，也就丟失了彈窗“引導(dǎo)用戶注意力”的基本價(jià)值。

第二個(gè)問題其實(shí)發(fā)生得很普遍。舉個(gè)例子，假如你現(xiàn)在在做一款人力資源管理系統(tǒng)，現(xiàn)在有一個(gè)“編輯員工角色”的彈窗長成這樣：

前端一看哎呀太好了，我們剛好之前做了一個(gè)“新增角色”彈窗，直接往這個(gè)“編輯員工角色”彈窗上一放就解決問題了，甚至還不打斷用戶的工作流，我看體驗(yàn)非常好：

此時(shí)假如用戶點(diǎn)擊“確認(rèn)新增”，就對輸入的字段進(jìn)行校驗(yàn)，沒問題了那么角色就在后端保存上了。

此時(shí)回到上一級(jí)“編輯員工角色”彈窗，用戶立刻就能在“角色”下拉框中找到自己剛剛新增的角色，但美中不足的是假如用戶在“編輯員工角色”彈窗上點(diǎn)擊“取消”，那只是取消了對員工角色的編輯，角色的新增操作已經(jīng)生效了。好像沒什么問題是吧？

然后我們舉第二個(gè)例子：假如我們作為HR正在新增一群員工，每個(gè)新員工可以有自己的花名和備注，但我們也可以現(xiàn)在不填，等以后再說。新增員工的彈窗長這樣：

假如花名和備注因?yàn)樘顚戭l率不太高，所以被放在了二級(jí)彈窗上，那么：

現(xiàn)在點(diǎn)一下“確定”，前端校驗(yàn)仍然可以做，但員工徐莉莉的花名和員工備注只是在彈窗上暫存，除非用戶在“新增員工”彈窗上點(diǎn)一下“確認(rèn)新增”，否則這批新員工的數(shù)據(jù)都不會(huì)提交后端保存（畢竟員工花名和備注大概率是和員工姓名存在一張表上的選填字段）。

上面兩個(gè)例子講到這里不難發(fā)現(xiàn)，雖然它倆看起來長得一模一樣，但是數(shù)據(jù)的提交方式卻存在差異。當(dāng)出現(xiàn)這種問題時(shí)，就非常難以簡潔地和用戶解釋為什么類似的交互形式造成了截然不同的后果。

一般來講，我們做父子級(jí)彈窗+延遲生效模式時(shí)，（不清楚什么叫延遲生效模式也請看前篇）采用第2個(gè)例子數(shù)據(jù)提交方式，即子級(jí)彈窗的數(shù)據(jù)僅作暫存，當(dāng)父級(jí)彈窗提交時(shí)才一起生效；另外假如存在第1個(gè)例子的情況時(shí)，一般以導(dǎo)航的形式打開新的網(wǎng)頁窗口引導(dǎo)用戶前往“新增角色”模塊進(jìn)行操作，而避免和第2個(gè)例子造成混淆。

但總體而言，應(yīng)該盡量在網(wǎng)頁上避免操作彈窗疊操作彈窗的設(shè)計(jì)方式，并且完全杜絕2級(jí)以上操作彈窗的重疊，因?yàn)榇蟛糠钟脩艉茈y理解這其中的彎彎繞繞。

4. 流程彈窗/多級(jí)彈窗

流程彈窗的歷史和多級(jí)彈窗其實(shí)都是在同一個(gè)彈窗容器上做內(nèi)容的變化，它倆的差異是：

• 流程彈窗有步驟上的順序（上一步、下一步），并且一般與延遲生效模式搭配，在最后一步統(tǒng)一提交信息。
• 多級(jí)彈窗沒有步驟上的順序，且往往與即時(shí)生效模式搭配（盡量避免與延遲生效模式搭配，否則會(huì)存在與彈窗疊彈窗一樣的問題）

不管你用哪一種彈窗類型，注意彈窗只有一個(gè)容器，因此右上角的“X”是對流程/多級(jí)彈窗起全局作用的關(guān)閉按鈕。近年來B端/工具型產(chǎn)品的形態(tài)愈發(fā)復(fù)雜，多級(jí)彈窗也變成了一個(gè)比較常規(guī)的設(shè)計(jì)方式，建議大家花點(diǎn)時(shí)間搞搞清楚。

比如說飛書的【分享】功能，就有這么一個(gè)非模態(tài)的、介于context menu和dialog之間的東西，也符合我們【層級(jí)高于頁面、容器是方形】的彈窗定義。

5. 連續(xù)彈窗

一般不存在多個(gè)不同的操作彈窗銜接在一起，但是因?yàn)榉N種原因，連續(xù)給用戶彈多個(gè)反饋/再確認(rèn)彈窗還是挺常見的。我們在這里就簡短地帶過一下這種情況?？傮w而言，我把連續(xù)彈反饋彈窗分成兩種類型：

把用戶當(dāng)大傻子型：意圖用多重再確認(rèn)來阻止用戶進(jìn)行一件事情（一般是卸載軟件），我們都知道這體驗(yàn)很差，假如用戶體驗(yàn)并不是你的產(chǎn)品主要的考量點(diǎn)，那么當(dāng)我沒說。

絕大部分的場景下，合理設(shè)置再確認(rèn)彈窗能夠避免99%的誤觸，雖然亦有意見表示用戶可能日常關(guān)閉各種彈窗已經(jīng)形成了肌肉記憶，只有一次的再確認(rèn)彈窗可能順手就被關(guān)閉了，可能并沒有起到防錯(cuò)的作用。

所以極少數(shù)誤觸造成問題比較嚴(yán)重的場景下，可以用輸入文字等方式提高再確認(rèn)彈窗的操作成本，但絕大多數(shù)產(chǎn)品的絕大多數(shù)場景只需要1個(gè)常規(guī)的再確認(rèn)彈窗就夠了。

產(chǎn)品各干各的型：當(dāng)一個(gè)模塊有多個(gè)產(chǎn)品經(jīng)理負(fù)責(zé)時(shí)很容易出現(xiàn)這種情況，每個(gè)產(chǎn)品都提出了自己的再確認(rèn)措施，并且各調(diào)各的接口，每個(gè)彈窗的觸發(fā)規(guī)則都有點(diǎn)差別。

那么這種情況就需要交互去協(xié)調(diào)同一個(gè)產(chǎn)品的不同再確認(rèn)彈窗彈出邏輯，盡量把這些彈窗的重點(diǎn)信息整合在一個(gè)彈窗上，并且優(yōu)先展示阻斷性的問題，建議、不那么急迫的事情優(yōu)先級(jí)適當(dāng)往后調(diào)。

到這里彈窗篇徹底寫完了，非常感謝大家的支持。

本文由 @白話說交互 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自unsplash，基于 CC0 協(xié)議