這幾天在工作中處理了一個歷史遺留問題：彈窗適配，幾經折騰終於落定發包。於是我也趁著這個機會把彈窗體系梳理研究了一遍。
我們常見的彈窗有對話框，提示框，有時候在需求溝通中經常會聽到產品同學說，給這裡加個彈窗，那裡加個提示框吧。實際上，這個彈窗到底該不該加？這個彈窗承載的是提示說明文字內容，還是需要引導用戶下一步操作？接下來我們從彈窗的屬性來聊聊我們的彈窗到底在什麼時候加比較合適？用什麼形態展示體驗會更好？
彈窗體系：模態與非模態
彈框體系總結：模態彈框和非模態彈框
王M爭：彈框是一種重要的交互方式，主要用於完成信息傳遞和用戶反饋兩大功能。彈框很常見，但並不見得每一個設計師都可以100%的弄明白彈框這個概念。這篇文章是對彈框體系的一個簡單...
閱讀文章 >>
模態彈窗：是指在用戶任務中，終止了用戶的上一步行為。也就是說，這個模態彈窗必須要用戶操作才可以進行下一步動作。所以在產品設計中，我們通常會用模態彈窗引導用戶去做我們要他做的操作。
常見的模態彈窗有這幾種：對話框、動作欄、浮層。
對話框：對話框主要是給用戶提供選項、相關的操作。另外，在一些對話框中，也可以展現圖片、頭像、步驟圖、其它輸入項等。
動作欄：常見的動作欄一般會出現屏幕下方，比如選擇某個內容時候，出現的選擇。
浮層：彈出窗口，浮動於頂層窗口，氣泡。
非模態彈窗：是指不強制用戶操作，他的作用相當於內容信息提示，他的出現不打擾用戶的當前操作，並且有時間限制，在一定時間裡能自動消失。比如「xxx 功能已更新哦」，這種提示是不需要用戶點擊操作，讓用戶看到就可以了。
常見的非模態彈窗有這幾種：toast/hud、snackbar、notice（通知）
toast/hud：iOS 用戶更習慣於在中間感知反饋信息，通常在信息提示完 3 秒左右後會消失，安卓通常會出現在屏幕頂部或者下部，不會遮擋主體內容。需要注意的是 toast 只有文字，hud 是可以帶有圖標的。
snackbar；可以理解為加強版的 Toast
notice：系統消息、通知推送，也是不干擾用戶行為，有消失時間，是非模態的彈窗。
什麼場景下使用什麼彈框
瞭解完彈窗體系後，我們就可以針對具體場景來看產品同學說加個彈窗到底合適不合適？我們可以從下面的幾個使用場景來看用什麼樣的彈窗合適。
1. 重要打斷用戶操作
在一些重要操作，避免用戶操作失誤。不過目前很多人都覺得這類彈框有利有弊，有的地方出現得不合時宜，打斷了用戶的使用狀態。所以在設計這類彈框時要非常謹慎，得通過多研究確認是否有必要出現。
對話框相對來說比動作欄更重要，因為在視覺中心，更能強烈引起用戶的重視，對於十分重要的內容需要打斷用戶上一步任務的，採用對話框的彈窗，對於不是特別重要信息露出又需要終止用戶上一步動作的情況下，一般採用動作欄彈框。
2. 定製化廣告彈窗
如功能更新、升級、優惠券彈窗。這一類一般是強制用戶看到的，要展示出與眾不同的特色，在視覺上比較突出，會使用模態的彈窗浮層形式。
3. 給予一定提示
比如提示用戶狀態、信息、反饋，確保用戶知曉自己所處的狀態，並可以做出相應的措施。一般使用非模態的彈窗。
4. 用戶操作反饋
出現在用戶操作完之後的反饋，比如提醒用戶頁面正在加載中、保存成功、已刪除、已刷新等等。
可以不用彈窗的反饋例子：完成頁
比如已支付成功、下載完畢、簽到成功，這一類是告訴你上個動作結束了，下一步不需要進行引導了，這種反饋大多數都不採用彈窗形式展現了。
需要注意事項
1. 層級關係
彈框是內容和導航的補充，用於通知、操作菜單、成功或加載狀態的 toast，他是寫在蒙層上面的一層內容。
2. 適配方式
下面我們需要了解的是這幾種彈窗在開發那的實現形式。我們可以理解為 2 種形式：
一種是開發直接用系統的接口，缺點是具有不可定製，形式美觀度不夠好。
另一種是開發用代碼會單獨寫出一個模態彈框系統，這套系統與整體設計語言具有一致性，可以複用在各個任務中，可以定製化設計。
需要注意的是，代碼寫出來的模態樣式要考慮在不同機型的適配情況，考慮不同機型的邊界。這個適配也有兩種實現形式，一種是固定寬高尺寸，展示在不同機型尺寸中，另一種是常用的等比例縮放。這個就需要開發與設計進行密切的溝通，能儘量合理地在不同機型展現更加合適，避免出現極限的情況。
我們是這樣操作的，為了避免尺寸比例混亂的情況，會設計一個彈窗的寬高尺寸範圍，開發同學代碼寫出的這套彈窗的適配在各個機型中，是在一定縮放比例下，適用各個不同情況下的視覺展示。這套彈窗可以調用在首頁引導、升級等各個頁面的彈窗設計中。
