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

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

初識彈窗

想象一下你去一家意大利餐館吃晚飯，正餐剛端上來你正吃的高興呢，一個(gè)服務(wù)生空著手走到你旁邊戳戳你：“這位客人，外面有個(gè)人叫你，你站起來跟我過去一下?！蹦悴坏貌唬ê懿磺樵傅兀和３燥?，站起來跟他走了。

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

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

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

什么是彈窗？

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

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

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

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

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

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

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

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

為什么彈窗？

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

氣不氣人？

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

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

觸達(dá)彈窗：這個(gè)彈窗是由系統(tǒng)觸發(fā)的，而非用戶主動觸發(fā)的，一般用作信息通知，可能附帶簡單操作

信息展示彈窗：用戶主動觸發(fā)，一般用來收納全頁面上放不下的信息詳情

操作彈窗：用戶主動觸發(fā)或受用戶的操作觸發(fā)，可能用來承載復(fù)雜操作（比如表單）

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

是否急迫：假如這是一個(gè)觸達(dá)彈窗，用戶是否需要馬上處理/查看彈窗上的內(nèi)容/任務(wù)？

具體情境：假如這是一個(gè)操作或信息展示型彈窗，用戶在處理這個(gè)內(nèi)容/任務(wù)時(shí)，是否需要對照或查看其他內(nèi)容？這個(gè)內(nèi)容/任務(wù)是否反復(fù)發(fā)生/需要反復(fù)處理？

生效方式：假如這是一個(gè)操作彈窗，用戶是否需要對照自己處理的結(jié)果，再次對內(nèi)容進(jìn)行調(diào)整？

1. 是否急迫

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

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

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

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

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

2. 具體情境

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

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

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

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

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

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

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

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

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

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

3. 生效方式

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

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

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

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

歡迎關(guān)注作者微信公眾號：「白話說交互」