編輯導(dǎo)讀：彈窗是吸引注意力的一種方式，不管是PC端還是移動端都廣泛使用。本文作者從交互設(shè)計的角度，對彈窗進行分析，與你分享。

過去幾周我們都在講一些非常玄學(xué)的設(shè)計理論相關(guān)內(nèi)容，這周換一下口味，我們繼續(xù)來講基礎(chǔ)控件。

不知道大家對交互設(shè)計中的控件持一個什么樣的態(tài)度，反正我自己入行的時候其實是挺“怕”這玩意的。這些東西好像都來頭不小，讓我一個不小心就犯很多體驗錯誤。但現(xiàn)在來看這樣的心態(tài)其實很不必要，因為盡管控件設(shè)計有很多約定俗成的規(guī)則，但嚴(yán)格來說控件的應(yīng)用不該講“對”和“錯”，只講一致性與更好地貼合場景。面對控件時態(tài)度放松一點，也能讓人更好地去思考未來改進的可能性。

另外，由于市面上已經(jīng)存在很多比較基礎(chǔ)的、移動端場景下或者UI角度的彈窗文章，所以這一篇我將著重講一講PC端那種特復(fù)雜的大彈窗怎么做，內(nèi)容比較多，所以會分兩期。

一、初識彈窗

想象一下你去一家意大利餐館吃晚飯，正餐剛端上來你正吃的高興呢，一個服務(wù)生空著手走到你旁邊戳戳你：“這位客人，外面有個人叫你，你站起來跟我過去一下。”你不得不（很不情愿地）暫停吃飯，站起來跟他走了。

——同一個吃晚飯的場景，假如這次服務(wù)生端著托盤走了過來，你一抬頭，他“啪”一下把托盤上的罩子打開，盤子上放著一個小紙條，并且示意你拿起來看看。

在交互設(shè)計中，假如把全頁面的跳轉(zhuǎn)類比成那個叫你“站起來跟我走”的服務(wù)生，彈窗就是那個端著托盤的服務(wù)生。他用一個新的任務(wù)或信息（托盤里的紙條），打斷了用戶原本的任務(wù)（吃飯），但是并沒有把用戶從桌子上拽起來，完全離開當(dāng)前場景——也就是飯桌。

因此可以這么說：網(wǎng)頁與移動端設(shè)計中，彈窗本質(zhì)上是一種對用戶注意力的引導(dǎo)形式。它弱于全頁面跳轉(zhuǎn)、可能具有打斷性，要求用戶從原來的場景中抽出一部分精力來應(yīng)對它。

二、什么是彈窗？

既然彈窗是引導(dǎo)注意力的一種形式，那是不是所有引導(dǎo)注意力的控件，都能叫彈窗呢？

在PC應(yīng)用程序設(shè)計的時代，所有的任務(wù)都是在窗體或者窗口 （window）上面完成的。因此實際上不存在所謂“全頁面”和“彈窗”的差異，只有“這種窗口”和“那種窗口”的差異。比如在我的這篇文章里出現(xiàn)過的兩種“彈窗”，在windows 7中同屬于dialog box類；而除了這種窗口（彈窗），當(dāng)時還定義了wizard、property sheet等多種不同的窗口樣式。每種窗口都有一個主要的解決問題與標(biāo)準(zhǔn)樣式。

PC設(shè)計從應(yīng)用程序進入網(wǎng)頁時代后，用戶不再在多個窗口之間跳來跳去，而是在一個網(wǎng)頁窗口下完成任務(wù)。因此在網(wǎng)頁狀態(tài)下，設(shè)計師模仿繼承了“窗口”的樣式與交互形式，產(chǎn)生了我們熟悉的“彈窗”。

隨著網(wǎng)頁/移動端設(shè)計的不斷發(fā)展，我們也發(fā)現(xiàn)，其實不用完全依照應(yīng)用程序設(shè)計窗口的那一套來做彈窗或者做觸達，因此網(wǎng)頁/移動端產(chǎn)生了很多獨有的設(shè)計樣式。這些樣式雖然起源于窗口，但更靈活多變、和傳統(tǒng)意義上的“窗口”有一些差異。

