彈窗是我們平時在設計APP時候繞不開的一個元素，選擇合適的彈窗形式，是我們需要多加思考的地方，避免變成只會完善產品原型的線框美工。

彈窗是我們與機器界面進行互動的一扇窗，它是一種用戶與產品直接對話的方式，它可以傳達信息，反饋狀態以及引導用戶操作。彈窗分為兩種類型：模態彈窗與非模態彈窗(有些地方可能翻譯為無模式窗口)。

模態彈窗

用戶需要先與其進行交互，才能繼續操作。也就是說它是強制性的，用戶無法忽視它的存在。確保人們收到關鍵信息，并在必要時采取心動。

非模態彈窗

存在一定的時間限制，通常用于系統反饋，用戶無需對其進行回應。

模態彈窗

1. 對話框 Dialog / 警告框 Alerts

出現在需要打斷用戶操作的情況下，可以大致分為信息下發(被動)例如：版本更新，消息通知，運營廣告等。信息提交(主動)，例如：修改信息，登錄注冊等。

通過上面幾個案例我們還能發現幾個特點，按鈕可以通過差異化設計引導用戶去點擊(例如美團的版本更新)，運營類彈窗一般更注重視覺沖擊力，且刻意將關閉按鈕弱化遠離彈窗主體，背景蒙版顏色更深一點，營造更強的沉浸感。對于承載輸入功能的彈窗，需要注意鍵盤彈出后的位置。類似系統功能的彈窗，比如清理緩存可以考慮直接調用平臺的系統彈窗。

2. 浮層 Popover / Popup

通常在用戶進行交互后出現，比如常見的下拉菜單，下拉彈窗等，更加強調彈窗的從屬關系。(在騰訊ISUX騰訊文檔的文章中使用了模態浮層與非模態浮層的概念，有興趣可以去看看)。

同樣都是下拉彈窗，但是很多產品有著不同的處理方式，微博通過暗色系彈窗來明確區分彈窗內容與背景內容，釘釘通過加深背景蒙版來突出彈窗內容，大眾點評只使用了淡淡的投影，去掉了背景蒙版，使得彈窗內容與背景內容對比無法拉開，在實際體驗中相當影響用戶的識別效率。

3. 操作欄 Action bar / 操作列表 Action Sheets / 操作視圖 Activity Views

跟浮層有點類似，也是通過用戶的主動交互后喚出的功能菜單。通常出現在屏幕下方，占用屏幕比例較高，為了方便用戶使用，底部會放置取消功能。(Action Sheets和Activity Views是IOS官網規范中的叫法。)

這種類型的彈窗最常見的場景就是分享模塊，比起其他的模態彈窗，它能夠承載更多更豐富的功能(多為選擇項功能)。支付寶和微信公眾號分享算是最標準的Action Sheets，為了減少用戶不必要的記憶負擔，彈窗高度限制較低，露出更多的背景內容協助用戶記憶。

4. 卡片 Sheet

Sheet是出現在IOS人機交互指南中的一種模態窗口，形式為一張從底圖出現的卡片，幾乎覆蓋了全部的原頁面。但是未覆蓋的區域也會使用暗色蒙版來幫助用戶記憶暫停的任務。因為它支持上下拖動，所以比起浮層，它能夠承載更多的復雜信息內容，常用于一些表格無法承載的復雜任務但又非沉浸式的情況下。

比起Action Sheets，Sheet的屏幕覆蓋率更高，且更多時候承載的是信息錄入型功能。Sheet需要頂部標題告知用戶當前所處步驟信息，通過底部卡片形式的疊加讓用戶感知當前處理的任務流程為主流程的分支任務。

5. 其他補充

隨著交互體驗與產品技術的不斷發展，如今的設備都能承載越來越多復雜精細化的模塊。所以漸漸有越來越多特殊的彈窗形式。(底層邏輯是互通的)

例如網易云音樂的分享使用了沉浸式模態，多個彈窗組合的形式，還有動效引導，以此來承載自身豐富的分享形式。IOS桌面使用聚焦類型的彈窗菜單，幫助用戶進行視覺聚焦。

非模態彈窗

1. 提示框 Toast

常見用于反饋用戶的操作結果，反饋應用的狀態改變，一般持續2s左右便自動消失，可能出現在任何位置。(不能通過主動滑動關閉)

