本文尝试从数据和逻辑的角度，对业务系统中的各种交互作一个归类，简单探索其中一些共性，并以此作为渐进式交互优化的一种依据。

最小交互的提炼

交互的本质是锦上添花，其中包含“锦”和“花”两种要素，二者之中，“锦”是必不可少的部分，而“花”则是为了使得交互更加友好。

那么，“锦”和“花”具体指代什么，应该如何区分呢？

一切业务系统，本质上是对数据的读写，所以，可以从是否影响业务数据的角度，来区分某种是什么类型。

  • 锦：引发业务数据更新，在此称之为必要交互
  • 花：不引发业务数据更新，在此称之为增强交互

必要交互

如果一种交互，它所产生的数据变更，直接影响到当前的提交或汇总结果，则可认为是一种必要交互。

比如：

  • 在表单内的某个输入框中修改文本
  • 改变表单中某个可选列表的选中项
  • 点击确定按钮，提交表单数据
  • 删除列表中的一项

增强交互

如果一种交互，它不会引发当前业务数据的变更，它就是一种增强交互。

比如：

  • 加载列表时，展示的 loading 图形
  • 在弹出选择项的时候，附带的搜索框中搜索过滤选项
  • 在下拉选择中，可以快速新增的按钮及其后续操作

需要注意的是，仅从当前交互是否提交或汇总数据来看，是不精确的，需要一直上溯。比如说：

在下拉选择中，可以快速新增的按钮及其后续操作

这个快捷新增操作是包含数据提交的，但是因为它的上层，其结果改变的是下拉框的可选项，这个地方是一个增强交互，因此，沿着交互树的树枝向根部追溯，发现经过了增强交互，所以，它就是从属于一个整体的增强交互的局部。

因此，经过完善的定义为：

  • 如果一个交互不产生业务数据变更、汇总，或者其上级可以追溯到一个不产生业务数据变更、汇总的交互，则可认为是一个增强交互
  • 否则，是必要交互。

在一套交互体系中，如果去除了一切友好优化，则可以得到满足业务需求的最小交互。一个业务的最小交互，是仅满足基本输入输出的最简形态，在不同的交互体系中，可以通过定义不同数据类型的原子操作形态，从而改变最小交互的默认形态。

例如：

  • 定义 Boolean 类型的原子读写操作为 Switch 组件
  • 定义 Text 类型的原子读写操作为 TextArea 组件

这样，业务的最小交互就是它们的叠加，并去除了非必要的关联。

同类交互的可替代性

基于以上的定义，如果两个交互所处理的数据类型一致，则可认为有一定的互相替代性。

比如说，表达一组实体数据的时候，我们可以约定，最简单的情况下，使用一个表格来表达。

所以它的数据形态就是类似：

  1. interface IListViewProps {
  2.   dataSource: Array<Entity>
  3. }

我们把这个表格称为列表数据的默认交互。

同样是这个数据源，在必要的时候，可以被呈现为数据列表，或者各种图表，比如柱状图，饼状图之类。视图只是数据形态的一种表现方式，所以，数据的查询、筛选、增删，都是独立于其呈现形态的，我们只需给这类视图提供一套协议，就足以使得它们能够无缝接入，可被任意切换，也就实现了交互的可替代性。

这些同样适配列表数据源的的交互，就可以被称为列表数据的可选交互。

推而广之，一切数据形态都可以找到它的默认交互，也可以在特定业务域中定义出一些可选交互来。这些交互集，可以辅助业务设计师/架构师，轻松快速完成业务设计。

可以大致用这样的分类方式来整理原子业务交互：

  • 视图
    • 实体
      • 表单
      • 详情
    • 实体集合
      • 列表
      • 表格
      • 饼图
      • 柱状图
      • 折线图
    • 增强的实体集合
      • 树
        • 组织架构
      • 分组
        • 看板
  • 字段
    • 简单数据
      • 布尔
        • Switch
        • Checkbox
        • RadioGroup
        • Select
      • 整数
      • 浮点数
      • 字符串/长文本
      • 日期
      • 枚举
      • 金额
      • ……
    • 关联关系
      • 一对一
        • 嵌入式表单
      • 多对一
        • Select
        • RadioGroup
      • 一对多
        • 带创建的 List
        • 带创建的表格
      • 多对多
        • 穿梭框
        • 多选下拉框
        • 带选取的表格

基于以上原则划分的交互形态，基本上都是可以同类互换的，将一种形态切换为另外一种，并不会影响业务实质。

比如说，业务上想要表达布尔类型，可以在 Switch、Checkbox、RadioGroup、Select 中任意选取。

另一方面，在某种交互内部，添加一些不影响提交数据的辅助交互，并不会影响其实质，比如，Select 中添加一个用于快速定位的搜索框，它最终提交的仍然是选中的那条记录。

这也符合我们上一节的论述：锦上添花，只是增加了交互的友好性，但是在其业务的实质上，存在最小集。

对等交互的裁剪

需要注意到的是，在很多交互中，会存在对全量元数据适度的裁剪。

比如说，一个实体，有20个字段，在表格视图下，我们查看其中10个，然后在详情视图下查询全部。这时候，表格视图就产生了对于业务实体全量交互的裁剪。

因为侧重性的问题，本文不尝试对交互裁剪作深入探讨，在此探讨一些相关问题。

