交互控件科普系列！Dialogs 的常见样式和设计注意事项总结

在前两篇文章中为大家介绍过 Snackbars 和 Banners 两位轻量级提示控件的用法，今天就让我们来继续详解一下 BOSS 级的提示控件 Dialogs 家族。

往期回顾：

• 《交互控件科普系列！ Sheet 的常见样式和设计注意事项总结》
• 《交互控件科普系列！Snackbar 的常见样式和设计注意事项总结》

什么是Dialog

Dialog 正是我们熟称的「弹窗」，该控件属于提示控件中的一种，通常用于强干扰的信息提示，该提示会打断用户的当前操作，用户必须执行对应操作后才可以对其进行取消。

Dialogs 因为属于强干扰，所以在提示时的霸气程度会远远大于 Banner 和 Snackbar，让我们来看看它的霸气到底体现在哪里。

视觉层：

• Dialog 显示时会用深色遮挡背景，并居中显示在页面中央，使用户不得不将注意力全部集中于 Dialog 之上；
• Banner 显示时仅占据页面顶部，形成局部的视觉干扰；
• Snackbar 显示时展示在页面底部，几秒之后就会自己悄悄溜走。

操作层：

• Dialog 持续期间会禁止用户进行其它页面操作；
• Banner 会长时间持续，但不会影响用户进行其它操作；
• Snackbar 仅会持续几秒，用户进行其它操作时它会立即识趣地走开。

综上所述，三个提示控件的干扰度从强到弱排序可以视为：Dialog > Banner > Snackbar。Dialog 虽然霸气非凡，但对用户过份霸气终究不是一件好事，毕竟强制中断用户行为会引起使用者强烈的反感。

因此我们不得不建议产品经理和设计师，尽量谨慎使用 Dialog 控件，采用相对柔和的控件来承载提示和操作，譬如 Menus、Bottom sheet、Action sheet 或者 Activity view。当然大家不必着急，这些控件稍后我也会进行一一解析。本篇文章还是留给 Dialogs 家族的成员们。

Alert dialogs 警告对话框

在 Google Material Design 和 iOS Human Interface Guidelines 中都对其有规范定义，属于两端皆可使用的原生控件。

1. 使用场景

Alert dialog 通常用于紧急不可逆情况的提示，需要用户确认该信息。

2. 注意事项

• 不要在标题中使用「抱歉打扰」、「危险！」、「你确定？」此类道歉、警告或含糊不清的标题；
• 不要打乱按钮顺序，肯定性按钮在右，否定性按钮在左；
• 建议使用三种按钮文案，确定文案（如删除/导出）、驳回文案（如取消）和确认文案（如我知道了/好的）；
• 不要滥用，无预期的频繁打断用户会引发反感；
• 绝对不能被其他元素遮挡，需一直保持焦点直到被关闭或某个动作已被执行。

3. 样式类型

左侧竖排为 Android 样式，右侧竖排为 iOS 样式。

仅在高风险情况下使用带标题栏的 Alert。

4. 显示与消失

显示

Alert 显示时，背景显示深色遮罩，并会立即中断用户正在进行的操作。

消失

Alert 仅支持 2 种关闭方式：

• 点击确定按钮后立即执行并关闭；
• 点击取消按钮后取消操作并关闭。

5. 范例

有道云笔记在删除文档时，使用 Alert 以警告用户删除的内容将无法恢复。

Simple dialogs 简易对话框

特属于 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）

Confirm dialogs 确认对话框

特属于 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 来承载彩铃设置功能。

Full-screen dialogs 全屏对话框

特属于 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。

欢迎关注作者的微信公众号：「愚者笔记」