目前最常見的場景就是各種刷新反饋信息，一般來說存在感都比較弱，比如案例中的知乎，B站和ins。比起B站和ins，微博和知乎都在其中融入了自己的品牌特征：主題色點綴，雖然只是個小細節，但是對用戶的品牌感知能起到潛移默化的作用。

2. 提示對話框 Snackbar

Snackbar最早是出現在Android的一種彈窗形式，不過現在很多IOS端產品上也會出現。它有點類似Dialog和Toast的衍生，很多時候像Dialog一樣可交互，有時候又像Toast一樣有時間限制。通常出現在屏幕底部，由頁面底部向上滑動出現，向下滑動消失。

由于目前手頭木有Android手機，所以截了Material Design的官方說明案例來幫助理解。主要強調了兩個點：1.不要加Icon，2.只能有一個操作項;因為snackbar及時不操作也會消失，所以比較常見運用與工具類產品，需要保持操作的連貫性。例如郵箱類產品，用戶刪除了郵件，snackbar可以及時反饋刪除成功的狀態的同時提供撤銷的操作。

3. 透明指示層 HUD

HUD是出現在IOS端常用的一種非模態類型，最早出現在屏幕中間，由于容易影響用戶的沉浸式體驗，所以在IOS13版本中對HUD進行了邊緣化調整。

對比左側與右側的HUD就會體會到為什么早期會被那么多人吐槽，特別是在游戲類的沉浸式應用中，很容易破壞用戶的體驗。

彈窗設計時需要關注

1. 展現形式

展現形式核心是分場景，一些偏向系統報錯考慮使用最簡單系統的彈窗展現形式，運營廣告之類的可以通過特殊的設計手法來吸引用戶。但是不管怎么做，一定要讓用戶懂得，這是一個彈窗。非模態彈窗一般多以最簡單的形式出現，避免傳遞狀態信息時干擾用戶的關鍵信息獲取。

2. 按鈕模態彈窗一般情況下只放置1-2個按鈕，信息告知類型的放個“確定”，重大決策類型的放個“確定”“取消”。比較特別的是權限請求彈窗，可能會有多個按鈕。現在很多運營廣告為了曝光率會將關閉按鈕放在邊邊上，對于用戶體驗上來說相當的不友好，但是對于運營數據上來說可能會很好看。

3. 動效因為彈窗承載文本量有限，得利于設備技術的發展，現在越來越多的產品會在模態彈窗中使用動態的形式傳遞信息，例如很多產品的功能引導。對于非模態彈窗來說，由于本身存在感較弱，動效運用于合理順應用戶的視覺動線，例如你下拉刷新后，一般刷新反饋彈窗都是出現在用戶當前的視覺聚焦點。

4. 時機頻率把握好彈窗出現的時機和頻率

模態彈窗會直接打斷用戶的操作狀態，一般只有在不可逆，或者操作會造成嚴重后果的情況下出現。但是在一些特殊的商業需求下，比如運營廣告，那就得權衡用戶與商業利益之間的關系了。非模態彈窗的話更注重出現的時機，反饋一定要足夠及時，這樣才能不會讓用戶在操作中產生疑慮。

5. 文案表述

由于彈窗的信息承載量非常小，所以一定要用最精煉，恰當的表述來告知用戶信息或者當前狀態，可以考慮使用“動詞+名詞”的組合短語，例如“刪除照片”“取消訂單”等等。特別是非模態彈窗那種會自動消失的，文案字數要更加注意(可以考慮增加一些通用icon顏色輔助表達，比如正確使用綠色打勾)。

6. 輸入內容

很多彈窗承載著表單輸入的任務，然而彈窗并不適合過多的表單輸入，特別還有一些多到需要下拉了- -如果需要用戶填寫很多表單，乖乖跳轉新頁面吧。況且彈窗本身出現就已經中斷了用戶原有的操作，還要填一大堆東西的話。。(除了IOS的Sheet，它的出現就是IOS官方為了解決常用于一些表格無法承載的復雜任務但又非沉浸式的情況。)

寫在最后

由于目前手頭目前沒有Android，所以截圖案例都是基于IOS端，下次有機會繼續修改更新。不過目前來說兩端很多交互形式越來越趨向共通。

借由這篇文章開了“設計控件”系列的坑，接下來會繼續學習與分享其他的設計控件相關知識。包括之前的設計原則系列，也會繼續分享設計心理學法則等等。最近一直在思考自己的學習框架，除了設計基礎原則，設計控件外，還有設計模型以及設計工具等等。坑已挖好，接下來就靠自己一鏟子一鏟子去填了。