美文网首页
单表筛选条件设计思考

单表筛选条件设计思考

作者: 纸纹 | 来源:发表于2020-03-19 18:20 被阅读0次

    单表筛选条件设计思考

    背景

    最近在做一个系统的筛选条件,主要是解决目前系统中比较复杂一些操作问题。筛选最终要实现的就是 针对某些属性,选出满足条件的属性值。

    筛选可以分很多类型,在生活中最容易接触到的场景就是购物,比如我们在逛淘宝可以选择关键词、品类、价格区间、好评度、销量等等。

    而在我们所涉及的系统中,由于是强业务相关,主要就是针对单表筛选,可以理解为一张Excel表作筛选条件。比如,针对不同的数据类型: 文本、布尔、枚举、数值等进行筛选,且可能伴随着【与/或】关系这种复杂一些的逻辑。

    用户筛选的核心目的: 快速找到自己所关注部分的数据,进行地理可视化。

    在实际的业务场景中,可能是:

    1. 数据分析人员有一份全国地市的GDP分布数据,他想要找出华东地区GDP大于全国平均值的城市制作一份城市分布图。
    2. 规划分析师有正在研究粤港澳大湾区的经济圈,他想要找出大湾区城市人口在200-500W,且GDP排名在湾区内前十的城市。

    现状

    现有的筛选条件倒不是不能用,如果有些数据分析背景,可能就筛选的能力来说还更强一点。因为最初的版本就是这样的,我们的工程师直接放了一个SQL的where子句输入框上去(不懂的可以了解一下SQL)。


    现有

    这种高级用户用起来当然觉得更好使一些,甚至他们觉得这种更强大。但实际的用户反馈来说,这种筛选框经常输错,更多的是不知道怎么用。大多数用户的想法是能让我选的,就不要输入。

    需求分析

    针对能选就不输入这种情况,就需要考虑用户上传的数据,针对不同的字段类型进行区分,包括文本、数值、枚举、布尔、日期等。然后为每个不同的类型,设置筛选操作。另外还要支持有多个条件,既要这样又要那样的需求,以及针对数据排序取TOP值。

    竞品参考

    由于有行业背景的用户占大多数,所以参考一下传统的软件是有必要的。传统软件的筛选都是构建查询条件的表达式,其实就是where子句的操作版。他们一般就是三段式,上方是候选的属性(也可以采集字段值),中间是可选的操作符,下方是构建的表达式。


    QGIS ArcGIS

    优点:已经有了可视化的操作选择,并且可以构造一连串复杂的筛选条件。
    缺点:对用户来说还是不够简单,学习成本较高。不同的字段类型适用不同的操作符,在创建查询条件的时候还是会对用户造成困扰。

    方案设计

    拆解

    针对拆解出文本、数值、枚举、布尔、日期类型、条件、排序等可能操作,让多余的选择变为有限的选择。列出所有的接触点。

    • 文本
      针对文本的操作,主要包括:包含、不包含、等于、不等于。用户可以输入文本。
    • 数值
      针对数值的操作,主要包括:大于、小于、大于等于、小于等于、等于、不等于、区间之内、区间之外。用户可以输入数字。
    • 枚举
      针对枚举类型,主要包括:等于、不等于。用户可以选择枚举值,可多选。
    • 布尔
      针对布尔类型,主要包括: 是、否。用户可以选择是否。
    • 时间
      时间为特殊的数值类型,主要包括大于、小于、大于等于、小于等于、等于、不等于、区间之内、区间之外。用户可以按日历选择。
    • 排序
      针对字段排序,主要包括:正序、逆序。用户可以输入数值,取筛选列表的前多少行。
    • 逻辑规则
      逻辑规则为条件之间的【与/或】关系,通俗点说就是条件需要全部满足还是只要部分满足就能查到。

    用户行为设计

    针对拆解出的不同类型的操作,再做用户的体验路径。


    用户流程

    页面效果

    最终效果

    总结思考

    需不需要分组?

    分组的意思是针对筛选条件组合,可能这两个条件是与关系,而又与另一个条件是或关系。用一个小学数学符号表示比较好理解一下。(A ∩ B)∪ C

    这种情况有考虑,但是一般来看使用的频率并不高,暂时也没在用户的业务场景中遇到,所以暂时没有做那么复杂。

    适用范围?

    此类筛选针对用户的数据进行单表筛选,这种更偏底层数据表一些。用户的数据不固定,主要看平台都支持哪些字段类型,然后结合实际的业务拆分操作。

    相关文章

      网友评论

          本文标题:单表筛选条件设计思考

          本文链接:https://www.haomeiwen.com/subject/bbolyhtx.html