有哪些新手必學的交互控件基礎知識？這篇全總結好了！

編者按：本文從收納+引導、提示+引導、提示+操作等多個方面，幫你熟悉常見的交互控件知識。

更多更系統的交互控件知識請看專題 ?? http://www.czdes.cn/zt/interactive-control

交互控件的名稱和定義在學術界并沒有統一的標準，也許在說某一個名字的時候你并沒有理解它的意思，本文主要是讓大家來見識一下那些常用的交互控件，一起來看看~

一、按照功能劃分

其實關于交互控件的名稱和定義在學術界并沒有統一的標準，但是目前市場主流的 OS 廠商都有自己的標準定義，分為：Apple 的 Human Interface Guidelines 和 Google 的 Material Design。

可以看到：在 Apple 的 Human Interface Guidelines 中 apple 將交互控件歸入視圖（Views）中，而 Google 的 Material Design 將交互控件歸入組件（Components）中。

在這里我不會嚴格按照兩家給出的標準對每一個控件都做詳盡的贅述，我將把工作中常用的組件按照功能來劃分一下并參考 iOS 和 Google 對于這些組件的描述，來向大家簡單梳理一下他們的定義和用法。

二、模態與非模態

在正式開始之前，我先簡單介紹一下模態與非模態。下面是維基百科關于模態窗口（Modal window）的標準解釋。其含義就是：模態窗口下，用戶被強制必須先與當前視窗進行交互才能回到主窗口，此時用戶的行為是線性的。由于其會打斷用戶操作并且強制用戶進行交互，因此模態控件的使用必須謹慎。

反之，非模態即用戶不被強制先與當前視窗進行交互也可以與主窗口直接進行交互，用戶行為是非線性的，擁有更多主動權。

三、收納+引導

這類控件包括 Popup（或者叫 Popover）、Action views、Action sheets/ Sheets_bottom、Dropdown menu，其共同特點是由用戶主動觸發（默認隱藏）、輕量化、指向性較強、包含操作、不會自動消失。

這類控件多用于屏幕空間的移動設備，作為低頻但重要的操作入口（Dropdown menu 在 PC 的應用場景同樣很多）。這一類控件既包含模態又包含非模態。

1. Popup（Popover）&Dropdown menu

iOS 的 Popup（Popover）與 Android 的 Dropdown menu 的使用場景和展現形式基本類似，主要用于收納一些默認不展示的低頻選項， 不過值得注意的是：Popup 和 Dropdown menu 出現的位置和方式與其入口的位置是有很大關系的，特別當入口按鈕是位于屏幕邊緣的時候尤其需要注意。

此外，Popup（Popover）自帶箭頭的強指示性，同樣適用于展示隱藏操作或新功能上線后的用戶教育。

2. Action views&Action sheets

不同于 Popup（Popover）和 Dropdown menu 幾乎可以出現在屏幕的任何位置，Action views 和 Action sheets/ Sheets_bottom 一般出現在屏幕底部。同樣，他們也是用于容納并展示低頻但重要的操作。

四、提示+引導

這類控件包括 Toast、Snackbars、HUD，其共同特點是：不一定由用戶主動觸發、輕量化且一般不包含操作，展示時間較短（一般在 3 秒以內）且會自動消失，這類控件多用于系統狀態或者用戶操作結果的展示。同樣，這類控件基本都是非模態的。

1. Toast

根據維基和 android 開發者指南的解釋：Toast 是一種小巧的作為操作反饋的信息窗口，并且會自動消失。

有意思的是，據說一位微軟前員工在開發 MSN Messenger 時，覺得 MSN 彈出通知方式很像烤面包（Toast）烤熟時從烤面包機（Toaster）里彈出來一樣，因此把這種提示方式命名為 Toast，后來這位微軟前員工帶著這一習慣命名跳槽去了 Google。

其實，在實際應用中，Toast 的應用延伸較多，除了作為操作反饋的信息展示窗口，還常常被用來作為系統狀態更新時的提示，并且在出現的位置上，也沒有非常嚴格的定義。

2. Snackbars

