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

弹框是设计师和用户又爱又恨的控件。产品需要弹框来传递信息，用户需要弹框来接受反馈。但不经推敲，弹框设计随机增加，用户流动（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秒，提示纯文本时间可以稍短，用户操作时间应该更长。综上所述，模态框和非模态框各有优缺点。适当使用模态框可以帮助用户一步一步完成操作，但频繁使用可能会扰乱用户的操作流程。如果只从用户心流的角度来看，非模态框应该更友好，但不能承载操作，有时很容易被用户忽略。因此，如何找到合适、正确的弹框，需要设计师根据具体场景进行推敲。在本期中，我们主要了解平台规范下的模态框和非模态框的控制类型。在深入研究一个控制器之前，我们必须首先了解每个控制器的名称和使用规则。在下一期中，我将对优秀的弹框案例进行更深入的分析。

以上就是关于弹框的规范和进阶使用方法详解的相关介绍，更多弹框的规范和进阶使用方法详解相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对弹框的规范和进阶使用方法详解有更深的了解和认识。