在业务系统中,设置查询条件是一个非常常见的场景,设置查询条件,根据查询条件生成sql,对数据进行过滤。
我们从这个简单的场景出发,当我们设计这个场景的时候,会发生什么事情。
这是一个最简单的实现,符合我们直观的认识。过滤项和它可输入的参数都已经规定。
1.查询条件以and连接,不支持查询出符合条件A或者条件B的过滤方式。
2.每个条件的过滤方式已经固定,不能在查询时修改。
3.所有查询条件都平铺在界面上,即使我们不需要他也会占用一大部分空间。
在简单实现的基础上,我们可以进行一些优化。查询条件和过滤方式均可以选择,只添加要过滤的条件。
同时加入了条件组的概念,组间用or连接,组内用and连接。
这样我们就解决了简单实现的三个不足。
这个实现已经可以满足所有复杂条件的生成。但是并不直观。
考虑我们需要一个
conditionA and ( conditionB or conditionC) 的条件。
这时候我们需要把它转换成
(conditionA and conditionB) or (conditionA and conditionC)
然后才能用上面的界面选出来。
如果我们需要的条件是
conditionA and ( conditionB or (conditionC or (conditionD and conditionE)))
那么我们这个实现就显的不那么友好了(⊙o⊙)?
带嵌套分组的实现我在常用的ui组件库中没有找到,所以自己简单实现了一个。
支持自定义字段及字段类型。组内的条件优先运算,与括号等效。
现在我们再来选出conditionA and ( conditionB or (conditionC or (conditionD and conditionE))) 这个条件,就显得方便多了。
选出一个更加复杂的条件。幸好准备了SQL生成的功能,从SQL上面看更清爽一些。
github地址:https://github.com/4cos90/condition/tree/master
当我写到这里的时候,一切似乎都已经搞定了,有了可选的条件,可以自由的设定条件的关联关系,可以支持嵌套,可以支持和sql相互转换。我们有了一个功能完备的组件。
但是我们日常使用中,还是第一种最简单的最常见。第二种在一些复杂的场景下偶尔会见到。
第三种看起来功能最全,什么情况都考虑到了,但是我没有见到有使用这种设计的。
我们自然会得到一个问题。我们需要这样完备的功能吗?
随着功能的增加,学习成本也会随之增加。使用起来也不再直观,不再好用。
设计是做减法。
在完备的功能中,选出我们会使用到的一部分,是整个设计过程中始终要考虑的问题。
选择的依据无外乎两点。我们的用户是谁,我们在什么场景下使用。由此向下推理,用户在这个场景下的行为,用户想要达成的目的。而我们真正选取出来实现的部分,只需要刚好满足让用户达成目的即可。而超出目的本身的其他部分,只是徒增了使用时的学习成本和交互操作时的复杂性。
我们从最简单的场景出发,逐渐加入新功能弥补不足。加了几回似乎还是最开始最简单的实现更普适。仿佛出发转了一圈又回到了原点。
但我们和出发时已大不相同。
我们最普遍看到的场景往往也是简单的场景,面对的用户也往往是非专业的用户。他们的目标往往是短暂的在页面中停留,快速的得到结果。业务逻辑不复杂,边界也小。我们在这个小边界里固定条件,减少用户的选择范围,是好事。
在逐步考虑复杂场景时,简单设计的不足才会被暴露。这时候我们再谨慎的添加新的功能,满足更复杂的需求。
我们坐在这里空想,就已经实现了一个用户并不真正需要的组件。更何况在面对真正的用户提出各自需求时?
唯有时刻记住用户才是实际使用产品的人,不要用自己的视角先入为主地替用户创造需求。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。