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

往期回顾:

什么是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。

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

点赞
收藏 47
继续阅读相关文章

发表评论 已发布 3

还可以输入 800 个字
 
 
载入中....
3 收藏