彈窗的類型有非常多種，所以在使用時很容易被濫用，這樣不僅會對用戶帶來困擾，也會讓我們的設計中出現細枝末節的問題。本篇文章分析和總結了不同彈窗的使用場景及工作中的實際應用，知道這些後，以後再也不會「濫用」彈窗啦！
我們口中常說的彈窗其實是個廣義的範圍，包括了對話框，動作菜單，浮出層，toast，snackbar等，這麼多類型的彈窗在使用中很容易混亂或者說濫用，反而得不償失，給用戶帶來更多困擾。故本篇文章主要分析和總結不同彈窗的使用場景及工作中的實際應用。
官方的設計樣式會提到，但是細節不展開，有需要的可以參閱MD官方文檔和蘋果HIG官方文檔，文檔裡介紹的都很細緻。
除了官方文檔，本文還參閱了很多前輩的總結分析，參考連結已置於文末。（配圖主要來自體驗過程中的app截圖，安卓部分截圖主要來自MD規範）
在App使用中，彈窗出現的頻率越來越高，運營活動，系統通知，信息反饋，任務引導等。濫用的彈窗會漸漸導致用戶認知疲勞和視覺失調，甚至會出現「習慣性取消」等行為。
彈窗最主要的功能就是服務於當前主任務之外的支線任務，包括信息傳遞，操作反饋等。
對話框，警告框，toast……都屬於彈窗，但是使用場景都不一樣。
在合適的業務場景選擇合適的彈窗組件，能夠保證最基礎的用戶體驗。因為像強幹擾類彈窗的使用，對用戶而言，更是一種強加的任務，很容易導致用戶喪失耐心而流失。
彈窗可以按照是否強制打斷用戶操作來分成兩種，模態彈窗和非模態彈窗（也可以叫做阻斷式彈窗和非阻斷式彈窗）。
模態彈窗：模態提供了一個專注聚焦的環境，用戶只有完成或者關閉當前任務，才能進行其他任務。
特點：打斷用戶當前的操作流程，屬於強勢的幹擾行為，故運用彈窗需要慎重考慮。
常用組件：dialog（對話框）/alert(警告框)、popover（浮出層）、action sheet（動作菜單）、activity views（活動視圖）、modal bottom sheet（模態底部菜單）。
非模態彈窗：常用於輕量級的操作反饋和信息傳遞，不需要獲取屏幕焦點，用戶可以同時操作屏幕中的其他內容。
特點：屬於輕量級的反饋，不會對用戶流程產生幹擾，但同時又給了用戶反饋和信息。
常用組件：Toast（吐司），snackbar，Hud（透明指示層）。
dialog和alert分別是MD和ios的官方彈出框，是最常見的彈窗，兩者功能一樣，在使用上以及樣式上略有區別（下文分析統一稱為彈出框）。
彈出框通常用來傳達和app及設備相關的重要信息，並且要求用戶操作或反饋，且其出現在屏幕中央，對內容遮擋嚴重，會中斷用戶正常操作。用戶只有完成或者關閉當前任務，才能進行其他任務。
其官方樣式如下：
4.1.1 使用場景
通知用戶app或設備相關的問題：
通過強幹擾通知用戶設備相關問題如備份，低電量等問題；這些潛在問題可能會對用戶造成一定負面的影響。
再比如app的版本更新，消息通知，首飾引導等都關係到用戶的利益，所以也會用強幹擾的方式讓用戶明確知道並選擇。
輔助用戶完成任務，如系統權限：
用戶在進行任務的過程中，受到阻攔，必須通過其他輔助操作幫助他完成任務。
如完成一些任務必須要開啟相應的系統權限：上傳照片要開啟相冊權限；拍小視頻要麥克風權限；出行外賣等產品要開啟定位權限；新建相冊必須要為相冊命名；下載app要登錄itunes帳號。
用戶主動中斷任務，破壞性操作等：
用戶中斷當前任務，對之前的操作有一定的影響，或者一些無法挽回的破壞性操作，故需強幹擾的彈窗通知，避免用戶因為失誤有了不可挽回的損失。如退出帳號；刪除訂單，活動消息等；放棄編輯。
操作反饋：
當操作後的反饋比較重要，會影響用戶接下來的操作或會影響當下的任務，那就需要用強幹擾讓用戶明確知道，要完成此操作需要什麼，或者接下來會發生什麼。
例如西瓜視頻的結算通過強幹擾通知到用戶想要結算應該怎麼做。
運營活動：
現在用彈出框來傳遞運營活動已經成為一個約定俗成的用法了，雖然ios規範中建議儘量少用彈出框，但公司還是要盈利的，所以基本上所有app都會以這種強幹擾的形式來通知用戶「這裡有優惠活動」等運營活動。
這種場景下，彈出框會根據產品以及業務的運營需求及產品的調性做豐富的運營設計，來吸引用戶參加運營活動，需要注意的一點，需要用戶參加的buttom一定要加強，突出。
功能引導：
功能引導和運營活動一樣，是產品出於業務角度考慮，用強幹擾的方式吸引用戶使用某功能，達到一定的業務目標，如用戶活躍度。
例如完成訂單後（外賣或商品）引導用戶評價，並給予一定獎勵。如將流量引流到新業務，從而達到新業務推廣目的。
浮出層是ios的組件，是用戶點擊屏幕上的某個控制項或區域出現在屏幕上方的臨時視圖，它最典型的是包含一個指向它出現位置的箭頭，且浮出層一般在入口下方，整個浮出層應該位於整個屏幕的中上方。
浮出層最開始主要用於大屏幕的ipad，但由於手機屏幕越來越大，目前也被較多地運用到手機界面中。
4.2.1 使用場景
多個常用操作的快捷入口：
多個常用操作通過popover摺疊起來，視覺上更清爽簡潔，同時使用起來也方便，缺點是用戶不能直觀看到，需要一定的學習才能掌握，所以適合於有學習能力用戶群的產品
呈現頁面中一些摺疊的信息：
屬於浮出層的衍生應用，和上個場景一樣，節約屏幕空間，顯露出一部分，並將剩餘信息摺疊起來，不影響用戶理解功能，又解決了屏幕空間，若用戶有需求，即可展開探索更多的信息，同樣也會用箭頭等指向出處
對於新用戶的功能引導或者新功能的引導：
此類場景也屬於浮出層的衍生應用，主要通過帶指向箭頭的浮層引導用戶學習某個功能，一般需要學習的功能是高亮的，且箭頭指向它。
actionsheet是ios系統中特定的警告框，用來響應動作或控制項，或者呈現和當前內容相關的兩個及更多的選項。一般在屏幕底部。官方不建議在動作菜單中應用滾動條，所以動作菜單中的選項不能過多。
4.3.1 使用場景
當前對象的多個操作或者完成任務的多個選擇：
對當前對象的的多個操作，如qq中對圖片長按，出現多個對該圖片可進行的操作，幫助完成任務。除了文字列表外，還可以用圖標+宮格式的展示方式，例如分享功能的多個選項。
執行潛在的破壞性操作前的二次確認：
當執行潛在的破壞性操作前需再做提醒，避免產生不可挽回的失誤。需注意的是破壞性操作的按鈕需重點突出，一般用紅色，起到警示，危險的提醒作用
和alert的區別：
alert主要適用於兩個選項，而actionsheet可以有多個功能選項，且展示形式更多樣。前文講過，alert也有破壞性操作提醒的場景使用。
兩者相比，alert出現在屏幕中央，actionsheet出現在屏幕底部。視覺角度上alert相較於actionsheet更有阻斷感，對用戶而言幹擾性更大。
另一方面底部的actionsheet從手勢操作的角度上來看，操作更方便，更容易對此作出選擇或關閉。所以alert更加適用於嚴重後果的破壞性操作提醒。
活動視圖是ios組件，是針對當前頁面提供的一系列任務和服務，例如複製，收藏，查找等。系統提供了許多內置活動，包括列印，信息和AirPlay。
這些任務始終首先出現在活動視圖中，無法重新排序。無需創建執行這些內置任務的自定義活動。活動視圖還顯示來自其他應用的共享和操作擴展。
Bottom sheet是MD的組件，MD中底部菜單有兩種，一種是Standard bottom sheet（標準底部菜單），另一種是Modal bottom sheet（模態底部菜單）。
MD的模態底部菜單和iOS的action sheet類似，它阻止用戶與屏幕其他地方交互，通過聚焦的底部菜單提供了更多的選項和功能。它可以是內聯菜單和簡單對話框的替代方案，為內容，圖標和動作提供了額外的空間。
規範建議，模態底部淡淡的初始垂直位置的上限為屏幕高度的50％。內容超過屏幕高度50％的模態菜單可以在整個屏幕上拉動，在內部滾動以訪問其餘項目。同樣他的展現方式有列表式，也可有宮格式
snackbar是android專有控制項，是出現在屏幕底部的提供有關app相關的簡簡訊息提醒，它屬於輕量級的信息提醒，一般出現幾秒後就會自動消失，不會中斷用戶操作。
snackbar往往由一條文案+一個引導性按鈕（可選，按鈕可以引導用戶進一步操作）組成，帶有一定的交互性。因為它自動會消失，所以它一定沒有取消或者不要等否定性按鈕。
4.6.1 使用場景
傳達輕量級的信息和操作反饋，可以引導用戶操作：
傳達輕量級的信息或反饋，並且可以引導用戶進行下一步行為，但並不強制用戶操作。比如chrome添加書籤時，可以進一步對新加的書籤進行編輯；刪除書籤時防止用戶後悔，提供一個撤銷按鈕。
Toast是android專有的控制項，原先的MD規範中，toast是和snackbar放在一起講的，翻閱了最新的MD規範，snackbar裡找不到關於toast的相關介紹（有小夥伴找到的望提醒一下）。
Toast應該包含在snackbar裡了，當snackbar沒有按鈕其實就是toast了，不過這邊還是把Toast單獨拿出來分析
4.7.1 使用場景
傳達輕量級的信息和操作反饋，且不需要用戶操作：
適用於通知用戶不重要的信息和操作反饋，且不會對用戶當前的任務有影響，因為不能交互，且幾秒後消失，所以用戶很可能忽略，所以該類信息相對而言沒那麼重要。
雖然toast是android專有樣式，但現在很多ios版本的系統中都使用了改良版的「toast」，因為輕反饋，不打斷用戶操作，同時又能通知信息和操作反饋，對用戶而言及其友好，但是不易傳達過多的文字，因為用戶很有可能會忽略。
ios文檔中的feedback中有建議：反饋可以幫助人們了解應用正在做什麼，發現他們下一步可以做什麼，並了解行動的結果。所以實際應用中，既要不打擾用戶，又要能引起用戶注意，還要和產品設計相協調。
比如結合了文字和icon的樣式，再比如用較為突出的背景色，位置的話在中央，頂部，底部，都會出現，會根據具體的業務來選擇合適的位置。一般出現的位置會和操作內容在一起，這樣用戶才能清晰有效地得到即時反饋。
下方例舉的toast案例因為選用了比內容更為突出的背景色，相比較上方案例的toast更易被用戶發現和察覺，達到通知用戶的目的。
Hud透明指示層，ios專用控制項，典型的就是音量調節的彈窗樣式。部分改良的toast，在樣式上有借鑑學習Hud。
Dialog/Alert：
當信息或操作非常重要，並且必須要由用戶做決定或者操作才能繼續，一般用alert，更適用於用戶判斷選擇。
Modal bottom sheet/Action sheet：
稍弱於dialog/alert，更著重於提供更多的功能和選項時使用。
Activity view：
是針對當前頁面提供的一系列額外的任務和服務。
Popover：
使用更側重於指向性，更適用於信息或功能摺疊。
Toast：
不太重要的信息提醒和操作反饋，更適用於不需用戶響應或反饋的場景。
snackbar：
不太重要的信息提醒和操作反饋，可以交互，但並不強制，更適用於可以引導用戶進行下一步或者一些撤銷上一步的場景。
Hud：
音量調節。
了解了每個彈窗組件的用法，下次就可以根據實際業務設計合適的彈窗了，不過官方規範或者文章的建議也都只是參考，實際工作中還是要靈活變通，設計的目標是幫助用戶更好更快的解決問題。
以上就是我對彈窗相關知識的總結，總結的過程中也對官方規範彈窗部分的內容再次熟悉了好幾遍，因為看的英文，所以理解上可能稍微有些不足，有不對的地方，還希望大家批評指正。（推薦大家多看看官方設計規範，就像一本非常實用的設計工具書，對於實際工作還是非常有幫助的）
再次感謝前輩的經驗分享！
MD官方規範 https://material.io/
HIG規範 https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/
互動設計之（二）彈窗設計 https://www.zcool.com.cn/article/ZNjE0MjIw.html
https://www.zhihu.com/question/38063549/answer/235584402
這個控制項叫什麼系列之toast的曾經，現在，與未來 https://www.uisdc.com/ui-element-toast
如何設計App中的提示控制項（toast） https://zhuanlan.zhihu.com/p/22405748
iOS和Android規範解析——底部浮層（上）https://www.jianshu.com/p/8bdfbc0a9339
iOS和Android規範解析——提示框（Toast）對比 https://www.jianshu.com/p/e1beeacbea32
不要濫用對話框！細說 iOS Alert View 與 Action Sheet https://zhuanlan.zhihu.com/p/20189186
App設計中，6組常見組件的區別和用法 http://www.woshipm.com/pd/873075.html
重新複習 Toast 和 Snackbar https://zhuanlan.zhihu.com/p/26386661
APP提示框架詳解：Toast提示、Snackers和Alert http://www.woshipm.com/pmd/296674.html
本文由 @麥子_Maizi 原創發布於人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基於CC0協議