由于中文表達的含糊和不清晰，現(xiàn)在國內(nèi)設(shè)計界傾向于把這些形形色色的觸達/操作形式全部都統(tǒng)稱為“彈窗”，但細(xì)究起來，我們甚至可以畫一張九宮格：

△你是彈窗原教旨主義者嗎？

我在這里無意于給“彈窗”這個概念正本清源，但為了下文能夠更有指向性，我們這里只把“層級高于頁面的”、“容器大概是個方形”的控件納入接下來“彈窗”的概念范圍。并且由于callout/tooltip的一些變體和menu菜單不太好區(qū)分，為了方便，這期就不講這些比較小的非模態(tài)控件了。

同時我也認(rèn)為，大家日常工作中特別是做控件的時候，可以去思考一下控件的具體定義，以防溝通起來雞同鴨講。

三、為什么彈窗？

還是承接上文那個吃飯場景，那個端著托盤的服務(wù)走后，你急急忙忙放下刀叉，把字條從托盤里拿出來：展開一看發(fā)現(xiàn)上面寫的是——

△氣不氣人？

你可能當(dāng)場就想跳起來大罵服務(wù)生：這點事情需要這時候來打擾我嗎？

同樣的道理，既然彈窗只是一種形式，那么是否選擇這種形式，必然是由其實質(zhì)內(nèi)容（也就是場景與任務(wù)）決定的。我基于我自己的經(jīng)驗把彈窗的作用分成三種（當(dāng)然你也可以分得更細(xì)，比如IBM就把他們的彈窗組件分成5種）：

• 觸達彈窗：這個彈窗是由系統(tǒng)觸發(fā)的，而非用戶主動觸發(fā)的，一般用作信息通知，可能附帶簡單操作
• 信息展示彈窗：用戶主動觸發(fā)，一般用來收納全頁面上放不下的信息詳情
• 操作彈窗：用戶主動觸發(fā)或受用戶的操作觸發(fā)，可能用來承載復(fù)雜操作（比如表單）

在決定要設(shè)計一個彈窗時，至少要思考三個關(guān)于彈窗內(nèi)容的問題：

• 是否急迫：假如這是一個觸達彈窗，用戶是否需要馬上處理/查看彈窗上的內(nèi)容/任務(wù)？
• 具體情境：假如這是一個操作或信息展示型彈窗，用戶在處理這個內(nèi)容/任務(wù)時，是否需要對照或查看其他內(nèi)容？這個內(nèi)容/任務(wù)是否反復(fù)發(fā)生/需要反復(fù)處理？
• 生效方式：假如這是一個操作彈窗，用戶是否需要對照自己處理的結(jié)果，再次對內(nèi)容進行調(diào)整？

1. 是否急迫

這個問題決定了你需要占用多少用戶注意力，是否要選擇“彈窗”作為你的觸達方式。

就像我們上面提到的，觸達彈窗不是由用戶自己觸發(fā)的，因此這個彈窗肯定不在用戶預(yù)期之內(nèi)，這意味著用戶有很大可能性不會去看這個彈窗。

對于觸達彈窗來說，假如這件事情不那么急迫，不需要用戶馬上進行處理、或者用戶根本處理不了，那么你可以考慮用以下方式弱化、降級觸達：

• 降低視覺音量：模態(tài)彈窗變成非模態(tài)彈窗，或者設(shè)置彈窗消失時間
• 主動觸達降級為被動展示：將觸達彈窗變成用戶主動點擊查看

由于觸達本身是個很大的話題，我們這里不做贅述。未來講觸達的時候再細(xì)講。

2. 具體情境

對于操作或信息展示彈窗來說，這個問題決定我們選擇組件的層級、以及是否需要阻斷用戶和頁面其他內(nèi)容的交互（也就是模態(tài)/非模態(tài)）。

