1. Toasts 輕提示
1.1. 簡介
Toasts 原本是 Android 系統(tǒng)獨有的控件，但我在最新的 Material Design 里已經(jīng)找不到這個控件了 Android 的開發(fā)者指南中有這個控件）。
根據(jù)網(wǎng)上相關(guān)文章的介紹，在 Android 之前的官方設(shè)計規(guī)范里，Toasts 應(yīng)該是非模態(tài)的、純文本的、出現(xiàn)在屏幕底部，且不支持交互的。但隨著這個概念的泛化，現(xiàn)在已經(jīng)出現(xiàn)了各種打破規(guī)范的 Toasts ，比如模態(tài)的、帶圖標的、可交互的等等。
而 iOS 系統(tǒng)，一直以來都沒有 Toasts 這個概念，類似于 Toasts 的組件是 UIProgressHUD，例如，調(diào)節(jié)音量時的提示（這個控件在 iOS 13 之后也有了更新）。但這個組件是系統(tǒng)私有的，第三方應(yīng)用無法直接獲取使用。所以，我們在 iOS 第三方應(yīng)用中看到的很多 HUD 都是第三方控件（如 MBProgressHUD）或者是應(yīng)用自定義的。
在這里，我們把所有響應(yīng)用戶操作而呈現(xiàn)，短暫顯示后可自動消失的輕量級提示都統(tǒng)一稱為 Toasts。
1.2. 特點及使用場景
(1) 對用戶干擾較小，是一種輕量級的反饋提示。不適用于展示大量文案、重要信息。
(2) 主要用于通知用戶操作結(jié)果或狀態(tài)變化（重點在告知用戶信息，而不是提供操作）。
(3) 主要類型包括：
① 普通提示（成功提示、失敗提示、警告提示）：非模態(tài)，不打斷用戶當前的操作任務(wù)；不支持手動關(guān)閉，不支持交互，顯示幾秒后自動消失。
② 加載提示：有兩種加載場景。
? 不需要打斷用戶的操作：非模態(tài)，不支持手動關(guān)閉，不支持交互，加載完成后自動消失。
常用于進入新頁面時加載數(shù)據(jù)的提示。
這種加載提示一般可用其他體驗更好的方式替代，例如，使用局部加載而不是全局加載、將加載提示放到導航欄、將加載提示放到觸發(fā)按鈕上等（見文末的「10. 模態(tài)情境的使用」部分）。
? 需要打斷用戶的操作：模態(tài)，一般帶有「取消」按鈕；加載完成自動消失；點擊「取消」按鈕，可取消加載，關(guān)閉提示。
如果用戶只能等加載結(jié)束后才能進行其他操作，但中斷時間比較短，就可以使用這種模態(tài)的加載提示，例如支付、下載、上傳等。（如果中斷時間比較長，一般會使用新頁面展示加載進程。）
參考《5000 字，總結(jié) App 加載設(shè)計》 ，這類場景一般有兩種情況：一是用戶如果執(zhí)行其他操作將會打斷正在進行的加載過程；二是用戶當前執(zhí)行的操作本身不能和其他操作同時進行。這個需要根據(jù)具體的功能、業(yè)務(wù)和開發(fā)實現(xiàn)技術(shù)等因素綜合確定。
1.3. 設(shè)計原則
(1) 一次只顯示一個 Toast。
(2) 視覺樣式
可包含簡單圖標，也可為純文本。
(3) 文案
① 盡量精簡。參考 Ant Design ，包含圖標的 Toasts 一般為 4-6 個字，純文本的 Toasts 一般不超過 14 個字。
② 盡可能使用與觸發(fā)提示的操作直接相關(guān)的動詞或詞組，如，評論中、刷新成功等；若是失敗提示，直接指出出錯原因。
③ 盡量避免使用 “你”、“你的”、“我”、“我的” 這類代詞。
(4) 顯示時長
Android 的開發(fā)文檔中提到的兩個默認時長分別為 2s 和 3.5s。但是暫時沒有查到它的設(shè)計緣由，不知道是不是僅適用于英文環(huán)境。
根據(jù)網(wǎng)上相關(guān)的文章，中文環(huán)境下，成人的平均閱讀速度為一分鐘 300-500 字，按一秒鐘 7 個字計算的話，6 個字以內(nèi)顯示 1s，7-10 個字顯示 1.5s，11-14 個字，顯示 2s。
此外，參考《人機工程學在交互設(shè)計中的運用》，對于加載提示：如果 1s 內(nèi)加載完成，不顯示加載提示；1~6s 加載完成的，顯示加載提示；6s 內(nèi)未加載出來的，顯示加載失敗。
(5) 顯示位置
① 同類型 Toasts 的出現(xiàn)位置最好保持一致，用戶會習慣于在固定的位置感知反饋信息。
② 一般在屏幕中居中。但，對于普通提示，顯示在頂部更好，可減少對用戶的打擾，并且不會因為鍵盤的出現(xiàn)而浮動或被擋住。
2. Snackbars 底部提示框
2.1. 簡介
Snackbars 是 Android 平臺的控件，跟 Toasts 非常相似。兩者的區(qū)別在于，Snackbars 可以包含一個操作（不是「取消」這類用于關(guān)閉的按鈕）。（根據(jù)網(wǎng)上的相關(guān)文章，在以前的規(guī)范里，Snackbars 是支持主動滑動關(guān)閉的。但是，現(xiàn)在 Material Design 的指南里并沒有這一項。）
雖然現(xiàn)在的 Material Design 里已經(jīng)找不到 Toasts，Snackbars 也可以取代 Toasts，但在實際運用中，還是 Toasts 用得比較多，用戶可能還是對 Toasts 比較熟悉。
2.2. 官方規(guī)范
(1) 非模態(tài)。
(2) 顯示在屏幕底部。
(3) 一次只展示一個 Snackbar。
(4) 只能包含一個文本按鈕，且文本顏色不能與提示信息文本顏色一樣。
(5) 文本按鈕不能是「取消」、「忽略」等用于關(guān)閉 Snackbars 的按鈕。
(6) 背景必須完全不透明，并帶陰影。
(7) 顯示 4~10s 后自動消失，不支持手動關(guān)閉。
2.3. 實際應(yīng)用
實際運用中，有一個樣式與 Snackbars 非常類似的比較常見的控件（如下圖所示），網(wǎng)絡(luò)上一些文章將這種底部提示框也稱為 Snackbars。但它跟官方定義的 Snackbars 的交互方式已經(jīng)不太一樣了，這種底部提示框：
(1) 非模態(tài)。
(2) 顯示在屏幕底部。
(3) 大部分情況下只包含一個按鈕，但有時也包含「關(guān)閉」按鈕。按鈕的形式可以是圖標、文本按鈕或填充按鈕。
(4) 背景一般為半透明黑色背景。
(5) 一般不會自動消失，可手動關(guān)閉或執(zhí)行相應(yīng)操作后消失。
3. Pickers 選擇器
3.1. 簡介
選擇器展示了一組值，用戶可以從中進行選擇，一般是選擇一個選項。通常用于表單。
3.2. 類型
3.2.1. Wheel Pickers 滑輪選擇器
(1) 類型
① Native Wheel Pickers 原生滑輪選擇器
? iOS 系統(tǒng)原生的滑輪選擇器，目前比較少見。
? 顯示在內(nèi)容視圖中，通常是嵌入表單中或出現(xiàn)在屏幕底部。
? 通常包括一個或多個滑輪，每個滑輪包含一組值。
? 當前選中的值在中間，以深色標識。
? 選中選項后，再次點擊觸發(fā)控件或界面中其他位置，關(guān)閉選擇器，選擇成功。
② Custom Wheel Pickers 自定義滑輪選擇器
包含「取消」和「確定」按鈕，選中選項后，點擊「確定」按鈕，選擇成功，同時關(guān)閉選擇器。點擊遮罩層可關(guān)閉選擇器，效果同點擊「取消」按鈕。
(2) 使用場景
① 當用戶對整組值都比較熟悉（如常見的年月日、省份城市等）的時候，才使用滑輪選擇器。因為當滑輪靜止的時候，大部分的值會被隱藏，所以最好是在用戶對所有值均有預期的情況下才使用滑輪選擇器。
② 若備選項數(shù)量非常多，一般不推薦使用滑輪選擇器。因為滑輪選擇器的高度較小，滾動起來需要花費較長的時間。
③ 若滑輪個數(shù)較多，一般也不推薦使用滑輪。因為滑輪是橫向排列的，橫向屏幕空間不夠時，可能無法完整顯示數(shù)據(jù)，導致理解、識別困難。參考 Ant Design，最多展示 5 個滾輪，具體視情況而定。
④ 若需要展示一大組用戶并不熟悉的選項，可使用下文的「5.3.2 Bottom Menus 底部菜單」。
3.2.2. Custom Pickers 自定義選擇器
使用底部模態(tài)面板來承載選擇器的內(nèi)容，如下圖的地址選擇器。
4. Popovers 氣泡浮層
4.1. 簡介
氣泡浮層是?戶點擊某個控件或者屏幕上某個區(qū)域后，出現(xiàn)在屏幕其他內(nèi)容之上的臨時窗?。通常包含一個指向觸發(fā)它顯示的控件或區(qū)域的箭頭，具有明確的指向性。
4.2. 類型
4.2.1. Native Popovers 原生氣泡浮層
(1) 系統(tǒng)原生的氣泡浮層可以包含各種各樣的元素，如導航欄、 ?具欄、標簽欄、表格、精選窗口、 圖像、地圖和自定義窗?等。
(2) 包含「取消」按鈕，點擊「取消」按鈕可關(guān)閉浮層。
(3) 既有模態(tài)的，也有非模態(tài)的。
① 模態(tài)的氣泡浮層：打開氣泡浮層后，其他操作將被中斷?？赏ㄟ^浮層上的「取消」或其他按鈕關(guān)閉浮層。
② 非模態(tài)的氣泡浮層：可通過點擊浮層上的按鈕或屏幕中其他區(qū)域來關(guān)閉浮層。
(4) 僅在較大的屏幕上使用，如，iPad。（如果需要在手機上用浮層來承載同樣的內(nèi)容，可以使用下文的「8. Full-screen Modal Views 全屏模態(tài)視圖」。）
4.2.2. Tooltips 文字提示
在手機端，有兩種常見的小型氣泡浮層。其中一種就是 Tooltips。
(1) 用于簡單的信息提示或操作引導，進入特定頁面、點擊特定元素或滿足特定條件后觸發(fā)顯示。
(2) 通常是非模態(tài)的。
(3) 短暫顯示自動消失，或點擊界面中其他區(qū)域、點擊該元素、執(zhí)行其他指定操作后關(guān)閉浮層。有時候也會包含一個關(guān)閉按鈕，點擊后可關(guān)閉浮層。
4.2.3. Pop Menus 氣泡菜單
手機端另外一種常見的小型氣泡浮層是 Pop Menus。詳情見下文的「5.3.1. Pop Menus 氣泡菜單」。
5. Menus 菜單
5.1. 簡介
將動作或內(nèi)容選項折疊收起來，通過點擊、長按等手勢喚起臨時視圖，進行菜單選擇。通常是折疊次要場景的、較低頻的選項。
所以，菜單常用的使用場景有：
(1) 啟動任務(wù)：將操作命令收納起來，點擊選項后在當前頁面執(zhí)行某個操作，或?qū)Ш街聊繕隧撁?。（菜單項不需要選中狀態(tài)。）
(2) 篩選內(nèi)容：將篩選條件收納起來，選擇選項后對當前頁面內(nèi)容進行篩選。（菜單項有選中狀態(tài)。）
① 單一篩選條件且單選：常采用列表的形式。
② 多個篩選條件或多選：常采用標簽的形式。
③ 復雜的篩選條件：一般會采用頂部 tab、側(cè)邊 tab 與列表或標簽結(jié)合的形式。
5.2. iOS 兩種常用的特定菜單
5.2.1. Action Sheets 動作面板
(1) 簡介
Action Sheets 為了響應(yīng)某個控件或操作而出現(xiàn)，提供與當前情境相關(guān)的兩個或多個選項。使用 Action Sheets 來讓用戶啟動某項任務(wù)，或在用戶執(zhí)行具有潛在破壞性的操作之前向用戶請求確認。
在小屏上，Action Sheets 從屏幕底部向上滑出。在大屏上，Action Sheets 以 Popovers（氣泡浮層）的形式呈現(xiàn)。
(2) 特點及使用場景
① 由用戶某個操作行為觸發(fā)。
② 提供一系列在當前情境下可以完成當前任務(wù)的操作。
③ 在用戶完成一項可能有風險的操作前獲得用戶的確認。
(3) 設(shè)計原則
① 模態(tài)。
② 從屏幕底部向上滑出。
③ 包含兩個或兩個以上的按鈕，點擊按鈕即執(zhí)行相應(yīng)命令。
④ 提供「取消」按鈕，點擊「取消」按鈕或遮罩層關(guān)閉 Action Sheets。
⑤ 最好使用紅色文字來表示可能存在破壞性的操作。
⑥ 避免操作太多，需要進行滾動的情況。
⑦ 可在頂部對執(zhí)行對象進行描述，包括圖片、文本等形式。
5.2.2. Activity Views 活動視圖
(1) 簡介
Activity Views 用于顯示用戶可針對當前內(nèi)容執(zhí)行的一系列服務(wù)（活動）。通常情況下，點擊之后該項活動會立刻執(zhí)行。若某項活動過于復雜，系統(tǒng)則會進一步請求獲取更多的信息后才為用戶執(zhí)行該服務(wù)。
(2) 設(shè)計原則
① 模態(tài)。
② 點擊「取消」按鈕或者遮罩層關(guān)閉 Activity Views。
③ 確?；顒邮强梢詫Ξ斍按翱谥械膬?nèi)容進?操作的。
④ 活動標題盡量精簡，且，標題中盡量避免包含公司或產(chǎn)品名稱。
5.3. 常見自定義菜單
5.3.1. Pop Menus 氣泡菜單
(1) 以 “小型氣泡浮層” 的形式承載菜單功能。
(2) 通常包含一個箭頭，指向浮層出現(xiàn)的位置（有時候也不包含箭頭）。
(3) 選中某個菜單項后，自動關(guān)閉氣泡浮層。
(4) 一般是模態(tài)的?？稍跉馀莞酉嘛@示遮罩層，也可不顯示。點擊遮罩層或界面中其他區(qū)域，可關(guān)閉浮層。（比較特別的是，像微信和 QQ，彈出氣泡浮層后，界面中其他元素均不可點擊，但仍可切換底部 tab。）
(5) 與 Action Sheets 的區(qū)別：
? Pop Menus 指向性比較明確，在觸發(fā)控件附近顯示，使用起來比較便捷，并且呈現(xiàn)形式對用戶打擾較小。
? Action Sheets 從屏幕底部彈出后可能會擋住觸發(fā)控件，或者相距較遠，點擊后需移動視線到屏幕下方，并且所占屏幕空間較大，加上底部遮罩層的視覺樣式，對用戶打擾較大。
? 在手機端，以上區(qū)別影響較小。所以，一般情況下，當使用場景為「啟動任務(wù)」或「篩選內(nèi)容」時，既可以使用 Pop Menus，也可以使用 Action Sheets。
? 在 iPad 等較大的屏幕上，則一般使用 Pop Menus。
5.3.2. Bottom Menus 底部菜單
(1) 以 “底部模態(tài)面板” 的形式承載菜單功能。從底部向上滑動出現(xiàn)的面板，可承載的菜單項較多。
(2) 模態(tài)。向下滑動面板、點擊「關(guān)閉」按鈕或遮罩層關(guān)閉面板。
(3) Action Sheets 和 Activity Views 可以看作一種特定的底部菜單。
(4) 底部菜單用于篩選內(nèi)容時：
① 單個篩選條件：選中選項后，自動關(guān)閉面板。
② 多個篩選條件：一般包含「重置」和「確定」按鈕，選擇菜單項后，點擊「確定」才關(guān)閉面板，點擊「重置」可清空所有已選條件。
5.3.3. Top Menus 頂部菜單
(1) 以 “頂部彈出層” 的形式承載菜單功能。
(2) 模態(tài)。點擊遮罩層可關(guān)閉彈層。
(3) 通常與頂部 tab 結(jié)合，切換 tab 直接關(guān)閉當前彈層，同時顯示新的彈層。
(4) 常用于篩選內(nèi)容：
① Tab 下僅包含一個篩選條件：選中選項后，自動關(guān)閉彈層。
② Tab 下包含多個篩選條件：一般包含「重置」和「確定」按鈕，選擇菜單項后，點擊「確定」才關(guān)閉彈層，點擊「重置」可清空所有已選條件。
5.3.4. Side Menus 側(cè)邊菜單
(1) 以 “側(cè)邊彈出層” 的形式承載菜單功能。
(2) 模態(tài)。點擊遮罩層可關(guān)閉彈層。
(3) 抽屜式的側(cè)邊菜單可承載更多篩選條件更多選項。常見的使用場景是，當篩選條件比較復雜時，與上文的「5.3.3. Top Menus 頂部菜單」結(jié)合，將較高頻使用的篩選條件用「tab + 頂部菜單」的形式呈現(xiàn)，其他更多的較低頻的條件都放在側(cè)邊菜單中。
5.4. iOS 官方提供的其他菜單類型
5.4.1 Edit Menus 編輯菜單
(1) 長按或單擊文本視圖、網(wǎng)頁或圖片視圖中的元素來選擇內(nèi)容并顯示編輯選項，例如復制和粘貼。
(2) 自定義命令的數(shù)量不宜過多，太多選擇會讓?戶感到困惑。
(3) 保持自定義命令名稱簡短。命令名稱應(yīng)該是動詞或簡短的動詞短語，簡潔地描述要執(zhí)行的動作。
(4) 如果未選擇任何內(nèi)容，則菜單不應(yīng)顯示如 “復制” 或 “剪切” 等操作選項。同樣，如果已選擇某些內(nèi)容，則菜單不應(yīng)顯示 “選擇” 選項。
(5) 不要使?與編輯菜單相同的功能的其他控件。提供多種?式來啟動操作會導致?戶體驗不一致并導致混淆。例如，如果應(yīng)用中允許?戶使?菜單復制內(nèi)容，請不要使用復制按鈕。
5.4.2 Context Menus 情境菜單
(1) iOS 13 之前叫「Peek and Pop 預覽彈出功能」，只能在支持 3D Touch 的設(shè)備上使用。主要用于快速預覽內(nèi)容；如果 app 進行了相應(yīng)的支持，還可以通過向上輕掃預覽視圖喚出相關(guān)的操作選項。
(2) iOS 13 及 iOS 13 之后，所有設(shè)備都可使用「Context Menus 情境菜單」。長按或 3D Touch 均可喚出情境菜單，但 3D Touch 的速度會更快。并且，喚出情境菜單時，相關(guān)操作菜單會同時呈現(xiàn)，無需進一步操作。
(3) 為 app 當中所有可能產(chǎn)生相關(guān)操作的內(nèi)容對象添加情境菜單功能。這樣既便于操作，也利于發(fā)現(xiàn)所有可執(zhí)行的功能。
(4) 情境菜單雖然很便捷，但并不是所有用戶都能始終想到去使用它。所以，情境菜單中提供的功能也應(yīng)該能夠在界面中的其他地方被訪問到。
5.4.3. Home Screen Quick Actions 主屏幕快捷操作
(1) 主屏幕快捷操作是 iOS 獨有的交互形式，只在主屏中使用，用于快速執(zhí)行應(yīng)用的常用任務(wù)。通過 3D Touch 喚起 app 指定的快捷操作菜單。只需比 “長按” 更重一些的按壓，就能看到高頻操作菜單。
(2) 顯示符合上下文情景的操作選項，并用通用的文案描述。
(3) 盡可能地減少選項數(shù)量，只顯示最有意義的操作。
(4) 使用標準手勢喚起菜單。
(5) 根據(jù)喚起的位置，自動調(diào)整菜單的位置。
6. Dialogs 對話框
6.1. Alerts 警告框
6.1.1. 簡介
警告框用于傳達與 app 或設(shè)備狀態(tài)相關(guān)的重要信息，并且通常需要得到用戶的反饋。
警告框的內(nèi)容包括標題，描述消息（可選）、一個或多個按鈕以及輸入框（可選）。除這些元素外，警告框的外觀樣式是不可更改的。
6.1.2. 特點及使用場景
(1) 盡量避免使?警告框。
警告框?分影響?戶的操作體驗，只應(yīng)該在重要的場景下使用。例如，確認購買和破壞性的操作（如，“刪除”），或，通知用戶有關(guān) app 和設(shè)備的問題（警告、預警之類的問題）。（一般，系統(tǒng)主動發(fā)出的重要通知就是使用 Alerts。）
(2) 主要有以下幾種類型。
① 根據(jù)按鈕數(shù)量分
? 一個按鈕：通常用于通知，因為它不提供其他更多的操作選擇。
? 兩個按鈕：官方建議采用的警告框，它提供了兩個選擇，方便用戶做出決定。
? 三個按鈕：按指南中的建議，三個及三個以上按鈕會讓選擇變得復雜，而且按鈕數(shù)量過多可能出現(xiàn)需要滾動的情況，會造成不好的用戶體驗，這種情況下可以考慮使用 Action Sheets。但其實官方組件中還是有三個按鈕的警告框，比如，獲取用戶授權(quán)時的警告框。
② 包含應(yīng)用評分的警告框
③ 包含輸入框的警告框
④ 包含選項選擇的警告框
除了以上樣式的警告框，這里根據(jù)我們的產(chǎn)品的具體情況，增加了一種包含選擇列表的警告框，通常用于在提交重要操作之前進行選擇并確認。選擇列表可以是單選列表（單選框）或者多選列表（復選框）。
對于多選列表，一般未選擇任何選項時，提交按鈕為禁用狀態(tài)。
(3) 除了以上提到的操作數(shù)量過多的情況可考慮使用 Action Sheets 之外，一般情況下的操作確認也可用 Action Sheets 代替，比如，點擊「取消關(guān)注」后的操作確認（不算危險操作，一般不會造成嚴重后果）。
(4) 按指南中的建議，在顯示警告框的情況下，若用戶切回到手機主屏幕，相當于按下「取消」按鈕。
6.1.3. 設(shè)計規(guī)范
(1) 模態(tài)。不提供關(guān)閉按鈕，不支持點擊遮罩層關(guān)閉警告框，用戶必須作出操作決策。（"取消" 不是 “關(guān)閉”，“取消” 是我選擇取消，不執(zhí)行這個動作，“關(guān)閉” 是我不做任何選擇直接關(guān)閉，沒說到底執(zhí)不執(zhí)行這個動作。）
(2) 確保警告框在豎屏和橫屏中均顯示正常。
設(shè)計時需考慮警告框的最大高度，保證豎屏和橫屏模式下文字都能完整顯示，不需要進行滾動。
(3) 標題
① 使用簡短的描述性標題。
② 可以使?疑問句或簡短的陳述句來傳遞更準確的信息。
③ 盡量避免單個詞的標題，例如，錯誤、警告等。這類標題幾乎不能提供任何有用信息。
④ 盡量將標題控制在?行以內(nèi)。
⑤ 如果標題是完整的句?，句末需添加適當?shù)臉它c符號。如果標題是句??段，不要使用表示結(jié)束的標點符號。
(4) 描述信息
① 如果能?標題表達清楚，就不要增加額外的描述信息。
② 如果一定要增加描述信息，請使?完整的短句。
③ 盡量將句?控制在一、兩行以內(nèi)，并在句末添加適當?shù)臉它c符號。
(5) 按鈕
① 為按鈕設(shè)計簡短而邏輯清晰的文案。
② 盡可能使用與警告文案直接相關(guān)的動詞或動詞詞組，如「View All 查看全部 」、「Reply 回復」和「Ignore 忽略」等。如果是簡單的通知，也可以使用「OK 好的 / 我知道了」。避免使用「Yes 是」或「No 否」。
③ 強化會產(chǎn)?破壞性操作的按鈕。如，「刪除」應(yīng)采用 “負向” 的視覺樣式，以表警示。
④ 盡量避免對警告按鈕做出解釋。如果警告框的文本和按鈕標題內(nèi)容傳達的信息?夠明確， 就不需要解釋按鈕的作?。
⑤ 通常來說，取消按鈕放在左邊，右邊的按鈕是用戶最有可能點擊的按鈕，即否定性操作放左邊，肯定性操作放右邊。
(6) 文案
① 避免出現(xiàn)指責、侮辱的語氣。
② 避免出現(xiàn) “你”，“你的”，“我”，“我的” 這類詞語，因為這類詞匯有時候會給人生疏和趾高?昂的感受。
③ 不用刻意避免在警告框中使用消極負面的文案。?戶知道警告框彈出是出現(xiàn)了問題和危險的情況。只要語?友好，直截了當?shù)膫鬟_消極的消息會比表意模糊的積極消息更更好。
6.2. Custom Dialogs 自定義對話框
(1) 可視為系統(tǒng)原生的 Alerts 的變形。
(2) 常見于運營宣傳、用戶引導等場景。
(3) 可進行各種樣式自定義，具有更強的視覺表現(xiàn)。可包含更多其他的操作，具體視場景而定。
(4) 模態(tài)。通常點擊遮罩層可關(guān)閉對話框，同時也包含關(guān)閉按鈕或其他可退出模態(tài)的按鈕，這樣用戶一目了然地知道如何關(guān)閉對話框。
7. Modal Sheets 模態(tài)面板
7.1. Default Modal Sheets 默認模態(tài)面板
7.1.1. 簡介
模態(tài)面板從屏幕底部向上滑出并覆蓋屏幕，用途是切換任務(wù)狀態(tài)。iOS 13 之后默認的模態(tài)面板樣式是 “卡片風格的模態(tài)面板”，可用于不包含復雜任務(wù)的、非沉浸式的模態(tài)內(nèi)容。
7.1.2. 呈現(xiàn)樣式
(1) 卡片樣式，部分覆蓋了底層內(nèi)容，未覆蓋的區(qū)域變暗，以防止與它們交互。
(2) 在當前卡片的后面可以看到父視圖或前一張卡片的頂部邊緣，以幫助人們記住打開該卡片時暫停的任務(wù)。
(3) 卡片風格的好處在于，你可以瞥見面板下方的界面環(huán)境，這樣你便可以意識到原本的任務(wù)流程或模式仍然在進行當中。（過去的全屏模態(tài)視圖很容易使人們忘記之前的任務(wù)進程。）
7.1.3. 退出模態(tài)的方式
(1) 對不包含滾屏內(nèi)容的面板，在卡片上的任意位置向下輕掃可關(guān)閉卡片面板；對包含滾屏內(nèi)容的面板，向下輕掃會先使內(nèi)容回滾到頂部，然后再繼續(xù)下拉才會關(guān)閉整個面板。
(2) 無論是否包含滾屏內(nèi)容，從卡片頂部向下滑動都可以直接關(guān)閉面板。
(3) 通過點擊按鈕關(guān)閉面板。
(4) 如果面板中包含需要通過縱向輕掃進行操作的控件，或是包含必須進行操作決策的邏輯，那么任何下拉關(guān)閉的操作都將被禁用，面板會自動彈回到默認的位置。譬如，當我們必須通過點擊「取消」或「添加」按鈕來結(jié)束當前邏輯狀態(tài)的時候。
(5) 對于必須在結(jié)束模態(tài)之前完成操作決策的情況，可以通過呈現(xiàn) Action Sheets 來禁止卡片的關(guān)閉，同時與用戶進行操作確認。
7.1.4. 為模態(tài)面板提供按鈕
(1) 可視化的按鈕可以一目了然地幫助人們意識到面板可以被關(guān)閉。
(2) 這對于可訪問性設(shè)計原則來說也是必需的。
(3) 此外，人們可能一時還無法習慣于通過手勢來關(guān)閉面板，或是根本不想進行手勢操作。
(4) 對于包含滾屏內(nèi)容的面板來說，直接點擊按鈕進行關(guān)閉會更加便捷。
(5) 明示著「確認」和「取消」邏輯的可視化按鈕還可以幫助人們快速理解有哪些選項可供執(zhí)行。
7.2. Custom Bottom Sheets 自定義底部面板
7.2.1. 簡介
現(xiàn)在，很多應(yīng)用都開始使用卡片風格的底部模態(tài)面板，iPhone 上的原生應(yīng)用也有很多使用半屏底部模態(tài)面板的場景。
底部模態(tài)面板可用于展示更多額外的內(nèi)容，減少頁面跳轉(zhuǎn)。例如，上文的「自定義選擇器」等等。
7.2.2. 退出模態(tài)的方式
與系統(tǒng)默認的卡片模態(tài)面板退出方式一樣，但除此之外，大部分底部面板還可通過點擊遮罩層退出模態(tài)。
8. Full-screen Modal Views 全屏模態(tài)視圖
8.1. 簡介
全屏模態(tài)視圖會覆蓋整個屏幕，即前一個視圖會被完全覆蓋，因此有更多的屏幕空間來展示內(nèi)容，并且使視覺干擾降至最低。通過點擊「取消」或「完成」按鈕來取消全屏模式視圖。
8.2. 使用場景
(1) 沉浸式內(nèi)容，如視頻、照片或相機視圖等。
(2) 使用全屏展示會更好的復雜任務(wù)，如標記文檔或編輯照片等。
9. 總結(jié)對比
9.1. 控件總覽
9.2. 部分控件對比
10. 模態(tài)情境的使用
10.1. 使用建議
(1) 模態(tài)一般用于切換任務(wù)流程。
例如，在「日歷」app 中，瀏覽日程列表里所有日程和瀏覽某個特定日程的詳情，都屬于 “瀏覽”，此時，進入日程詳情就不需要使用 “模態(tài)”；而當需要創(chuàng)建或編輯日程事項時，就會進入 “編輯” 模式，此時，就需要用到模態(tài)面板，讓用戶意識到任務(wù)流程的變更。
(2) 盡可能減少應(yīng)用中的模態(tài)體驗。通常，僅在以下情境考慮使用模態(tài)：
① 必須引起用戶關(guān)注的時候。
② 一個獨立的任務(wù)需要完成或者很明確需要被放棄，為了避免在模棱兩可的狀態(tài)下遺漏用戶信息的時候。
(3) 始終提供明顯、安全的退出模態(tài)的方式。
(4) 確保用戶在退出模態(tài)視圖時可以預期操作的結(jié)果。
(5) 保證模態(tài)任務(wù)簡單、簡短和高度聚焦。
① 如果一個模態(tài)任務(wù)必須包含不同視圖的子任務(wù)，確保給用戶一個獨立、清晰的導航路徑。
② 一個任務(wù)需要多層級的模態(tài)視圖時，盡可能避免在下級視圖中添加「完成」按鈕。否則可能造成困惑，用戶會分不清點擊「完成」按鈕是完成這個視圖中任務(wù)的一部分，還是整個任務(wù)。
10.2. 可替代方案
除了盡可能減少不必要的模態(tài)體驗外，在 iOS 的設(shè)計指南中還提到了，要盡可能地將狀態(tài)改變或其他類型的反饋信息放在界面中，最好是，用戶在不進行操作、不跳出當前內(nèi)容、不被打擾的情況下，就能獲得需要的信息。
以下這些反饋設(shè)計方案，既可以明確、及時告知用戶任務(wù)狀態(tài)（如操作結(jié)果、上傳進度等等），又降低了對用戶的打擾程度，不影響用戶對其他內(nèi)容的瀏覽和操作。
(1) 將反饋（如加載進度等）放在按鈕上。
(2) 適當添加動效。（合理的動效還可提升使用時的愉悅感。）
(3) 將不需要打斷用戶操作的圖片、視頻的上傳、轉(zhuǎn)碼等進程放到后臺進行。（這個需要根據(jù)具體的功能、業(yè)務(wù)和開發(fā)實現(xiàn)技術(shù)等因素綜合確定。）
(4) 頁面內(nèi)提示。表單校驗使用實時校驗，并在出錯項附近顯示錯誤提示。
(5) 其他交互方式：合理地使用推擠等交互形式。
------
1. 文中配圖展示的控件樣式僅為參考，實際運用中可根據(jù)具體產(chǎn)品功能、業(yè)務(wù)場景、設(shè)計風格等進行設(shè)計。
2. 此次規(guī)范梳理的過程中，我在網(wǎng)上查閱并參考了以下官方指南與文章，感謝這些平臺和作者～
iOS：Human Interface Guidelines（Apple Developer）
Android：Documentation for app developers（Google Developers）
iOS-Human-Interface-Guidelines（中文翻譯；作者：Cloudox；來源：GitHub）
MBProgressHUD（作者：Jonathan George；來源：GitHub）
iphone - What is HUD VIEW?（來源：Stack Overflow）
UIProgressHUD（作者：Dustin Howett；來源：iPhone Development Wiki）
你真的了解這些交互控件嗎？（作者：johnnylhj；來源：人人都是產(chǎn)品經(jīng)理）
移動彈窗基礎(chǔ)知識淺析——iOS彈窗體系（作者：常天；來源： TXD技術(shù)體驗設(shè)計公眾號）
實用干貨！UI設(shè)計師需要了解的 APP彈窗體系（來源：優(yōu)設(shè)網(wǎng)）
iOS：自定義模態(tài)（譯文）（作者：半木zxy；來源：知乎）
彈窗、模態(tài)、提示、浮層，這幾位是什么關(guān)系？（來源：知乎）
模態(tài)是一個大多數(shù)設(shè)計師不能完全理解的UX概念（作者：花火圓桌；來源：知乎）
CSS 命名之Dialog, Modal, Popup, Popover, Lightbox 等的區(qū)別（作者：Jeff；來源：騰訊云云+社區(qū)）
What’s the difference between a Modal, Popup, Popover and Lightbox? （來源：Stack Exchange）
正確使用控件 - 確認彈框、全屏彈框和模態(tài)視圖（作者：沐風與體驗設(shè)計；來源：簡書）
3分鐘帶你掌握11個最常用的交互控件（作者：沐風與體驗設(shè)計；來源：簡書）
iOS和Android規(guī)范解析——簡易菜單、簡易對話框和彈出框（作者：沐風與體驗設(shè)計；來源：簡書）
Modal & Nonmodal Dialogs: When (& When Not) to Use Them（作者：Therese Fessenden；來源：NN/g）5000字，總結(jié)App加載設(shè)計（作者：一點優(yōu)秀；來源：人人都是產(chǎn)品經(jīng)理）
toast 吐司提示放在屏幕哪個區(qū)域比較好？（來源：知乎）
Can an Android Toast be longer than Toast.LENGTH_LONG?（來源：Stack Overflow）
Designing Toast Messages for Accessibility（作者：Sheri Byrne-Haber；來源：Medium）
人機工程學在交互設(shè)計中的運用（作者：XUE.百度；來源：人人都是產(chǎn)品經(jīng)理）
文章來源：站酷 作者：天真兒
分享此文一切功德，皆悉回向給文章原作者及眾讀者.
免責聲明：藍藍設(shè)計尊重原作者，文章的版權(quán)歸原作者。如涉及版權(quán)問題，請及時與我們?nèi)〉寐?lián)系，我們立即更正或刪除。
藍藍設(shè)計( www.cqzjtgb.com )是一家專注而深入的界面設(shè)計公司，為期望卓越的國內(nèi)外企業(yè)提供卓越的UI界面設(shè)計、BS界面設(shè)計 、 cs界面設(shè)計 、 ipad界面設(shè)計 、 包裝設(shè)計 、 圖標定制 、 用戶體驗 、交互設(shè)計、 網(wǎng)站建設(shè) 、平面設(shè)計服務(wù)