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

過去幾周我們都在講一些非常玄學的設計理論相關内容，這周換一下口味，我們繼續來講基礎控件。

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

另外，由于市面上已經存在很多比較基礎的、移動端場景下或者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的這個側邊欄，雖然也是設置，但采用了非模态面闆 即時生效。

本文由 @白話說交互 原創發布于人人都是産品經理，未經許可，禁止轉載。

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部