交互實戰｜覆蓋層設計(上)：對話框&浮層

來源：妖鹿山設計屯（微信公眾號）

什么是覆蓋層？從本文的角度來講，覆蓋層指在當前頁面上打開的臨時界面。這些臨時界面能夠完成提示性的或上下文相關的任務，它們的打斷性較弱，為用戶保持較為連貫的使用體驗。我們日常會見到的 “浮層”、“彈層”、“彈框”等都在本文的討論范圍內。

覆蓋層有著廣泛的應用場景，但因為各平臺規范不同，又沒有統一說明，所以設計過程中難免會遇到各種問題。 比如在既定場景下無法確定使用哪種覆蓋層具體樣式； 自己設計的自定義樣式沒有平臺默認組件開發效率高。所以本文的目的是梳理常用的覆蓋層樣式和應用場景，幫助大家在設計過程中更有目的性的使用覆蓋層。

今天想要討論的是覆蓋層中最為常用的兩種形式：

· 對話框
· 浮層

下面將對這兩種形式進行具體描述。當然，以下只代表作者本人觀點，歡迎指正。

1、對話框

對話框也叫彈框、彈窗等。它是模態的，需要用戶對其進行操作后才會消失。

1.1 提示型對話框

提示型對話框主要用于對系統級、應用級或用戶操作結果的提示，需要確保用戶知曉當前的狀況或需要用戶進行選擇時適用。iOS平臺和Android平臺的對話框樣式不同，但使用方法一樣。

·優點：能夠確保流程正常執行，防止用戶犯錯。
·缺點：對用戶的打擾較大。

1.1.1 通知型提示

使用場景：通常用于通知用戶某件事情完成了，或重要信息介紹等；

內容：一般由圖文信息+1個確認性按鈕，只能點擊了按鈕后才能退出對話框；

變形：有時會在對話框角上提供關閉按鈕以退出對話框；圖文介紹也可以分多頁；甚至確認按鈕可放置于整個蒙層區域響應。

1.1.2 確認型提示

使用場景：通常用于二次確認、權限獲取申請、引導用戶執行某項操作等場景；

內容：一般由提示描述+2個按鈕構成：描述可帶標題或不帶標題；2個按鈕分別為一個積極的確認按鈕和一個消極的取消/拒絕按鈕構成，積極按鈕放于右側（積極按鈕的位置設計上一直是仁者見仁智者見智，windows平臺一般是把積極按鈕放在右側，而Mac OS更傾向于放在左側，由于windows系統的市場占有率更大，許多web產品都傾向于將積極按鈕放在左側；但在移動端設計場景下，一方面在手指對于右側按鈕的操作更加敏捷，另一方面Android平臺有明文規范建議將積極按鈕放于右側，所以本文建議在移動端設計時將積極按鈕置于右側）。注意：積極按鈕指使得流程順利執行下去的操作，其具體操作可以是“刪除”“放棄”等。

變形：有時會在對話框角上提供關閉按鈕以退出對話框，關閉按鈕一般等效于取消操作。

1.1.3 選擇型提示

使用場景：需要用戶選擇一項操作以保證流程繼續下去；

內容：一般由提示描述+2~3個按鈕構成：描述可帶標題或不帶標題。

1.1.4 小結

針對3種不同的提示型對話框，主要有以下差異：

1.2 輸入型對話框

對話框還可以用于某個或某組信息的輸入。輸入的信息不易過于復雜，點擊對話框的確認鍵后統一執行輸入內容。一般情況下，對話框上不允許再出現其它對話框。

1.2.1 單頁對話框

使用場景：輸入1~2行文本、進行一組多選操作等；

內容：一般由標題+輸入項+2個按鈕構成：一個為確認按鈕，一個為取消按鈕。點擊取消按鈕為退出當前流程，但應根據輸入內容的量和重要程度制定取消時是否需要二次確認。