按照使用場景和元素來說，Snackbars 可以簡單理解為 Toast 的升級版本，但根據 Google Material Design 的定義，我們可以發現：Snackbars 與 Toast 的主要差別在于前者可以包含一個操作按鈕，而后者不包含。

在實際應用中，Snackbars 的應用范圍其實比較廣，我們會發現：Snackbars 主要被用在展示一些對用戶很重要的操作結果，比如：刪除文件或者快速引導。

3. HUD

HUD 全稱叫做 UIProgressHUD，其實在 iOS Human Interface Guidelines 中并沒有 Toast 和 Snackbars 這樣的定義，但是與之對應的是 UI Progress HUD（直譯為界面進程浮層），這種控件是 iOS 系統私有的，在 App Store 上線的 app 原則上是不能直接獲取的，所以出現了許多模仿的第三方控件（主要是開放者用以與 iOS 的 UI 風格保持一致的嵌入式組件）。

4. Toast& Snackbars& HUD 小結

其實，我們這樣理解這三者之間的關系更加簡單明了：Google 的 Toast≈iOS的HUD，Snackbars=Toast+操作按鈕，Toast+Snackbars+HUD都是用來展示App或者系統內的狀態信息。

五、提示+操作

這類控件主要是 Dialogs/ Alerts，嚴格意義上來說，其實 Alerts（警告型對話框）也是屬于 Dialogs 中的一種。Google 的 Material Design 將 Dialogs 分為：Alert Dialog、Simple Dialog、Communication Dialog 和 Full-screen Dialog，但是在 iOS 中并沒有定義 Dialogs 這種控件，而只是對 Alerts 做了定義。

對話框的精髓在于讓用戶聚焦，它一般有兩種使用場景：

1. 系統的關鍵狀態提示，并且如果不處理當前狀態會影響到用戶的下一步操作，如：系統錯誤或者電量過低。
2. 需要用戶特別注意的關鍵信息處理，如：刪除文件、支付確認 Google Material Design 關于對話框的定義。

1. Alert Dialog

由于警示型對話框出現的形式非常直接（包含用戶主動觸發與系統自動觸發），且常常會打斷用戶當前操作行為（強打擾性），因此絕大部分的警示型對話框被用在關鍵信息處理或者關鍵狀態提示上，

如：

1. 文件操作場景 — 刪除文件，放棄編輯；
2. 支付場景 — 支付二次確認，余額不足提示；
3. 重要狀態改變場景 — 手機電量低，版本更新。

值得注意的是：在警示型對話框中的按鈕文案使用一定要避免歧義，不要讓用戶做選擇變成一道哲學命題。

Google Material Design 總結了一些 Alert Dialog 按鈕文案的一些基本規則：

① 文案要釋義操作行為，比如：當問題為“您是否要放棄編輯當前的郵件”相比于用簡單的“是”或“否”，使用“放棄編輯”和“繼續編輯”用戶更能清楚操作后的預期效果。

② 從用戶習慣來說，對于當前提問的肯定回答應置于右側，而否定回答應置于左側 。

同樣接著上一個例子，當問及“您是否要放棄編輯當前的郵件”時，“放棄編輯”應該置于右側，而“繼續編輯”應該置于左側。

③ 對于 APP 內或系統重要狀態的提示，不要給多余的按鈕而讓用戶費解。

④ 最好不要在警示型對話框中放置諸如“了解更多”等第三個按鈕，因為它會將用戶引導至其他內容而導致用戶中斷/忘記當前對話框的操作。

2. Simple Dialog

簡易對話框用以展示用戶做即時決斷的選項，選項本身既是信息又是按鈕，不包含單獨的文案按鈕。

一般用于多選其一且不用二次確認的場景，如：地區選擇、語言選擇、郵箱地址選擇等。

3. Confirmation Dialog

確認對話框用于需要用戶進行選擇并手動確認的場景，不同于簡易對話框，用戶可以選擇一項或者多項，并且包含確認和取消按鈕。

4. Full-screen Dialog

全屏對話框包含一些列的操作任務，這些操作任務可能需要用到鍵盤輸入并且還可能包含子對話框，典型的使用場景如：填寫表單、設置日程等。

本文科普到這就結束了，更多的干貨，建議大家閱讀相關的文章推薦。