想象這么一個場景：假如你是一個中學(xué)老師，你正在給每個小朋友寫期末評語。學(xué)校提供的寫評語系統(tǒng)長這樣：

你發(fā)愁了：班上有50個孩子，每個人的期末評語得按照他們的平時表現(xiàn)和期末成績來寫。為了寫這個評語，你得打開期末成績excel、打開學(xué)生檔案，再打開百度搜索評語模板，一邊復(fù)制、一邊粘貼：

再來一個場景：假如你是一個第一天上崗的客服，用戶來找你咨詢：“這件衣服有幾個碼呀？我能穿上嗎？”

你一愣，“等等哦，我給你去查查”，然后打開了商品鏈接一通翻找。等你找到了，關(guān)閉商品頁正準(zhǔn)備回復(fù)呢，這時候客戶也消失了。

這就叫完成任務(wù)時，需要“對照或查看”其他內(nèi)容。這種情況下假如設(shè)計一個模態(tài)彈窗，的確好像起到了“引導(dǎo)注意力、讓用戶專注當(dāng)前任務(wù)”的效果，但也嚴(yán)重影響了用戶完成任務(wù)的能力。對此，我們一般有以下幾種方式來解決：

• 嘗試不用彈窗，而采用側(cè)邊欄來承載信息或任務(wù)
• 使用各種形式的非模態(tài)彈窗，來讓用戶在完成任務(wù)的同時，可以自由行動、甚至允許暫時中斷任務(wù)

比如第二個案例里，我們可以嘗試用側(cè)邊欄承載商品信息，這樣客服就不需要離開當(dāng)前聊天頁面，而可以直接通過側(cè)邊欄獲取商品規(guī)格，直接給到顧客及時的反饋。

而在第一個案例中，也許我們可以嘗試在學(xué)生的單人信息頁上打開側(cè)邊欄，或者做成停駐窗口（docked window）的形式。這樣即使在輸入中，用戶也可以去查閱完成任務(wù)所必要的信息，降低任務(wù)的完成難度。

這個案例之所以我們不使用側(cè)邊欄，而采用了層級高于頁面本身的面板來完成，主要還是考慮到寫“期末評語”這個情景比較偏向長文本輸入、一次性提交后不再支持編輯，所以相對于頁面內(nèi)輸入，面板感覺起來比較“鄭重”。這個就純屬個人習(xí)慣了。

3. 生效方式

這個問題在操作型彈窗非常多見。設(shè)計師用Mac的多，不知道平時打開系統(tǒng)偏好設(shè)置的時候，有沒有注意過不同的菜單，右下角一會有“應(yīng)用”和“復(fù)原”按鈕，一會兒又沒有。

很明顯，這兩種彈窗的生效方式（或者叫生效模式）是不同的。有提交按鈕的彈窗，在你沒有真正點擊“提交”之前，所有的修改都只是暫存，并沒有真正生效。而右邊這種沒有提交按鈕的彈窗，在你與彈窗內(nèi)容區(qū)交互時，就已經(jīng)即時生效了。windows給這兩種模式起了名字：前者叫延遲提交模式delate commit model，后者叫即時提交模式immediate commit model。

我們大部分在網(wǎng)頁端能見到的常規(guī)模態(tài)操作彈窗，都應(yīng)該采用有提交按鈕、需要再次確認(rèn)的延遲提交模式：它的潛臺詞是，你可以仔細(xì)思考一下你鍵入的內(nèi)容、選擇的選項，隨意修改到符合你的想法之后，再提交生效。相比起效率，這種模式更加關(guān)注準(zhǔn)確性，填錯了可能造成一些后果。

但假如你的任務(wù)本身操作量不大，但是變更很頻繁，比起準(zhǔn)確性、更關(guān)注效率，那么就應(yīng)該思考是否可以采用非模態(tài)彈窗或者側(cè)邊欄+即時提交模式，來創(chuàng)造相對高效、輕量的體驗。比如windows edge的這個側(cè)邊欄，雖然也是設(shè)置，但采用了非模態(tài)面板+即時生效。

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

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