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