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


最小交互的提炼


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


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


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



必要交互


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


比如:



增强交互


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


比如:



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


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


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


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



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


例如:



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


同类交互的可替代性


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


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


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


interface IListViewProps {
  dataSource: Array<Entity>
}


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


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


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


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


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



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


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


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


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


对等交互的裁剪


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


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


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


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



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


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


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


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


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


举例来说:


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


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


第一组:



第二组:



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


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


添加辅助交互


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


输入与选择


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


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



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


使用过滤项


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


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


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


关联关系的快捷编辑


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


比如:


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


与之对应:


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


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


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


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


交互的渐进式优化


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


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



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


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



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


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



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


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



小结


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


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