弹框的规范和进阶使用方法详解

弹框是设计师和用户又爱又恨的控件。产品需要弹框来传递信息，用户需要弹框来接受反馈。但不经推敲，弹框设计随机增加，用户流动（Mentalflow）频繁的中断很容易让用户感到沮丧。如何在日常设计工作中设计合理的弹框？什么样的弹框设计是优秀的，为什么有些弹框设计会让用户感到恼火？我将分两个阶段总结弹框的规格和先进使用方法。欢迎继续跟进。在第一期中，让我们先梳理一下平台规范下的弹框是什么？弹框的分类在「弹框」在概念泛化的时候，相信很多设计师已经开始分辨弹框的具体分类了。似乎弹出的窗口在任何情况下都被统称为「弹框」，而且使用手法很模糊。事实上，纵观iOS人机交互规范和MaterialDesign，我们可以将弹框分为两类：模态框和非模态框。模态框模态框（ModalDialog）指需要中断用户的弹框，用户必须在继续主面板操作之前完成对话框中的任务(或主动关闭)。「非模态」就是和「模态」对立概念是指不需要中断用户操作的弹框。事实上，良性模态框可以帮助用户顺利完成任务，因此设计师必须了解模态框的类型和使用规则。1.iOS–Alert和MaterialDesign–Dialogs(对话框)对话框使用最广泛，也是最容易打断用户心流的弹框。因为它直接出现在屏幕中心，双平台明确提醒设计师尽量克制对话框的使用频率。正是因为对话框很容易获得用户的注意力，所以它通常被用来携带非常重要的额外操作或警告信息。对话框值得一提的是，由于系统原有的对话框控件可以在产品设计过程中直接调用，很多设计师往往忘记提醒开发者配置引导用户操作的亮点选项，导致我们经常看到一些违背产品设计意愿的对话框。例如，为了激活睡眠用户或收集用户的个性化信息，产品通常希望获得用户提醒、访问和其他权限，因此弹出框中的操作指导通常应该是积极的。但是我们总能看到一些讽刺的案例。因此，为了方便或出于其他兼容性问题，设计师在调用原始对话框控件时，不应忽视对细节的控制。有时候疏忽很可能会导致用户和用户体验的流失。2.iOS–ActionSheetActionSheet(动作面板)是iOS规范下的控件，近年来也逐渐被安卓化。Actionshet是一个响应控制器，通常需要用户执行某个操作才能弹出(在某些危险情况下，Alert//Dialog），并显示两个或多个与当前操作相关的选项。ActionShet的出现方式是从屏幕底部向上滑出。iOS人机交互规范提醒设计师在使用Actionshet时要注意以下几点:突出破坏性选项:对于用户执行破坏性或危险操作的按钮，应使用红色亮点显示，并放置在Actionshet的顶部。「取消」动作面板底部应始终存在按钮：虽然用户可以点击屏幕的任何空白区域取消Actionshet，但是「取消」当用户不想执行任何操作时，按钮可以给用户一个明确的操作方向，因此不应删除「取消」按钮。避免纵向滚动：滚动意味着操作项已经超过溢出控制器的视觉区域，用户需要额外的时间来选择操作。但由于ActionSheet中每个操作的横向热区都很大，在滑动过程中容易发生误触。此时选择使用ActivityViews会更合理。3.iOS–ActivityViewsActivityViews是iOS10引进的新规范控件。它的诞生是为了解决ActionShet的滚动问题，因此也常被称为ActionShet的宫格模式。众所周知，中国最常见的ActivityViews使用场景是在共享或使用第三方应用程序打开文件时。ActivityViews支持横向滑动。与Actionsheet选项的热区相比，Activityviews选项放置在只有70px*70px的色块中，点击热区相对较小，适合承载更多选项，不易被用户误触。但我发现，目前调用iOS原生ActivityViews控制器已经能够融入宫格 列表的形式，一些应用程序已经开始使用。就我个人而言，我认为这可能是因为当携带的选项太多时，有些选项太落后，用户水平滑动时间太长，但用户很难找到所需的操作。由于iOS支持组件的组合，必须考虑到这种极端情况，因此设计师应根据具体场景随机适应具体的使用方法。4.iOS–Popovers(气泡弹框)和Materialdesign–MenusPopovers通常由指向其出现位置的三角箭头和弹出窗组成。根据iOS规范，Popovers只适用于iPad，但不难发现，跨平台使用Popovers的场景并不少见。各种APP中最常见的Popovers使用场景是信息提示和场景菜单，所以这就是为什么我要把iOSPopovers和MDMenus分类的原因。MD–Menus和iOS–Popovers其实没有太大区别，只是没有三角指向。但我个人认为，用户更容易知道当前弹框中包含的内容与什么操作有关，这实际上对用户更友好。但MD–毕竟Menus是原生控件，款式不再支持修改。因此，在设计师设计个性化气泡弹框时，可以进行更多的改进。与模态框相比，非模态框非模态框更不容易干扰用户的操作，因为当非模态框弹出时，用户仍然可以继续操作主面板中的内容。但是非模态框也有它的缺点:时间短，不容易引起用户的注意；有时用户可能在阅读非模态框中的信息之前就消失了。以下是iOS和MD规范中定义的非模态框。1.MaterialDesign–ToastToast是MD的标准控制器，平台规定Toast应出现在屏幕底部，并且只能包含尽可能少的文本信息，不应出现图标等增加用户认知成本的内容。鉴于上述非模态框的缺点之一：有时用户没有时间阅读非模态框中的信息，弹出框已经消失，行业对吐司弹出框实施了潜规则，认为吐司弹出框的最佳时间是2–3.5秒(即所谓短吐司和长吐司)。在这段时间内不容易干扰用户，也有助于用户阅读完整的提示信息。2.iOS–事实上，iOS的HUD弹框并没有包含在平台规范中，但我们并不陌生。例如，HUD弹框出现在IOS13之前控制设备音量时。但由于HUD弹框体积过大，屏幕信息经常被屏蔽，IOS13后对此类弹框进行了体验优化，因此HUD弹框现在出现的场合已经很少了。但是为什么要单独提出HUD弹框呢？MD规定Toast中不应出现图标等元素，但现在很多APP自定义Toast已经打破了这一规范。我认为这种变化的启蒙点来自HUD弹框。IOS系统一直私有HUD弹框，不能被第三方应用调用。因此，许多应用程序开始模仿HUD弹框的风格，并演变出现在图案多样的Toast弹框。因此，今天的Toast不仅是MD最初规定的标准Toast，有时产品会添加一些自定义元素，考虑到用户的情感需求。3.MaterialDesign–SnackBars非常有趣的是，当SnackBars最初被收录在MD规范中时，它被击中「MDOnly」标签，有一种炫耀设计这个控件的成就感。因为SnackBars是一个中和模态框和非模态框属性的弹框，在其他平台规范中很少见。传统的非模态框不支持操作，会自动消失；模态框必须由用户操作或手动关闭才能消失。SnackBars是一种支持用户操作并自动消失的控件，通常出现在屏幕底部。SnackBars支持两种模式：纯文本提示和操作容器。如何区分它和Toast？谷歌翻译做了一个很好的例子。SnakeBars的弹框长度更长，显示时间更长。MD规定SnakeBars的显示时间应为4–10秒，提示纯文本时间可以稍短，用户操作时间应该更长。综上所述，模态框和非模态框各有优缺点。适当使用模态框可以帮助用户一步一步完成操作，但频繁使用可能会扰乱用户的操作流程。如果只从用户心流的角度来看，非模态框应该更友好，但不能承载操作，有时很容易被用户忽略。因此，如何找到合适、正确的弹框，需要设计师根据具体场景进行推敲。在本期中，我们主要了解平台规范下的模态框和非模态框的控制类型。在深入研究一个控制器之前，我们必须首先了解每个控制器的名称和使用规则。在下一期中，我将对优秀的弹框案例进行更深入的分析。