交互的本源 —— 对渐进式交互优化路径的初步探索

@xufei 2020-03-31 14:16:02发表于 xufei/blog

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

最小交互的提炼

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

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

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

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

必要交互

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

比如:

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

增强交互

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

比如:

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

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

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

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

因此,经过完善的定义为:

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

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

例如:

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

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

同类交互的可替代性

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

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

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

interface IListViewProps {
  dataSource: Array<Entity>
}

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

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

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

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

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

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

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

比如说,业务上想要表达布尔类型,可以在 Switch、Checkbox、RadioGroup、Select 中任意选取。
另一方面,在某种交互内部,添加一些不影响提交数据的辅助交互,并不会影响其实质,比如,Select 中添加一个用于快速定位的搜索框,它最终提交的仍然是选中的那条记录。

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

对等交互的裁剪

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

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

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

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

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

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

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

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

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

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

举例来说:

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

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

第一组:

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

第二组:

  • 人员管理(包含人员基本信息和宠物信息)
  • 宠物管理(包含主人信息)

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

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

添加辅助交互

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

输入与选择

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

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

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

所以,这就是辅助交互的第一个层次:以选代填

使用过滤项

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

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

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

关联关系的快捷编辑

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

比如:

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

与之对应:

当选择宠物的时候,发现该宠物尚未创建,先切换到宠物管理界面,新建了宠物之后,再切回来选。
很明显,上面那种交互的效率更高。

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

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

交互的渐进式优化

以上,我们描述了一套可替换的组件化体系,基于这套体系,可以很容易实现交互的渐进式优化。
所谓的渐进式优化,我给它一个形象描述:

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

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

然后,头痛医头,脚痛医脚,哪里不行改哪里:

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

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

所以,在某个设计体系下,可以逐一约定:

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

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

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

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

小结

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

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