交互基本功-移动端弹层设计规则

工作中我们常常会听到或在撰写交互说明时提到“从底部向上出现弹层”、“出现浮层”、展示“对话框”、弹出“弹框”、“出现对话框”诸如此类的话术。我相信大家对“浮层、弹层、弹框、对话框......”等称呼常常也会感到困惑。到底什么时候应该称呼为“对话框，什么时候称呼弹框”，此类相似的组件又是如何分类的，应该如何应用、如何设计。本文将结合实战经历，把弹层设计经验分享给大家，希望帮助大家对弹出层组件有更清晰的认知和理解。

交互基本功移动端弹层设计规则

• I. 弹出层组件的定义
  • 定义
    • 当触发某项操作时，在页面上方展示的弹出层容器，容器内可展示文本、按钮、列表、标签、表单项等内容，英文名称定义为Popup
  • 弹出位置的不同
    • 五种样式
  • 分类
    • Alert确认框、picker选择器、基于场景的筛选组件
    • 浮层、弹层、弹框、对话框
    • 官方划分
  • 模态弹框
    • 弹出层的一种样式，并非有一种组件的分类被称作是“模态弹框”，而是当弹框采用了“模态”的设计手法时，将其简称为“模态弹窗”
    • IOS官方定义
      • 模态是一种设计手法，它使用一种临时性的模式将用户之前看到的内容与当前看到的内容进行区分，并且需要通过明确的操作才能退出该模式
      • 模态呈现的内容
        • 帮助用户专注于一个独立的任务或一组紧密相关的选项
        • 确保用户收到关键信息，并在必要时采取行动
      • 由此可见，弹层是否为模态弹层可以根据具体的使用场景进行定义。在iOS官方中定义的模态弹层通常包括：Alerts, Activity Views ,Share sheets, and Action Sheets .iOS 13 及后续的系统中将Fullsreen也作为模态弹层进行使用。MD中的Dialogs组件均为模态，而sheets组件不采用模态设计手法。
• II. 弹出层组件的分类与应用
  • 1. 警示型弹框
    • 概述
      • 警示型弹框均采用从页面中间进行弹层的方式，MD和IOS中组件的样式略有不同，但其使用场景和功能相同。都是在重要信息提示、需要用户确认的操作、以及破坏性操作之前进行提示。警示型弹窗会中断用户的任务流程，影响用户体验，因此需注意其使用频率。
    • 使用场景
      • 通常在系统级信息的提示，例如权限的获取、系统通知，需要明确告知用户的信息，以及破坏性操作前使用。
    • 样式
  • 2. 任务型弹层
    • 简单型弹层
      • 定义
        • 常用于在弹层中展示内容，需要用户进行选择的场景，该场景通常只需要用户完成一种任务，比如通过点击的方式，完成信息的选择或分享。
      • 弹层差异
        • iOS中采用从底部向上弹层的方式；安卓平台多使用在页面中间弹层的方式
      • 组件样式
        • 弹层中是否存在操作按钮可根据实际应用场景去确定。通常选择项条目较少或内容简单易于识别时，可不需要【确认】按钮。而在选择项条目较多时或需要用户作短暂的思考才能确认选项时，可增加【确认】按钮，允许用户有修改选项的机会。
        • 弹层中信息的呈现方式又可分为“列表”和“网格”两种，大多种场景下，均可使用列表展示内容，更加符合用户从上到下的阅读习惯；而在分享场景下多通过网格的方式将分享渠道展示出来，增加屏显的内容，同时提高用户查看信息的效率，具体样式可参考上图。
      • 使用场景
        • 简单型弹层多用在信息的筛选、排序和信息确认的场景下使用。且在目前大部分应用中除原生的安卓应用外，大部分应用都采用从底部向上弹层和从顶部向下弹层的方式。
    • 复杂型弹层
      • 定义
        • 复杂型弹层中通常承载的信息量更丰富，包含多种组件，需要用户完成一系列的任务。
      • 组件样式
        • 涉及到信息筛选时，通常采用侧边弹层组件进行展示，且弹层上的信息仅支持垂直滚动查看，不支持水平滚动查看，且通常采用“非模态”的手法，方便用户快速取消当前弹层。在IOS中并无“Sheets:side”组件，但是在iOS系统中，很多APP应用在复杂的筛选场景下也都采用侧边弹层的方式。
        • 全屏弹层会将当前页面中的全部信息遮挡，更方便用户聚焦于当前需要完成的任务，避免用户的注意力被分散。通常采用模态的设计手法，仅当用户触发确认、取消或关闭操作时，弹层才会消失。一般全屏弹层中需要包含标题、操作按钮、内容区域。用户在全屏弹层中需要完成多个任务，因此内容区域中也会包含多个组件。例如”按钮、输入框、标签、开关、列表、日期选择”等。
      • 使用场景
        • 通常用于完成复杂任务的表单信息填写、内容筛选、搜索和内容展示。
    • 根据用户在弹层中完成的任务内容和任务数量划分
  • 3. 气泡框组件
    • 定义
      • 在iOS的官方定义中，气泡框组件应用于iPad应用程序，在iPhone应用程序中，通过以全屏模态视图而非弹出框形式显示信息，来利用所有可用的屏幕空间。气泡框组件更多被用于简单信息的展示与选择。
    • 应用
  • 4. 总结
