写在最前
在我心里，表格是个很神奇的玩意。初始看来简简单单、条条框框几笔，但真要设计实现起来，从信息的展示、操作的体验、场景的适用，需要注意很多细节。
工作一年多的时间里，从前端写到后台，对表格的需求量一直很大，这阵子准备重写我们后台的表格组件，说说自己的设计思路，给它来一波变形记~
变形前原貌
这次的变形记主角是用于后台的一款表格组件，供操作人员来查看筛选数据。
它主要分为上部的查询条件区域、中部的列表区域以及底部的分页区域，大致是长下面这样子的（为了保护当事人，我为它打上了部分马赛克嘻嘻）。
在先前的使用过程中，我首先觉得这个组件存在两个直观缺陷。
无用信息篇幅过大
查询条件区域中的各个条件没有细分归类，粗暴地将需要的所有条件选项直接堆砌。而现实场景中一些选项不光不常用到，有时还导致该区域占用面积大，直接影响到下面列表的显示区域。列表展现冗杂
列表区域展现形式和查询区域类似，字段过多却不常用，占用篇幅过大。
变形前的思考
既然要变形，那当然是首先要改正原来的缺陷。不过只以查缺补漏的心态设计的话应该是不够的，顺便想了想，用户到底想要一个什么样的表格组件。
结合自身想法和用户平日反馈，总结了两个小目标。
- 高效的搜索
- 清晰的展示
形象设计
写这个段落标题的时候，突然觉得自己有种理发师的既视感，那就开始为客户构想一下新形象吧。
高效搜索
我将查询区域简化为一个搜索输入框+一个筛选按钮。
搜索输入框主要包含以下特征。
支持多字段模糊查询
用户可在输入框中输入不同的字段相关信息进行搜索，而不是像以往那样每个字段对应一个输入框。达成由多化一的效果，增强了搜索的功能力度，同时节省了查询区域的占用面积。外观遵循常规设计
该搜索框与业界的常规设计保持一致，将搜索按钮以图标的形式放在输入框内部，在外观上避免与右侧筛选按钮重复，更加美观简洁。此种常规设计也保证了用户的直接理解。除了点击搜索图标外，也支持响应回车键搜索。提供placeholder
从产品设计上来说，输入框并不需要支持记录所有字段的搜索。用户最常用的名称/ID等字段已经能覆盖绝大多数搜索需求，其他需要且适合通过输入搜索的字段，在实际场景中并不多。因此在输入框内给用户提供可搜索的字段提示，在不影响用户体验的情况下，也从技术开发层面有效限制了字段。
筛选按钮看似孤零零一个人杵在那，实体部分其实会位于窗口右侧。
用户点击筛选按钮时，筛选窗口会从浏览器右侧弹出。其中包含上方的操作按钮区与下方的条件筛选区。
操作按钮在窗口采用固定布局，即使筛选窗口上下滚动时，按钮都固定在窗口，方便用户随时可以操作。
而筛选条件采用简单的表单部件展现筛选项。
之前因为过多查询条件占了太多地方，尤其在小窗口下，列表区域容易被挤成很小一道地方，常被操作人员吐槽。当时最直接的方案是如下图加了一个收缩功能，可以在不需要的时候将查询区域暂时最小化，从纵向上减少了占用面积。
然而之所以决定用右侧这种方式，首先是因为当查询区域没有最小化时，下方的列表区域还是会压榨下方列表区域的生存空间。其次是因为对于表格来说，重要字段一般位于列表前面几列，用户遵循了从左到右的查看模式。因此窗口从右侧弹出即使遮盖了部分列表内容，也不会造成太大的影响。
这个方式实际上模仿了淘宝的交互，在这个人人都是剁手党的时代，这种方式也十分符合大众的使用习惯。但不同点在于淘宝的重置和完成按钮位于页面下方，更符合移动端的使用方式，而此款组件往往用在PC端，更适合将按钮放在上方。
清晰展示
清晰展示主要是体现在列表区域。
针对该区域字段过多的问题，最简单的方法是直接不展示不重要的字段。这个方法看似轻易解决了问题，然而现实场景中，操作人员某时又需要查看所谓的不重要字段，这就产生了矛盾。于是我采用了下面这种方式。
这里的关键在于每行数据前面的">"按钮，它用于展开每行数据的详细信息。列表主体只展示必要字段，其余字段默认隐藏，按下">"时才显示给用户，解决了上文提出的矛盾点。
这个灵感来源于Elementui，个人觉得十分受用^ o ^
其他
在整个过程中，实际上我还是会考虑一些技术因素。
比如多字段模糊搜索是不是会影响搜索效率，又比如因为这实际上是一个组件的设计，采用的表单部件实际上只会是常用固定的几种，以方便代码配置。
最后还有一个分页，基本整体就是下面的形式（直接看图吧，小话痨感觉快写不动了T^T）。
写在最后
细细想来，之所以后台的表格组件做得粗糙，主要原因应该是后台产品基本面对的是企业内部，相比于2C的产品，对用户体验的注重程度上会偏低。
在开发过程中，也有对表格组件做过一两次优化，但之前更多停留在技术层面。因为本身是技术，还是容易受到技术思维的局限。另外也使用原先表格组件很长时间了，比较难跳出原来的模式。希望之后自己能通过学习和自我意识，在这方面逐步提高。
初次写这种产品相关的文章，诸多纰漏，欢迎大家来无情指正~~~（终于写完啦，溜了溜了）
