沐鸣登录网站_交互控件科普系列！Dialogs 的常见样式和设计注意事项总结
在前两篇文章中为大家介绍过 Snackbars 和 Banners 两位轻量级提示控件的用法，今天就让我们来继续详解一下 BOSS 级的提示控件 Dialogs 家族。
往期回顾：
- 《交互控件科普系列！ Sheet 的常见样式和设计注意事项总结》
- 《交互控件科普系列！Snackbar 的常见样式和设计注意事项总结》
Dialog 正是我们熟称的「弹窗」，该控件属于提示控件中的一种，通常用于强干扰的信息提示，该提示会打断用户的当前操作，用户必须执行对应操作后才可以对其进行取消。
Dialogs 因为属于强干扰，所以在提示时的霸气程度会远远大于 Banner 和 Snackbar，让我们来看看它的霸气到底体现在哪里。
视觉层：
- Dialog 显示时会用深色遮挡背景，并居中显示在页面中央，使用户不得不将注意力全部集中于 Dialog 之上；
- Banner 显示时仅占据页面顶部，形成局部的视觉干扰；
- Snackbar 显示时展示在页面底部，几秒之后就会自己悄悄溜走。
操作层：
- Dialog 持续期间会禁止用户进行其它页面操作；
- Banner 会长时间持续，但不会影响用户进行其它操作；
- Snackbar 仅会持续几秒，用户进行其它操作时它会立即识趣地走开。
综上所述，三个提示控件的干扰度从强到弱排序可以视为：Dialog > Banner > Snackbar。Dialog 虽然霸气非凡，但对用户过份霸气终究不是一件好事，毕竟强制中断用户行为会引起使用者强烈的反感。
因此我们不得不建议产品经理和设计师，尽量谨慎使用 Dialog 控件，采用相对柔和的控件来承载提示和操作，譬如 Menus、Bottom sheet、Action sheet 或者 Activity view。当然大家不必着急，这些控件稍后我也会进行一一解析。本篇文章还是留给 Dialogs 家族的成员们。
在 Google Material Design 和 iOS Human Interface Guidelines 中都对其有规范定义，属于两端皆可使用的原生控件。
1. 使用场景
Alert dialog 通常用于紧急不可逆情况的提示，需要用户确认该信息。
2. 注意事项
- 不要在标题中使用「抱歉打扰」、「危险！」、「你确定？」此类道歉、警告或含糊不清的标题；
- 不要打乱按钮顺序，肯定性按钮在右，否定性按钮在左；
- 建议使用三种按钮文案，确定文案（如删除/导出）、驳回文案（如取消）和确认文案（如我知道了/好的）；
- 不要滥用，无预期的频繁打断用户会引发反感；
- 绝对不能被其他元素遮挡，需一直保持焦点直到被关闭或某个动作已被执行。
3. 样式类型
左侧竖排为 Android 样式，右侧竖排为 iOS 样式。
仅在高风险情况下使用带标题栏的 Alert。
4. 显示与消失
显示
Alert 显示时，背景显示深色遮罩，并会立即中断用户正在进行的操作。
消失
Alert 仅支持 2 种关闭方式：
- 点击确定按钮后立即执行并关闭；
- 点击取消按钮后取消操作并关闭。
5. 范例
有道云笔记在删除文档时，使用 Alert 以警告用户删除的内容将无法恢复。
特属于 Google Material Design 中定义的原生 Dialog 控件。
1. 使用场景
Simple dialog 通常用于提供列表项的详细信息或操作。
2. 注意事项
- 不要使用明确的按钮进行确认或取消操作；
- 在能够使用 Menus、Bottom sheets、Action sheet（iOS）或 Activity view（iOS）的情况下不要使用 Simple dialogs；
- 绝对不能被其他元素遮挡，需一直保持焦点直到被关闭或某个动作已被执行。
样式类型：
3. 显示与消失
显示
Simple dialog 显示时，背景显示深色遮罩，并会立即中断用户正在进行的操作。
消失
Simple dialog 支持 3 种关闭方式：
- 点击一个选项后立即执行并关闭；
- 点击 dialog 外任意区域取消操作并关闭；
- 点击 Android 系统返回键取消操作并关闭。
4. 范例
安卓端的 Keep 利用 Simple dialog 来承载话题举报的操作，用户点击任意一选项后触发提交。（在iOS端使用的是 Action sheet）
特属于 Google Material Design 中定义的原生 Dialog 控件。
1. 使用场景
Confirm dialog 通常用于复杂操作前的最终确认，使其有机会在必要时改变主意。
2. 注意事项
- 需同时提供明确的确认和取消按钮；
- 在能够使用Menus、Bottom sheets、Action sheet（iOS）或Activity view（iOS）的情况下不要使用 Confirm dialogs；
- 绝对不能被其他元素遮挡，需一直保持焦点直到被关闭或某个动作已被执行。
3. 样式类型
支持嵌套 Selection controls。
4. 显示与消失
显示
Confirm dialog 显示时背景显示深色遮罩，并会立即中断用户正在进行的操作。
消失
Confirm dialog 支持 4 种关闭方式：
- 点击确定按钮后立即执行并关闭；
- 点击取消按钮后取消操作并关闭；
- 点击 dialog 外任意区域取消操作并关闭；
- 点击 Android 系统返回键取消操作并关闭。
5. 内容滚动处理
应尽量避免内容滑动，当确实需要滑动时，标题需固定在顶部，按钮固定在底部，保证滚动的同时仍然可见标题和按钮。Dialogs 存在时禁止滚动对话框以外的元素，例如背景。
6. 范例
原生安卓系统使用 Confirm dialog 来承载彩铃设置功能。
特属于 Google Material Design 中定义的原生 Dialog 控件。
1. 使用场景
Full-screen dialog 通常用于对一系列复杂任务的分组。
2. 注意事项
仅在以下场景中使用 Full-screen dialog：
- 有需要用户输入的选择器或表单时；
- 编辑的内容无法实时保存时；
- 没有本地自动保存的草稿功能；
- 在提交前需要进行批量处理或更改队列时。
Full-screen dialog 仅限于在移动端使用。
3. 样式类型
在 Top app bar 上需展示「X」按钮和确定性按钮。
4. 显示与消失
显示
Full-screen dialog 显示时填充全屏，使用沉浸式的全屏布局。
消失
Full-screen dialog 支持 3 种关闭方式：
- 点击确定性按钮后立即执行并关闭；
- 点击「X」按钮并确认取消操作后关闭；
- 点击 Android 系统返回键并确认取消操作后关闭。
5. 二次确认
点击「X」按钮或系统返回键时，将丢弃所有更改信息并退出，如果用户发生了字段更改，需给予 Confirm Dialog 进行二次确认。
6. 范例
Teambition 使用 Full-screen dialog 来承载 Date picker 和 Time picker 的多重时间设置。
俗话说得好，「好钢用在刀刃上」，产品经理和设计师应当尽量将 Dialogs 应用于非常重要的使用场景（这里也包含我们定制的活动弹窗）。所谓物以稀为贵，少量使用可以凸显出其重要性，过度使用则会使人感到异常反感。
那么如何更好地选择控件呢？
我们可以以内容信息的重要程度为判断基准：
- 不重要程度：用户可以不注意或不操作；
- 一般重要程度：用户可稍后注意或稍后操作；
- 很重要程度：用户必须立即注意或立即操作。
若不重要，请使用 Toast 或 Snackbar；若一般重要，请使用 Banner；若很重要，请尽量先考虑使用 Bottom sheets（Android）、Action sheet（iOS）或 Activity view（iOS）等模态控件。若以上不能满足需求，再使用 Dialogs。
欢迎关注作者的微信公众号：「愚者笔记」