• III. 如何设计弹出层组件
  • 设计目的
    • 设计侧
      • 规范的组件设计，对内有利于全公司的设计师对组件的使用有统一的认知，明确组件的使用场景，避免误用和错用组件，并且方便新人设计师快速学习和上手，提高设计效率。对外也有利于保证设计上线后的一致性和规范性，方便用户对本公司产品建立统一的心理认知。
    • 技术侧
      • 通用的基础组件，具有可复用性，能够减少重复开发，大大提高开发效率。
    • 组件设计的最终目标可归纳为保持设计的统一性，提升用户体验，同时提高设计和开发的效率。
  • 设计思路
    • 定义
      • 通过精准的话术描写组件的内容与目的
    • 用法
      • 组件包含的内容、出现的位置、信息展示的规则等
    • 构成
      • 通过示意图展示组件包含的具体信息，例如标题、按钮、内容区等
    • 种类
      • 根据一定的规则对组件进行分类
    • 行为与状态
      • 使用组件的整个交互流程与交互逻辑说明；组件的状态说明，例如normal态、click态，disable态，滚动时的页面状态等
  • 移动端弹出层组件
    • 遮罩层
      • 覆盖底部页面上的内容，方便用户聚焦当前弹层上的信息
    • 容器层
      • 承载内容的容器
    • 内容层
      • 容器里的内容，不同区块的内容可单独封装
    • 基于通用性和可复用性原则拆解
  • 设计实战
    • 1. Picker 选择器
      • 定义
        • 用于从一组预设数据中进行选择的控件。
      • 用法
        • （1）选择器通常显示在屏幕底部或弹出窗口中；
        • （2）通常包含2个操作按钮“取消和确定”，按钮名称支持修改；
        • （3）可自定义设置是否显示标题；
        • （4）支持单列选择和多列选择，多列选择一般不超过4列，且多列值之间可配置其级联关系。
      • 构成
        • 标题、按钮、内容（当前选项和其他选项）
      • 种类
        • 根据选项间是否存在级联关系可将其分为2类，普通选择和级联选择。
      • 行为与状态
        • 状态：给出单列选项和多列选项的常态页面以及选项被禁用的状态页面。行为：需要定义完整的组件交互逻辑，从入口->弹层出现->选项查看->选择目标选项->弹层消失的完整逻辑进行说明。
      • 总结
        • 当完成以上全部内容的撰写时，可对本组件开发出的效果进行说明。例如：（1）普通选择：以单列选择示例，默认项为第一个选项；（2）普通选择：以2列选择示例，默认项为每列的第一个选项；（3）多列选择无级联关系：（以日期选择年、月、日示例，3列选择，默认项为当天；（4）多列选择存在级联关系：（以城市选择为例，3列选择，默认项为每列的第一个选项。
    • 2. Filter 筛选器
      • Filter组件是基于公司移动端产品均存在的高频“筛选”场景而总结的场景（业务）组件
      • 场景组件设计注意事项
        • 场景组件在设计时遵循“加法”逻辑，从而提升组件的复用率。
        • 组件内容分区块进行封装，从而增加组件的灵活性。
      • 在上图所示的筛选场景中，单类目和多类目筛选若均为高频的使用场景，那么单类目和多类目筛选组件均可以抽离成组件并进行开发，且多类目筛选可基于单类目筛选组件进行开发。 但是多类目筛选组件是无法覆盖单类目筛选组件的，组件开发不同于设计稿，设计稿可将多个类目删除掉只剩余单个类目，但是组件的代码逻辑不遵循此删除逻辑。在原有组件的代码上修改的开发成本要高于重新开发组件。因此，如果要修改多类目筛选组件的逻辑，不如重新开发出单类目筛选的组件。这也是需要我们牢记的，组件设计需要从“原子组件到复杂组件”，遵循由“简单到复杂”的加法逻辑。
      • 组装
        • 组件开发时通过“group”的形式进行封装，可使组件更加灵活。例如，当业务场景是需要通过“输入框”组件输入筛选条件，只要将Group中的内容改为“输入框组件”，即只需修改该group下的代码即可，筛选器组件的其他逻辑仍然可复用，这就提高了组件的通用性和复用率。
      • 其他细节
        • Filter组件还需要考虑很多设计细节，例如类目名称是否显示为当前筛选项名称、重置的逻辑是什么、确认筛选后页面信息会如何变化、筛选项支持单选还是多选等等。复杂的场景组件通常是由多个原子组件组合而成，因此组件的逻辑也更为复杂，组件设计的整体流程和交互细节也应考虑的更加全面。