Replies: 1 comment
-
|
飞叔，我能转载到我的公众号吗 |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
本文尝试从数据和逻辑的角度，对业务系统中的各种交互作一个归类，简单探索其中一些共性，并以此作为渐进式交互优化的一种依据。
最小交互的提炼
交互的本质是锦上添花，其中包含“锦”和“花”两种要素，二者之中，“锦”是必不可少的部分，而“花”则是为了使得交互更加友好。
那么，“锦”和“花”具体指代什么，应该如何区分呢？
一切业务系统，本质上是对数据的读写，所以，可以从是否影响业务数据的角度，来区分某种是什么类型。
必要交互
如果一种交互，它所产生的数据变更，直接影响到当前的提交或汇总结果，则可认为是一种必要交互。
比如：
增强交互
如果一种交互，它不会引发当前业务数据的变更，它就是一种增强交互。
比如：
需要注意的是，仅从当前交互是否提交或汇总数据来看，是不精确的，需要一直上溯。比如说：
这个快捷新增操作是包含数据提交的，但是因为它的上层，其结果改变的是下拉框的可选项，这个地方是一个增强交互，因此，沿着交互树的树枝向根部追溯，发现经过了增强交互，所以，它就是从属于一个整体的增强交互的局部。
因此，经过完善的定义为：
在一套交互体系中，如果去除了一切友好优化，则可以得到满足业务需求的最小交互。一个业务的最小交互，是仅满足基本输入输出的最简形态，在不同的交互体系中，可以通过定义不同数据类型的原子操作形态，从而改变最小交互的默认形态。
例如：
这样，业务的最小交互就是它们的叠加，并去除了非必要的关联。
同类交互的可替代性
基于以上的定义，如果两个交互所处理的数据类型一致，则可认为有一定的互相替代性。
比如说，表达一组实体数据的时候，我们可以约定，最简单的情况下，使用一个表格来表达。
所以它的数据形态就是类似：
我们把这个表格称为列表数据的默认交互。
同样是这个数据源，在必要的时候，可以被呈现为数据列表，或者各种图表，比如柱状图，饼状图之类。视图只是数据形态的一种表现方式，所以，数据的查询、筛选、增删，都是独立于其呈现形态的，我们只需给这类视图提供一套协议，就足以使得它们能够无缝接入，可被任意切换，也就实现了交互的可替代性。
这些同样适配列表数据源的的交互，就可以被称为列表数据的可选交互。
推而广之，一切数据形态都可以找到它的默认交互，也可以在特定业务域中定义出一些可选交互来。这些交互集，可以辅助业务设计师/架构师，轻松快速完成业务设计。
可以大致用这样的分类方式来整理原子业务交互：
基于以上原则划分的交互形态，基本上都是可以同类互换的，将一种形态切换为另外一种，并不会影响业务实质。
比如说，业务上想要表达布尔类型，可以在 Switch、Checkbox、RadioGroup、Select 中任意选取。
另一方面，在某种交互内部，添加一些不影响提交数据的辅助交互，并不会影响其实质，比如，Select 中添加一个用于快速定位的搜索框，它最终提交的仍然是选中的那条记录。
这也符合我们上一节的论述：锦上添花，只是增加了交互的友好性，但是在其业务的实质上，存在最小集。
对等交互的裁剪
需要注意到的是，在很多交互中，会存在对全量元数据适度的裁剪。
比如说，一个实体，有20个字段，在表格视图下，我们查看其中10个，然后在详情视图下查询全部。这时候，表格视图就产生了对于业务实体全量交互的裁剪。
因为侧重性的问题，本文不尝试对交互裁剪作深入探讨，在此探讨一些相关问题。
关联数据的选取和变更操作，都会体现这么一个特质：两类关联关系的典型交互，其操作是孤立的，比如：
这样的交互虽然逻辑正确，但总是这样的话，可能过于死板，考虑如下业务诉求：
在宠物详情表单中，除了编辑宠物自身信息，选择主人，还能快捷编辑其主人的信息。
换句话说，多对一关系中，在“多”进行编辑的时候，以什么样的交互编辑“一”，是有可能随着业务的不同，有所不同的。
除了拓展之前我们提到的下拉选择，把每个项改成可编辑，还有可能存在其他形态的交互，比如把主人信息展开为一个子表单之类，与主表单一同编辑。
在业务中，每种关联关系都可以去考虑：是否开启以关联关系的两端为主体的交互，还是只开启其中一端。有的时候，不同场景下是可能存在不同的主体语义的。
举例来说：
主人和宠物是一对多关系。
业务设计的时候，可能有如下两组视图：
第一组：
第二组：
这两种设计视图中，前一组出现了两种不同的以人员为主体的交互，只是一种侧重于当前实体，一种侧重于关联关系的表达，而后一组把这两种交互合并在一起了。在实际设计过程中，可能需要根据场景和业务诉求来选择采用哪种方式。
在业务设计的时候，关联关系的两头可以都作为默认交互来生成，然后由业务设计师来裁剪其中一部分，以此达到最佳的业务使用合理性。
添加辅助交互
一般来说，仅靠原子交互自身，只能满足业务特性的最低限度表达，想要实现最低限度的可用性，可能还需要添加一些辅助交互。
输入与选择
最典型的一种交互是日期选择器，它算不算日期形态的最简交互呢？当然不算，因为用一个文本输入框去输入日期，也同样能把这个业务完成，只是体验低一些而已。
通常我们不会把系统可用性的基准定在这么低的位置，所以，我们会：
所以，这就是辅助交互的第一个层次：以选代填。
使用过滤项
当我们使用选择来代替填空的时候，就会面临一个问题，在很多场景下，可选项过多。为了收缩可选项的数量，需要增加过滤器。过滤器的形态可以是多样化的，但实质都一样，影响的是可选项的数量.
在不同类型的选择器上，是有机会去定义出一些默认的过滤器的，可以是折叠式，可以是可展开的，搜索结构可以根据使用这些选择器的元数据来生成。
所以，这也就成为了辅助交互的第二个层次：快速选择。
关联关系的快捷编辑
前面我们提到，业务上会存在一些对等关联关系，如果能够在编辑自身数据的时候，快捷编辑所关联的数据，那往往会大幅缩短填写时间。
比如：
为一个人选择宠物的时候，可以允许他在选择过程中，快速新建一个宠物，或者修改已有的宠物。
与之对应：
当选择宠物的时候，发现该宠物尚未创建，先切换到宠物管理界面，新建了宠物之后，再切回来选。
很明显，上面那种交互的效率更高。
我们完全可以为每种关联关系创建一些可选交互，其中包含关联数据的快捷编辑功能。需要注意的是，关联数据的编辑，可能会受到关联关系的一些约束，比如是否可空等等。
这就是辅助交互的第三个层次：关联关系的快捷编辑。
交互的渐进式优化
以上，我们描述了一套可替换的组件化体系，基于这套体系，可以很容易实现交互的渐进式优化。
所谓的渐进式优化，我给它一个形象描述：
也就是说，最开始，仅拥有对业务实体的元数据描述，就已经得到了一个可使用的业务系统了，就好比盖房子，主框架改好的时候，内墙直接贴好了简单实用的墙砖，如果不讲究的话，都是可以用的。
然后，头痛医头，脚痛医脚，哪里不行改哪里：
通过这样的步骤，逐步把整个系统变为更专业、准确的形态。
所以，在某个设计体系下，可以逐一约定：
然后，初始化的时候，给出的都是默认交互，从默认交互的基础上逐步优化到最佳交互。
所以，我们得出了渐进式优化的三个重要路径：
小结
本文初步着眼于业务数据变迁的过程，产生了交互的最小集、可替换性和渐进式优化方面的一些思考，基于这样的思考，是相对比较容易对基础交互进行归类，进而形成一套业务体系的标准交互的。
而整个这套体系，一旦形成，就是它发挥价值的时候。它是业务应用灵活搭建的必经之路，做好了这一步，才能突破下一级阶梯：快速装配。
Beta Was this translation helpful? Give feedback.
All reactions