設計Tips：當輸入內容為文本時，進入對話框就激活第一條輸入框并彈出鍵盤，鍵盤類型需根據輸入的文本類型進行定制，如字母鍵盤、數字鍵盤等。

1.2.2 可滾動對話框

使用場景：輸入內容無法在一頁展示完全時，對話框可支持滑動；

內容：標題置頂+輸入項+操作按鈕置底。注意：即使對話框的內容區域可以滾動，但輸入項內容仍然不宜過多。

1.2.3 全屏對話框

使用場景：全屏對話框與可滾動對話框的使用場景其實非常類似，區別在于全屏對話框能夠承載更多的內容；同時在全屏對話框上允許使用其他對話框。

內容：全屏對話框在形式上非常像新的頁面，但其本質是一個對話框覆蓋層。全屏對話框由標題+關閉按鈕+確定按鈕構成。頁面展開時由底部往上彈出，收起時從上往下收起。

1.2.4 小結

針對3種不同的輸入型對話框，均有確認和取消兩個按鈕，主要差異在于輸入的內容：

2、浮層

本文的浮層指的是出現后一段時間自動消失的反饋信息層，它與知會提示型對話框在使用場景上類似，也主要用于對系統級、應用級或用戶操作結果的提示，區別在于浮層不強求用戶一定要對其進行交互，因而其對用戶的打擾也更弱。

2.1 Toast

使用場景：用戶的每一步操作都應該得到反饋，當有些操作的結果是從界面上不能直接獲得，或反饋為系統反饋時，應該使用Toast；

內容：置于頁面底部的一條半透明浮層，浮層上應是純文本描述（在Android規范中Toast應為純文本描述），出現2-3秒后自動消失；

設計Tips：描述文字在一行內為宜，需要保證用戶在toast出現的2-3秒內掃一眼就知道其要傳達的內容；同一時間只允許有一條Toast出現；

變形：也有將toast放置于頁面中間或頂部的做法；toast的內容也可定制為icon+文字描述或純圖案描述等。

2.2 Snackbar

使用場景：Snackbar是Android平臺特有的交互形式，它也用于向用戶反饋信息，但其打擾程度介于對話框和Toast之間；

內容：置于頁面底部的一條半透明浮層，浮層上應是簡單的文本描述+0~1個按鈕；浮層出現一定時間后自動消失；Snackbar并不是模態的，其出現期間用戶仍然可以在原頁面執行其它操作。

設計Tips：Snackbar最多只能承載1個按鈕，如需超過1個按鈕則需要采用對話框形式；同一時間只允許有一條Snackbar出現；Snackbar與Floating button在同一層上，當Snackbar出現時Floating button需要同步移動，不能被Snackbar遮蓋。

3、小結

上篇主要討論了“對話框”和“浮層”兩類覆蓋層樣式，它們最大的應用場景即是“提示”。如前文中說到的，Toast與Snackbar在使用場景上與提示型對話框類似，當需要對用戶進行提示時到底是用對話框，Toast還是Snackbar呢？這也是自己在設計過程中常常遇到的問題，所以在小結中希望為大家梳理清楚。

當然對話框的應用場景并不止于此，輸入型對話框和全屏對話框主要用于執行一些分支任務或上下文相關的信息補充。這類使用場景除了對話框外還可以使用Actionsheet、Bottom Sheet、menu等交互形式，這些覆蓋層樣式我們將會在下篇中討論。歡迎一起討論哦~

參考文獻：

【１】iOS Human Interface Guidelines
【２】Google Material design

圖片來源：主要來自手機截圖和以上文獻，少量來自google搜索

作者：蔣蕊遙-Jerria，昵稱阿遙，網易UEDC交互小鮮肉一枚，現支持杭研測試項目。商業與體驗就像美食與身材，要找到其中的平衡點–對我就是愛吃又想瘦！所以學習奮斗吧！

本文版權歸原作者所有，轉載請注明出處。如有任何問題，請加微信ixdc-apply詳談。