有哪些新手必学的交互控件基础知识？这篇全总结好了！

编者按：本文从收纳+引导、提示+引导、提示+操作等多个方面，帮你熟悉常见的交互控件知识。

更多更系统的交互控件知识请看专题 👉 https://www.uisdc.com/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

全屏对话框包含一些列的操作任务，这些操作任务可能需要用到键盘输入并且还可能包含子对话框，典型的使用场景如：填写表单、设置日程等。

本文科普到这就结束了，更多的干货，建议大家阅读相关的文章推荐。