关联数据的选取和变更操作，都会体现这么一个特质：两类关联关系的典型交互，其操作是孤立的，比如：

  • 多对一或者多对多：在主模型中，选取一条或者多条关联模型数据
  • 一对多：在主模型中，创建一条或者多条关联模型数据

这样的交互虽然逻辑正确，但总是这样的话，可能过于死板，考虑如下业务诉求：

在宠物详情表单中，除了编辑宠物自身信息，选择主人，还能快捷编辑其主人的信息。

换句话说，多对一关系中，在“多”进行编辑的时候，以什么样的交互编辑“一”，是有可能随着业务的不同，有所不同的。

除了拓展之前我们提到的下拉选择，把每个项改成可编辑，还有可能存在其他形态的交互，比如把主人信息展开为一个子表单之类，与主表单一同编辑。

在业务中，每种关联关系都可以去考虑：是否开启以关联关系的两端为主体的交互，还是只开启其中一端。有的时候，不同场景下是可能存在不同的主体语义的。

举例来说：

主人和宠物是一对多关系。

业务设计的时候，可能有如下两组视图：

第一组：

  • 人员管理（仅包含人员基本信息，不含宠物信息）
  • 宠物管理（包含主人信息）
  • 主人和宠物的关联关系管理（以主人为主体）

第二组：

  • 人员管理（包含人员基本信息和宠物信息）
  • 宠物管理（包含主人信息）

这两种设计视图中，前一组出现了两种不同的以人员为主体的交互，只是一种侧重于当前实体，一种侧重于关联关系的表达，而后一组把这两种交互合并在一起了。在实际设计过程中，可能需要根据场景和业务诉求来选择采用哪种方式。

在业务设计的时候，关联关系的两头可以都作为默认交互来生成，然后由业务设计师来裁剪其中一部分，以此达到最佳的业务使用合理性。

添加辅助交互

一般来说，仅靠原子交互自身，只能满足业务特性的最低限度表达，想要实现最低限度的可用性，可能还需要添加一些辅助交互。

输入与选择

最典型的一种交互是日期选择器，它算不算日期形态的最简交互呢？当然不算，因为用一个文本输入框去输入日期，也同样能把这个业务完成，只是体验低一些而已。

通常我们不会把系统可用性的基准定在这么低的位置，所以，我们会：

  • 使用日期选择器，而不是输入日期
  • 使用下拉选择，而不是输入 id

所以，这就是辅助交互的第一个层次：以选代填。

使用过滤项

当我们使用选择来代替填空的时候，就会面临一个问题，在很多场景下，可选项过多。为了收缩可选项的数量，需要增加过滤器。过滤器的形态可以是多样化的，但实质都一样，影响的是可选项的数量。

在不同类型的选择器上，是有机会去定义出一些默认的过滤器的，可以是折叠式，可以是可展开的，搜索结构可以根据使用这些选择器的元数据来生成。

所以，这也就成为了辅助交互的第二个层次：快速选择。

关联关系的快捷编辑

前面我们提到，业务上会存在一些对等关联关系，如果能够在编辑自身数据的时候，快捷编辑所关联的数据，那往往会大幅缩短填写时间。

比如：

为一个人选择宠物的时候，可以允许他在选择过程中，快速新建一个宠物，或者修改已有的宠物。

与之对应：

当选择宠物的时候，发现该宠物尚未创建，先切换到宠物管理界面，新建了宠物之后，再切回来选。

很明显，上面那种交互的效率更高。

我们完全可以为每种关联关系创建一些可选交互，其中包含关联数据的快捷编辑功能。需要注意的是，关联数据的编辑，可能会受到关联关系的一些约束，比如是否可空等等。

这就是辅助交互的第三个层次：关联关系的快捷编辑。

交互的渐进式优化

以上，我们描述了一套可替换的组件化体系，基于这套体系，可以很容易实现交互的渐进式优化。

所谓的渐进式优化，我给它一个形象描述：

  • 10%的代价，得到60%体验
  • 40%的代价，得到75%体验
  • 80%的代价，得到90%体验

也就是说，最开始，仅拥有对业务实体的元数据描述，就已经得到了一个可使用的业务系统了，就好比盖房子，主框架改好的时候，内墙直接贴好了简单实用的墙砖，如果不讲究的话，都是可以用的。

然后，头痛医头，脚痛医脚，哪里不行改哪里：

  • 替换局部交互
  • 编排布局
  • 附加额外的规则

通过这样的步骤，逐步把整个系统变为更专业、准确的形态。

所以，在某个设计体系下，可以逐一约定：

  • 某种数据形态的默认交互是什么
  • 每种数据形态的可选交互有哪些

然后，初始化的时候，给出的都是默认交互，从默认交互的基础上逐步优化到最佳交互。

所以，我们得出了渐进式优化的三个重要路径：

  • 替换：把一种简化交互替换为更能够表达业务的形态
  • 裁剪：从全量业务交互中，裁剪出最适合的形态
  • 附加：在已经能够表达业务的交互上，附加额外的便利操作项

小结

本文初步着眼于业务数据变迁的过程，产生了交互的最小集、可替换性和渐进式优化方面的一些思考，基于这样的思考，是相对比较容易对基础交互进行归类，进而形成一套业务体系的标准交互的。

而整个这套体系，一旦形成，就是它发挥价值的时候。它是业务应用灵活搭建的必经之路，做好了这一步，才能突破下一级阶梯：快速装配。