表格是B端产品中出现最高频的模块之一，我们认为良好呈现信息的表格应当做到疏密适度、高效扫视、精简克制。
前言
表格作为组织整理数据的手段，可以有效的向用户展示数据信息，是B端产品中出现最高频的模块之一。
下图为典型的B端表格示例：
用户主要通过表格浏览获取信息、对数据进行筛选、排序以及相关业务处理等更多复杂操作、对比数据的差异与变化（关联和区别）。好的表格信息展示设计，应当是能够辅助用户高效便捷的实现以上场景中的诉求。
今天我们就来讨论表格设计中一个重要的问题——【应该如何考虑表格信息展示】。首先抛出结论，我们认为良好呈现信息的表格应当做到疏密适度、高效扫视、精简克制。
///
一、疏密适度
常见的表格信息包含文本、标签、状态样式、数值统计图表、关键信息Icon等。表格单元格是信息填充的基本单元，行高和列宽的定义决定了表格信息的疏密程度，进而决定了表格给用户的直观感受，因而下面分别从行高和列宽两个方向来探讨表格信息展示如何疏密适度。
1、定义合理的表格行高
a、行高模数设定
在具体设定表格行高时，由于表格中以文字信息为主，我认为可以参考文字排版的常用做法，将整个表格的行高分成文字行高、文字与分割线间距离，即上下间距两部分来考虑。文字行高可以设定为字号的1.2~1.8倍，文字与分割线间距离可以设定为字号的1~1.5倍。分为这样的两部分也比较符合开发同学写代码时的习惯（多行行高同理去设定）。
根据用户场景的不同，来选择模数倍数，需保证系统内使用统一的模数。比如，针对用户快速浏览获取大量数据场景时，可以选择1.2倍作为模数，列表更为紧凑，同样扫视范围内，可获取更多信息。
b、为小屏幕考虑一屏显示的行数
表格行高决定屏幕内能呈现的行数，即用户在一屏内能获取信息的数量，主要影响用户纵向对比数据的效率。对于1920*1020（包含该分辨率）以上的大屏用户，对于一屏显示行数的感知不强，但对于1366×768、1280*720等这类小屏，显示行数有限，用户进行纵向数据对比的效率就会有所降低。在设计前，应当充分了解目标用户的行为诉求，了解目标用户设备屏幕分辨率的占比分布情况，有针对性的设置行高。
c、用户自定义行高的场景
B端产品的特点之一是通用化，覆盖用户角色多样。然而用户个体对于表格信息呈现密度的诉求经常是有所差异的。比如个人视力的原因，有些用户喜欢表格行高值大一些，看起来舒适透气，便于阅读。而有些平台用户由于很熟悉线下excel表格模式，希望线上的表格也尽可能像excel那样紧凑，以便他们在一屏内看到更多的数据，进行对比，提升工作效率。产品为了让不同用户都能获得较好的体验，可以考虑把表格疏密度的设置开放给用户，建议不是完全开放给用户去调整尺寸，而是给出一定阶梯度的快速选项，例如舒适、标准、紧凑三种高度来满足用户需求。
例如，Gmail提供默认/标准/紧凑三种表格密度设置，如图：
2、灵活扩展的横向空间
通过对表格固定位置与列宽的调整，扩大表格数据空间，使信息不局促，空间更透气，保证横向扫视易读性。
a、列宽极限值设定
设计师需要根据表格承载内容定义表格的列宽，应包含最大/最小/默认列宽的定义以及使用规则。
我推荐的一个规则是：
规则1：当相对列少【浏览器宽度-页面其他模块 > 全部列的默认宽度和】，则各个列自动等比拉伸，撑满屏幕；
规则2：当相对列多【浏览器宽度-页面其他模块 < 全部列的默认宽度和】，则出横向滚动条，每列宽度为默认宽。
另外需注意最小值设定时应避免信息展示出现【对联式表格】。对联式表格最大的问题在于，一屏内展示的行数有限，当用户纵向对比数据时，需往复滚动多次，记忆压力大；横向扫视时，阅读视线不能一直保持左右横向预览，而是不停上下左右切换，使用体验不佳。
b、横向『偷取』屏幕外空间、行高模数设定
当压缩列宽也无法在有限空间内展示大量的数据指标列时，我们可以借助横向滚动来『偷取』屏幕外更多空间。横向滚动需用户拖动滚动条进行浏览，有一定操作成本，所以要结合业务实际情况选用是否利用屏幕外横向空间。
随着行和列的增加，用户的瞬时记忆会达到极限，超过“7±2原则”的范围，用户需要依靠辅助信息去阅读表格内的数据，防止遗忘某列数据的意义。因而当表格数据列较多横向滚动时，建议为用户固定重要信息列，如标题列、操作列。同时用户浏览表格时是符合F型扫视原则的，建议固定列显示在表格左侧，方便用户从左至右浏览数据、从上至下对比数据时能够清晰定位当前所浏览数据的主体是什么，同时可根据需要快速发起操作。
同理，用户拖拽纵向滚动条来阅读数据时，可固定表格的表头，帮助用户在阅读过程中清晰知晓单元格数据的意义。
c、用户自定义展示信息
针对需展示大量数据的情景，我们除了【偷取】屏幕外空间外，可以根据B端产品提供的数据表格是覆盖全部用户角色的全量数据的特点，让不同用户角色来自定义想要浏览的信息，从而提升表格的可读性。下图为百度信息流推广平台的自定义列功能，用户可根据需要选择展示的数据列，系统将在用户完成选择后，主动帮用户保存自定义内容，下次登录后，表格依然按照用户定义的数据来展示。
///
二、高效扫视
无论是在表格中要明确的定位数据，还是顺序阅读，高效扫视都是B端用户一个很重要的诉求，我们在设计表格时可尝试一些有效手段提升用户浏览获取信息的效率。
1、合理的对齐方式
数据信息本身包含多种格式，可遵守一个基本原则即文字左对齐，符合从左到右的阅读习惯；数据信息右对齐，方便数据大小的直观对比。
具体对齐方式可参考我们建议的方式：
文本字段：可点击字段、普通文本类、数字、字母等，长短参差不齐，左对齐；
格式化字段：日期、时间、部分枚举类等，字符数一致且较短的，左对齐。
数据字段：金额、数据、百分比。带小数点等数据，方便对比为主，右对齐。
2、去除视觉杂音，强调对比关系
a、正确使用分割线，实现对表格行与列的强调
横向分割线可强调行内信息的连续性。垂直分割线在缩减元素之间的距离后也能区分不同元素，更好的强调纵向数据对比。但只要遵循良好的对齐方式，通常不展示纵向分割线，避免信息干扰。因而表格中通常仅使用横向分割线和底色分割，提升表格阅读效率。
b、斑马线作用有限
斑马线即隔行（列）变色。它能让行（列）间界限更为明显，但由于与分割线的作用类似，起到的作用有限，可针对不同场景酌情考虑是否使用。比如针对不同类型的数据（如总和、平均值）使用不同底色来区分，可以更突出强调该数据。要注意的是，隔行（列）换色的两种颜色不能反差过大，否则看来太“跳跃”。
对同一类数据而言，分割线就已经能够明显区隔，所以可不使用斑马线，但需要给出单行的悬浮状态，强化横向导视，避免出现列数过多引起数据错行的问题。
3、突显重要内容的视觉重量
前面我们提到表格呈现的数据信息除文本外，还有其它一些可视化数据。可视化一方面提升了列表视觉表现力，增加差异化，另一方面让内容更加突出，提升阅读效率。例如：数据列中数据异常时，最好可以醒目的形式突显，让用户一进入页面就能快速注意到异常状况。
///
三、精简克制
体验好的表格一定是克制的，克制应表现在信息的适度隐藏以及内容折行与截断展示原则。
1、适度隐藏信息
a、隐藏低频操作
当表头需要承载排序、表头筛选、提示等功能时，不建议一股脑的将所有功能展示出来。用户对表头的诉求是定位数据指标﹥执行操作的，因此可根据具体业务定义展示哪些操作，将其它操作隐藏，有需求时用户主动触发再展示。比如，百度搜索推广平台的推广管理页面提供了全局筛选，所以表头筛选对于用户而言是相对低频的操作，我们选择隐藏表头筛选的图标，当用户鼠标HOVER表头单元格时再展示。
对于表格行内的操作我们也应当进行优先级排序，为用户专门设置操作列展示高频核心的操作，其它相对低频的次要操作可隐藏在相关数据单元格中，用户有诉求时hover对应单元格即可快速发起操作。
b、隐藏辅助信息
表格中的有些数据指标是综合纬度的，当用户关注点定位于该指标时，需要通过细分数据来理解、分析。指标的细分纬度信息虽能起到辅助用户更好理解数据指标的作用，但如果全部拿出来在表格列展示，会让表格变得臃肿不易读，此时可以考虑采取一定设计手段去隐藏这些信息，把触发展示的自由度交给用户，也更符合用户逐级查看的场景。例如，百度搜索推广平台中关键词列表中，质量度指标是由多条数据共同决定的，我们采用了将细分指标聚合在气泡卡片中，当用户HOVER质量度得分数据时展示出来。
再比如，有父子层级关系的数据，可以通过父子折叠表格将子信息默认隐藏，用户根据需要，去展开查看详细的子信息。
2、设定折行与截断规则
B 端业务的数据信息复杂多样，信息内容的长度高度是多样不可控的，很多内容会超出我们限定的最大列宽，最大列高，我们应当给出折行与截断原则去约束内容的展示，而非总是为具体情况而做特殊设计，破坏体验的一致性。
截断折行原则设定时要细分，不能简单粗暴的一刀切，比如一行截断这种，如日期、时间等固定格式内容，拖动列宽后文字应折行而非截断展示，避免影响用户误读。再比如很多业务实体标题字段是格式化的，即标题前面部分可能都是一致的，这时候如果简单的截断，用户就需要逐一Hover才能找到定位到要找的数据。因而折行与截断原则，我们建议是给出三种：单行截断、双行截断以及自适应截断，根据具体业务情景选择。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码ben_lanlan，报下信息，会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码ben_lanlan，报下信息，会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
总的来说，所谓的感知性模式就是物体或者物件的一种外在的呈现而给人的感觉或者感受。例如同样的一个电脑桌上都有电脑、鼠标、或者其他的物件摆设，但根据不同人的使用给人的感觉是完全不同的，或是凌乱、或是整洁、或是简约，而更直观的差异可能来源于这些物件的样式、材料、颜色、纹理的不同而传递出来的视觉感知，
如果沿用到互联网方面的设计，那么感知性模式的例子可能包括：文字信息、版式、配色、布局、插图、图标、形状纹理、间距、交互或者动画等等，这些都作为具体方式来表达感知性设计。
说到这里，你可能会认为感知性设计是一个纯粹的外在视觉表现，但想要完全的得到一些成效，更多需要把这个事情融入到品牌的核心中，随着产品的发展而发展，进而在众多的同类此产品中脱颖而出。
案例一：微信
微信作为一个超过十亿用户的产品，随着版本的不断迭代，功能也越来越强大，因此从产品体验上来说也可能会给人一种臃肿的感受。但微信整体的感知性模式的设计是非常清晰的，从桌面 APP 的 logo，再到内页呈现的图标、颜色、按钮样式、交互反馈等等的设计都是统一性很好的设计。
案例二：Instagram
Instagram 作为全球热度最高的图片分享社区，自始自终都有着非常明显的感知性，整体 APP 的简洁性设计让用户更加专注于内容本身，似有似无的品牌蓝色似乎已经牢牢融入了用户的大脑中，这种感知性无需被刻意放大，但就在潜移默化中用户就能感受到。
案例三：抖音
作为目前国内最热的短视频平台，抖音的感知性模式已经深入的印在用户的脑里，我认为抖音主要在以下三个方面让用户记住了 TA：1.品牌属性，抖音的品牌属性就是用最简单的方式让用户记住了 ta，通过 APP图标、闪屏、发起按钮的图形及品牌色的串联；2.内容属性，具有自己平台气质的内容特性，抖音在最早期主打的“潮酷”类的视频让它跟快手做了明确的区分；3.体验属性，大胆的全屏滑动视频交互很好的结合了手机的体验方式。
在同一个领域中的产品，在功能上大多会具有一定的趋同性，而由于这几年的扁平化风格盛行，更把产品之间的类同性推向极致。因此更需要通过感知性模式的设计来进行区分，这种区分不仅仅只是视觉上的差异，更多是来自于产品者对于自己产品方向的把控。
书中提到 Spotify 的例子，Spotify 给人感觉是温暖的、私人的，虽然月活跃量已经超过一亿，但给用户的感受仍然是独特的，除了功能之外，主要在于整体的图形样式、颜色搭配（黑绿的品牌色比例把控）、交互中微妙而平静的感觉，以及排版上传递出来的感受。
从上面这个案例来说，基础体验是用户值得参与的一个重要环节，但感知性模式的设计更多是来源于产品者想要给用户传递什么样的品牌性格或品牌核心，Spotify 的静谧性及沉浸式体验，这是 Spotify 设计师想要传递出来的品牌核心
感性性模式的品牌传递主要是通过界面或者运营调性来让用户得到感知，并且让人记住。在界面上想要让用户记住我们的产品，更多的是需要思考三个关键点：设计的独特性；设计的辨识性；设计的区分度。
设计的独特性
设计的独特性往往是通过我们界面的排版、图标、图像、交互体验方式、交互措辞等等一系列的内容来奠定。这些内容我们常常可以在国外的软件中看到很多不错的案例。
还是以 Instagram 作为案例来说，ins 风的极简设计是一种贯彻始终的独特性存在，除了设计界面本身的研究之外，还在内容上下足了功夫。以照片浏览来说，始终坚持大图的体验方式，保证一屏内的沉浸度，而非为了效率，这与 Instagram 一直具有较高的照片质量密不可分。
设计的辨识性
辨识性的可打磨方式有很多种，以图标作为一个基础的案例来说，我们在设计图标的时候是否有结合整体产品的性格去思考并且设计，并且深入打磨。简单的区分，我们可以从风格（例如：简洁的、有趣的、硬朗的、柔软的等等），更深入的内容就是需要思考如何传递品牌感，以及将图形与品牌理念、产品性格进行结合，通过设计贯彻品牌辨识性。
以 YouTube 这个 APP 的图标作为案例，设计师在设计时更多是希望表达整体 APP 设计的简洁性，弱化图形对于内容的影响，因此在整体坚持了三个核心关键点：简约、细线、普识。
设计的区分度
在目前趋同性的主潮流之下，如何把握好产品设计的区分度变得尤为关键，也就是说，当用户在看我们产品的时候会不会乍一眼认为是另一个产品。区分度的把握往往来源于品牌对于颜色的选择，我们在定义色调之前需要对主流竞品做一个分析，从中找出属于我们的区分度，并且尽量避免重合性。
以现在流行的电商 APP 为案例，很大电商平台的设计大多类似，在品牌色的选择上则尤为重要，因此需要尽量避免具有耦合性。
我们在产品设计中想要把所有的模块或者组件做得一模一样几乎是不可能的，但我们可以利用感知性模式的设计进行内容模块的渗透，让用户对于整体的感受感知是一致的。
以 material design 的设计系统为案例，他所确定的是一个规则，而并不是任何的模块或者任何的图标都是一样的、无差别的，如果都完全长得一样会让设计变得单调、无差异性，通过设计准则来限定整体的图形风格，应用在不同的位置让用户从视觉角度感知到风格的一致性，这样也可以让整体的体验更连贯。
富有表现力
为了突出 Material Theming 必须提供的功能，每个 Material 研究都表达了一个不同的品牌。
各种各样的
为确保 material 主题化和组件满足尽可能多的产品需求，material 研究代表了不同类型的产品。
基于现实
为了尽可能地复制真实产品，每项研究都会识别用户、显示功能用户流并应用现实世界的限制。
我们在日常设计功能性模块更多的是考虑到用户对于产品的体验感受，而感知性模块则是我们想要用户在这里获得什么品牌感知，通过品牌结合视觉设计系统给用户带来产品独特的性格及个性化氛围。
对于探索感知性设计的方法也有很多，目前比较流行的技巧主要有：情绪板、样式叠片、元素拼贴。无论是哪种方式，都没有唯一的答案，更多是利用这些方法在不断的尝试中探索到属于自我品牌的感知。
情绪板
情绪板是一种较为轻量的风格探索方法，在这个过程中往往不需要花费过多的精力，我们需要做的就是把统一或者接近类型的图片进行重新整合，得出我们想要表达的视觉感受即可。
情绪版属于比较前期的视觉品牌调性探索，在整体的颜色、排版上也都可以利用情绪板来获得初步的答案，如果想要再往深一步，可能则需要样式叠片的方式。
样式叠片
给予情绪板获得的大致品牌方向之后，便可以利用样式叠片的方式来进行更精细化的探究，我们可以用一种或多种不同的样式叠片来表达，但是希望在截取这些内容的时候要记得保持控件、组件、颜色、字体等等内容的一致性，避免差别性较大，形成不了统一的视觉系统。
元素拼贴
从书中讲到的大体概念是：将界面元素等内容拼贴在一起，从而达到设计稿初稿的雏形感受。这个方法可以比较敏捷的对需求方进行试探，但相比上面 2 种方法需要花费更多的时间及精力，同时这个方法出来的内容也比较偏向高保真。
从表面上来看，这三种方法似乎都可以帮助我们更好的进行设计，没有太大的差异化，不过从本质上来看，这三个方法影响的是我们设计初期输出的保真程度，从情绪版到样式叠片再到元素拼贴似乎是一个越来越保真的方式，我们可以选择其中一种，或者 2 种结合来进行表现。
过多的个性化设计，会削弱整体的品牌感，同样，如果设计的内容需要全部都一模一样的规范，也会扼杀设计的品牌感的创造性。因此，在感知性设计的概念下，一致性设计不是一味的复用，不求变通，而是通过整体统一的理念，允许个性化设计的存在，这样既满足部分模块的独特视觉表现又并不影响品牌传递。
举个例子
例如外面在设计一个完整的 APP 时，我们已经规范好了大体的基础视觉规范，在不影响这个规范的前提下，我们针对部分模块，例如福利类、游戏类，这种比较偏运营的设计界面，我们可以考虑有更丰富的颜色、图形等视觉表现，但前提在于是否符合基础规范的设定，如果符合那我们完全可以对这些类型进行个性化设计。
如果没有打破常规的设计方式，固化的追求一致性的设计，那么它就会变得普通、僵化，感知性设计的存在就是让我们在允许的范围内追求更不一样的设计，鼓励设计师积极探索更多的可能性，好的设计体系既能体现品牌的一致性也能表达出创造性。
由于感知性模式的相关设计，容易被当作只是样式或者主题化皮肤设计，很多人会认为这方面的设计比优化交互流程更容易些。在这种状况下，临时的业务经常会去挑战产品的品牌性和规范性，综合这 2 方面的原因，我们需要随时调整我们对于感知性模式的策略。
数据的好坏往往来自各种原因，优化设计后得到好的数据，但并不能说我们的感知性设计是好的，首先刺激数据的手段有很多，例如加重内容的表现、利用颜色对比突出想要突出的模块，这些方式都是与感知性设计背道而驰的。
基于上面这个问题，我们在日常设计中有几个基本原则是需要我们去遵守的，尽量避免为了满足短时间的产品需求而影响整体的设计感知性。
1. 不挑战基础规范原则
基础规范作为整体设计的基本标准，整体的制定肯定经过多种尝试之后的结果，如果轻易推翻的话，其中产生的设计成本是巨大的，往往需要重新输出、多方对齐、最终输出、再落地形成开放组件，在我日常的工作中也常遇到。往往是因为一个极小的模块而产生了巨大的设计成本。
2. 不改变用户的普识习惯
这里说的不是不去优化或迭代体验设计，而是我们应该尽量避免因为一个很小的内容而调整全局的体验方式。
举个例子：早前很多 APP 在设计表单选择器时都喜欢进行 UI 定制，从这个问题分析，用户在使用这种表单选择器的时候是用的系统多一点还是我们的 APP 多一点，如果是系统的多一点，我们何不直接调用系统？因为组件的 UI 改造，往往会带来一定的开发成本，但其造成的感知却并不够大，反而会让用户觉得很奇怪，为啥这些选择权在不同 APP 的不一致。
3. 一致性最大化
任何的设计都应该以一致性作为最大的前提，这样才能更加完整体现感知性模式，在各个模块、颜色、图形等等内容都具有完整的呈现，无时无刻影响着用户，让用户对于整体具有潜移默化的感知。
感知性模式不是一个原则，而是一种工作方式、设计模式，除了个人的坚持之外，还需要有团队的意识才能让我们的设计更加具有品牌性，自上而下的调性、方向的确定，在团队中形成共识，这样设计语言才能形成。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码ben_lanlan，报下信息，会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
文章来源：优设 作者：ID设计站
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
很多受欢迎的产品中都有我们值得学习和借鉴的设计思考点，通过分析海外主流产品，带大家掌握底部导航栏（Tab Bar）的基本知识，找到解决问题的方法并开拓创意思维。
在开始之前，请大家先思考下面两个问题～
好像并不是。虽然淘宝、微信、微博、美团等大多数主流的产品都在使用 Tab Bar，但这并不意味着所有产品都需要它。
很多APP没有Tab Bar，比如日历、计算器、滴滴、Uber等。对于是否要在APP中使用Tab Bar，应该分不同的情况灵活考虑。
答案是为了易于使用，意味着通过 Tab Bar 这种简单的设计可以轻松帮助用户导航到页面。
明白了上面的问题后，接下来就要考虑如何来设计 Tab Bar，能更好的满足用户的需求和体验。
1. 显示最重要的信息
导航栏应该只包含最有用的信息，不能添加过多无用的标签使导航栏混乱。许多 App 在导航栏上添加搜索功能，因为这有助于用户更快地导航和检索内容。
在Spotify底部导航中，主页选项用于播放或收听所有内容，搜索选项用于搜索下一首歌曲和播客，音乐库选项用于播放列表中喜欢和保存的歌曲，单独的会员选项方便用户轻松点击并快速完成购买操作。
2. 扩展导航的功能
主流 App 更喜欢在底部导航栏中使用 4-5 个标签，这样能保持导航栏的整洁，还避免了标签过多导致用户难以精确点击选项的情况。
Pinterest的导航栏上只有四个选项，这有助于用户轻松点击。消息选项会实时更新消息数量，对用户来说这样的提示很直观。另外搜索功能包含在导航栏中，方便轻松地在主页和搜索结果之间来回切换。
3. 容纳多种标签形式
多数 App 底部导航栏会使用「图标+文字」的标签形式，这样能清楚地告知用户点击标签之后的结果。
有时候我们也会看到有些产品的导航栏只有图标没有文字，但这种形式并不会影响我们的操作，因为当导航栏的标签使用了用户特别熟悉的形状和内涵，完全可以省略文字。
宜家App的导航栏使用了大众都很熟悉的图标，所以即使不加文字，我们也能清楚地知道这3个图标分别代表了主页、分类、我的。
相对于宜家，Youtube的导航栏就显得有点复杂，因为Youtube的图标含义用户可能并不是很熟悉，加上文字说明很有必要。
4. 文字标签应该简短
文字标签应该简短而清晰，准确的文字说明能对用户使用正确导航起到关键作用。
TikTok导航所有的文字标签都简短，并且中间的添加图标还隐藏掉了文字，以此来引吸引用户的注意力。
5. 避免隐藏导航栏
Tab Bar 通常包含了最重要的导航信息，应该始终向用户展示，避免在用户滚动页面的情况下被隐藏掉。
Pinterest导航栏的设计是个例。当滚动页面时，底部的导航栏会隐藏，这么设计的原因可能是为了防止导航栏遮挡图像，保证用户看到更多的图像内容。
6. 传达位置
Tab Bar 帮助用户轻松导航，但如果用户不知道自己的位置，将会影响他们浏览和使用产品的体验。
多邻国App通过改变导航图标的样式来让用户清晰的知道自己所有的板块。
Headspace在底部导航栏加上了线条装饰，每次切换选项，线条都会跟着一起切换，确保告知用户确切的位置。
7. 从反馈中学习并不断改进
反馈是关键，如果想改善产品的导航栏设计，就要考虑并测试用户最喜欢哪个导航选项，不使用哪个导航，需要四个还是五个选项等等。
Pinterest通过收集用户的使用反馈情况来不断改进导航栏的设计，帮助用户更方便地使用产品，这些不断打磨的改进真是产品成功的关键。
8. 在导航栏中显示更新
Tab Bar 不仅仅起到导航的作用，很多时候还能通过状态变化告知用户更多的信息。
在Twitter主页导航中，当有新内容推送时，主页就会出现更新的状态，提示用户查看新内容。这样的设计在Youtube、Pinterest等很多主流产品中都有使用。
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码ben_lanlan，报下信息，会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
文章来源：优设 作者：Clip设计夹
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
表格作为组织整理数据的手段，可以有效的向用户展示数据信息，是B端产品中出现最高频的模块之一。
下图为典型的B端表格示例：
用户主要通过表格浏览获取信息、对数据进行筛选、排序以及相关业务处理等更多复杂操作、对比数据的差异与变化（关联和区别）。好的表格信息展示设计，应当是能够辅助用户高效便捷的实现以上场景中的诉求。
今天我们就来讨论表格设计中一个重要的问题——【应该如何考虑表格信息展示】。首先抛出结论，我们认为良好呈现信息的表格应当做到疏密适度、高效扫视、精简克制。
1
常见的表格信息包含文本、标签、状态样式、数值统计图表、关键信息Icon等。表格单元格是信息填充的基本单元，行高和列宽的定义决定了表格信息的疏密程度，进而决定了表格给用户的直观感受，因而下面分别从行高和列宽两个方向来探讨表格信息展示如何疏密适度。
1
a、行高模数设定
在具体设定表格行高时，由于表格中以文字信息为主，我认为可以参考文字排版的常用做法，将整个表格的行高分成文字行高、文字与分割线间距离，即上下间距两部分来考虑。文字行高可以设定为字号的1.2~1.8倍，文字与分割线间距离可以设定为字号的1~1.5倍。分为这样的两部分也比较符合开发同学写代码时的习惯（多行行高同理去设定）。
根据用户场景的不同，来选择模数倍数，需保证系统内使用统一的模数。比如，针对用户快速浏览获取大量数据场景时，可以选择1.2倍作为模数，列表更为紧凑，同样扫视范围内，可获取更多信息。
b、为小屏幕考虑一屏显示的行数
表格行高决定屏幕内能呈现的行数，即用户在一屏内能获取信息的数量，主要影响用户纵向对比数据的效率。对于1920*1020（包含该分辨率）以上的大屏用户，对于一屏显示行数的感知不强，但对于1366×768、1280*720等这类小屏，显示行数有限，用户进行纵向数据对比的效率就会有所降低。在设计前，应当充分了解目标用户的行为诉求，了解目标用户设备屏幕分辨率的占比分布情况，有针对性的设置行高。
c、用户自定义行高的场景
B端产品的特点之一是通用化，覆盖用户角色多样。然而用户个体对于表格信息呈现密度的诉求经常是有所差异的。比如个人视力的原因，有些用户喜欢表格行高值大一些，看起来舒适透气，便于阅读。而有些平台用户由于很熟悉线下excel表格模式，希望线上的表格也尽可能像excel那样紧凑，以便他们在一屏内看到更多的数据，进行对比，提升工作效率。产品为了让不同用户都能获得较好的体验，可以考虑把表格疏密度的设置开放给用户，建议不是完全开放给用户去调整尺寸，而是给出一定阶梯度的快速选项，例如舒适、标准、紧凑三种高度来满足用户需求。
例如，Gmail提供默认/标准/紧凑三种表格密度设置，如图：
1
通过对表格固定位置与列宽的调整，扩大表格数据空间，使信息不局促，空间更透气，保证横向扫视易读性。
a、列宽极限值设定
设计师需要根据表格承载内容定义表格的列宽，应包含最大/最小/默认列宽的定义以及使用规则。
我推荐的一个规则是：
规则1：当相对列少【浏览器宽度-页面其他模块 > 全部列的默认宽度和】，则各个列自动等比拉伸，撑满屏幕；
规则2：当相对列多【浏览器宽度-页面其他模块 < 全部列的默认宽度和】，则出横向滚动条，每列宽度为默认宽。
另外需注意最小值设定时应避免信息展示出现【对联式表格】。对联式表格最大的问题在于，一屏内展示的行数有限，当用户纵向对比数据时，需往复滚动多次，记忆压力大；横向扫视时，阅读视线不能一直保持左右横向预览，而是不停上下左右切换，使用体验不佳。
b、横向『偷取』屏幕外空间、行高模数设定
当压缩列宽也无法在有限空间内展示大量的数据指标列时，我们可以借助横向滚动来『偷取』屏幕外更多空间。横向滚动需用户拖动滚动条进行浏览，有一定操作成本，所以要结合业务实际情况选用是否利用屏幕外横向空间。
随着行和列的增加，用户的瞬时记忆会达到极限，超过“7±2原则”的范围，用户需要依靠辅助信息去阅读表格内的数据，防止遗忘某列数据的意义。因而当表格数据列较多横向滚动时，建议为用户固定重要信息列，如标题列、操作列。同时用户浏览表格时是符合F型扫视原则的，建议固定列显示在表格左侧，方便用户从左至右浏览数据、从上至下对比数据时能够清晰定位当前所浏览数据的主体是什么，同时可根据需要快速发起操作。
同理，用户拖拽纵向滚动条来阅读数据时，可固定表格的表头，帮助用户在阅读过程中清晰知晓单元格数据的意义。
c、用户自定义展示信息
针对需展示大量数据的情景，我们除了【偷取】屏幕外空间外，可以根据B端产品提供的数据表格是覆盖全部用户角色的全量数据的特点，让不同用户角色来自定义想要浏览的信息，从而提升表格的可读性。下图为百度信息流推广平台的自定义列功能，用户可根据需要选择展示的数据列，系统将在用户完成选择后，主动帮用户保存自定义内容，下次登录后，表格依然按照用户定义的数据来展示。
1
无论是在表格中要明确的定位数据，还是顺序阅读，高效扫视都是B端用户一个很重要的诉求，我们在设计表格时可尝试一些有效手段提升用户浏览获取信息的效率。
1
数据信息本身包含多种格式，可遵守一个基本原则即文字左对齐，符合从左到右的阅读习惯；数据信息右对齐，方便数据大小的直观对比。
具体对齐方式可参考我们建议的方式：
文本字段：可点击字段、普通文本类、数字、字母等，长短参差不齐，左对齐；
格式化字段：日期、时间、部分枚举类等，字符数一致且较短的，左对齐。
数据字段：金额、数据、百分比。带小数点等数据，方便对比为主，右对齐。
1
a、正确使用分割线，实现对表格行与列的强调
横向分割线可强调行内信息的连续性。垂直分割线在缩减元素之间的距离后也能区分不同元素，更好的强调纵向数据对比。但只要遵循良好的对齐方式，通常不展示纵向分割线，避免信息干扰。因而表格中通常仅使用横向分割线和底色分割，提升表格阅读效率。
1
b、斑马线作用有限
斑马线即隔行（列）变色。它能让行（列）间界限更为明显，但由于与分割线的作用类似，起到的作用有限，可针对不同场景酌情考虑是否使用。比如针对不同类型的数据（如总和、平均值）使用不同底色来区分，可以更突出强调该数据。要注意的是，隔行（列）换色的两种颜色不能反差过大，否则看来太“跳跃”。
对同一类数据而言，分割线就已经能够明显区隔，所以可不使用斑马线，但需要给出单行的悬浮状态，强化横向导视，避免出现列数过多引起数据错行的问题。
1
前面我们提到表格呈现的数据信息除文本外，还有其它一些可视化数据。可视化一方面提升了列表视觉表现力，增加差异化，另一方面让内容更加突出，提升阅读效率。例如：数据列中数据异常时，最好可以醒目的形式突显，让用户一进入页面就能快速注意到异常状况。
1
体验好的表格一定是克制的，克制应表现在信息的适度隐藏以及内容折行与截断展示原则。
a、隐藏低频操作
当表头需要承载排序、表头筛选、提示等功能时，不建议一股脑的将所有功能展示出来。用户对表头的诉求是定位数据指标﹥执行操作的，因此可根据具体业务定义展示哪些操作，将其它操作隐藏，有需求时用户主动触发再展示。比如，百度搜索推广平台的推广管理页面提供了全局筛选，所以表头筛选对于用户而言是相对低频的操作，我们选择隐藏表头筛选的图标，当用户鼠标HOVER表头单元格时再展示。
对于表格行内的操作我们也应当进行优先级排序，为用户专门设置操作列展示高频核心的操作，其它相对低频的次要操作可隐藏在相关数据单元格中，用户有诉求时hover对应单元格即可快速发起操作。
b、隐藏辅助信息
表格中的有些数据指标是综合纬度的，当用户关注点定位于该指标时，需要通过细分数据来理解、分析。指标的细分纬度信息虽能起到辅助用户更好理解数据指标的作用，但如果全部拿出来在表格列展示，会让表格变得臃肿不易读，此时可以考虑采取一定设计手段去隐藏这些信息，把触发展示的自由度交给用户，也更符合用户逐级查看的场景。例如，百度搜索推广平台中关键词列表中，质量度指标是由多条数据共同决定的，我们采用了将细分指标聚合在气泡卡片中，当用户HOVER质量度得分数据时展示出来。
1
再比如，有父子层级关系的数据，可以通过父子折叠表格将子信息默认隐藏，用户根据需要，去展开查看详细的子信息。
B 端业务的数据信息复杂多样，信息内容的长度高度是多样不可控的，很多内容会超出我们限定的最大列宽，最大列高，我们应当给出折行与截断原则去约束内容的展示，而非总是为具体情况而做特殊设计，破坏体验的一致性。
截断折行原则设定时要细分，不能简单粗暴的一刀切，比如一行截断这种，如日期、时间等固定格式内容，拖动列宽后文字应折行而非截断展示，避免影响用户误读。再比如很多业务实体标题字段是格式化的，即标题前面部分可能都是一致的，这时候如果简单的截断，用户就需要逐一Hover才能找到定位到要找的数据。因而折行与截断原则，我们建议是给出三种：单行截断、双行截断以及自适应截断，根据具体业务情景选择。
1
我们今天集中讨论了应该如何考虑表格信息展示，并总结了如何做好表格信息展示，即遵守【 疏密适度】、【高效扫视】、【精简克制】三原则，并结合业务特点以及目标用户场景，设计高效易读的表格。
最后，感谢你花费宝贵时间阅读这篇文章，希望可以给你带来一些启发。我们非常期待我们的思考和一些小经验能够帮助你去设计满足你的业务场景的表格，也可以通过这些方法和步骤，创造属于你们团队自己的设计资产。
感谢阅读，以上内容均由百度MEUX团队原创设计，以及百度MEUX版权所有，转载请注明出处，违者必究，谢谢您的合作。申请转载授权后台回复【转载】。
也欢迎加入MEUX,视觉/交互/用研
可投简历至MEUX@BAIDU.COM
(注明信息获取来源如：公众号）
蓝蓝设计建立了UI设计分享群，每天会分享国内外的一些优秀设计，如果有兴趣的话，可以进入一起成长学习，请扫码蓝小助，报下信息，蓝小助会请您入群。欢迎您加入噢~~希望得到建议咨询、商务合作，也请与我们联系。
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
今天开发项目的时候，用Datatables插件做前端分页列表，想在列表发生翻页、排序、搜索、改变单页显示数据条数这些行为的时候做一些其他的操作，看了半天Datatables官网终于找到可以监测到这些事件发生方法：
-
$('#table')
-
.on( 'order.dt', function () {
-
console.log( '排序事件' );
-
} )
-
.on( 'search.dt', function () {
-
console.log( '搜索事件' );
-
} )
-
.on( 'length.dt', function ( e, settings, len ) {
-
console.log( '改变单页显示条数事件' );
-
console.log( 'New page length: '+len );
-
} )
-
.on( 'page.dt', function () {
-
console.log( '翻页事件' );
-
} )
-
.DataTable();
遇到问题多看官网，而且英文网站的社区讨论真的有很多有效的提问和回答。
附上datatables的官网:https://datatables.net/,大家遇到问题可以多看看
转载于:https://www.cnblogs.com/fuxin41/p/6782994.html
文章来源：博客园
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
记得还是15年的时候，工作需要，独自写后台管理系统。。记得那时候，最让我头疼的不是后台逻辑，而是数据的列表展示。 列很多的时候,页面显示问题;分页样式问题;表格样式问题;数据加载...很多细节的问题，费时，而且总是达不到我想要的效果...也是那个时候，第一次接触了datatable.js插件,只需要简单的修改配置值，就可以改变表格的方方面面,真的是非常好的体验。。。
不过，因为一些历史原因，和时间问题，那时候对 ajax加载+服务端分页+页面刷新,仍然是一直很迷迷糊糊...刚好最近工作中需要做一个列表管理页,所以就很自然的选择了datatable.js,并且总算把 ajax加载数据+服务端分页+reload这套流程弄通。也许还有很多种方案可以达到效果，但至少这个是肯定可行的.
样式是基于bootstrap风格.
<!-- datatables样式和bootstrap支持样式 --> <link rel="stylesheet" type="text/css" href="https://netdna.bootstrapcdn.com/bootstrap/3.0.3/css/bootstrap.min.css"> <link rel="stylesheet" type="text/css" href="https://cdn.datatables.net/plug-ins/28e7751dbec/integration/bootstrap/3/dataTables.bootstrap.css"> <script type="text/javascript" language="javascript" src="https://code.jquery.com/jquery-1.10.2.min.js"></script> <script type="text/javascript" language="javascript" src="https://cdn.datatables.net/1.10.15/js/jquery.dataTables.min.js"></script> <script type="text/javascript" language="javascript" src="https://cdn.datatables.net/plug-ins/28e7751dbec/integration/bootstrap/3/dataTables.bootstrap.js"></script> <script src="https://cdn.bootcss.com/bootstrap/3.3.7/js/bootstrap.min.js" integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa" crossorigin="anonymous"></script> <!--form ajax提交--> <script src="https://cdnjs.cloudflare.com/ajax/libs/jquery.form/4.2.1/jquery.form.js"></script>
<!-- search 框start --> <div class="container"> <nav class="navbar navbar-default"> <div class="container-fluid"> <!-- Collect the nav links, forms, and other content for toggling --> <div class="collapse navbar-collapse" id="bs-example-navbar-collapse-1"> <form class="navbar-form navbar-left"> <div class="form-group"> <input type="text" class="form-control" placeholder="用户姓名" name="userName" id="searchUserName"> </div> & <div class="form-group"> <input type="text" class="form-control" placeholder="律所名" name="officeName" id="searchOfficeName"> </div> & <div class="form-group"> <input type="number" class="form-control" placeholder="状态" name="be_valid" id="searchValid"> </div> <button type="button" class="btn btn-success" onclick="searchData()">搜索</button> </form> <form class="navbar-form navbar-right"> <button type="button" class="btn btn-primary btn-sm btn-warning" data-toggle="modal" data-target="#addModal"> 新增律所 </button> </form> </div><!-- /.navbar-collapse --> </div><!-- /.container-fluid --> </nav> </div> <!-- search 框end --> <div class="container"> <table id="mytable" class="table table-striped table-bordered table-hover" cellspacing="0" width="100%" style="white-space: nowrap;"> <thead> <tr> <th>用户名</th> <th>用户ID</th> <th>邮箱</th> <th>身份</th> <th>律所</th> <th>律所id</th> <th>律所简报</th> <th>律所创建时间</th> <th>限制人数</th> <th>验证码</th> <th>状态</th> <th>备注信息</th> <th>操作</th> </tr> </thead> <tbody></tbody> <tfoot> <tr> <th>用户名</th> <th>用户ID</th> <th>邮箱</th> <th>身份</th> <th>律所</th> <th>律所id</th> <th>律所简报</th> <th>律所创建时间</th> <th>限制人数</th> <th>验证码</th> <th>状态</th> <th>备注信息</th> <th>操作</th> </tr> </tfoot> </table> </div>
因为是服务端分页,所以我页面做了搜索框,进行自定义的参数搜索.
<script type="text/javascript"> var oTable; $(function(){ LoadData(); }); function searchData(){ oTable.draw(true); // oTable.ajax.reload(null,true); }function LoadData() { oTable = $('#mytable').DataTable({ //sDom: 'T<"clear">lfrtip', oLanguage: { sZeroRecords: "对不起，查询不到任何相关数据", sInfoEmpty: "记录数为0" }, sScrollX: "100%", sScrollXInner: "110%", bScrollCollapse: false, //可滚动 bDestory: true, //数据允许清空 bServerSide: true, //服务端处理分页 bLengthChange: false, //是否允许自定义每页显示条数. iDisplayLength: 20, //每页显示10条记录 bPaginate: true, //是否分页 //sPaginationType: "amaze", //分页样式 "full_numbers" //bJQueryUI: true,//是否将分页样式应用到表格 bProcessing: true, //当datatable获取数据时候是否显示正在处理提示信息。 bFilter: false, //是否启用条件查询 bSearchable: false, //bStorable: false,//是否启用列排序 //bInfo: true, //是否显示分页信息(页脚信息) order: [[7, "desc"]], //默认按照第几列排序,从1开始 bAutoWidth: false, //自动宽度 bStateSave: true, //状态保存，使用了翻页或者改变了每页显示数据数量，会保存在cookie中，下回访问时会显示上一次关闭页面时的内容 ajax:{ dataType:'json', type:'POST', url: '/adminUserList', headers: { 'token': window.localStorage.token //取localStorage中的token，用来做安全校验 }, dataSrc: "aaData", data:function(d){ //取搜索的参数值,在请求服务端时,附加到请求参数中 var userName=$('#searchUserName').val(); var officeName=$('#searchOfficeName').val(); var be_valid=$('#searchValid').val(); d.userName=userName; d.officeName=officeName; d.be_valid=be_valid; } }, columns: [ { data: "name", bSortable: false }, { data: "user_id", bSortable: false }, { data: "email", bSortable: false }, { data: "level_name", bSortable: false }, { data: "office_name", bSortable: false }, { data: "office_id", bSortable: false }, { data: "officeBriefing", bSortable: false }, { data: "office_create_time"}, { data: "limited_num", bSortable: false }, { data: "verify_code", bSortable: false }, { data: "be_valid", bSortable: false }, { data: "remark", bSortable: false }, { data: null, render: function (data, type, row) { return '<button type="button" class="btn btn-primary btn-sm" onclick="editShow(\''+data.user_id+'\')">编辑</button>'; }, bSortable: false } ] }); } </script>
@ResponseBody @RequestMapping(value = "/adminUserList",method = RequestMethod.POST) public AjaxListResponseDTO<AppUserShowDTO> getAdminUserList( @ApiParam(required = true, name = "start", value = "开始条数") @RequestParam Integer start, @ApiParam(required = true, name = "length", value = "取多少条") @RequestParam Integer length, @ApiParam(required = true, name = "userName", value = "用户名") @RequestParam String userName, @ApiParam(required = true, name = "officeName", value = "律所名") @RequestParam String officeName, @ApiParam(required = true, name = "be_valid", value = "状态") @RequestParam Integer be_valid, HttpServletRequest request) throws Exception{// Map<String,String[]> paramMap=request.getParameterMap(); String[] orderTypeArr=request.getParameterValues("order[0][dir]"); String lawOfficeOrderType=""; if(null!=orderTypeArr){ lawOfficeOrderType=orderTypeArr[0]; } AjaxListResponseDTO<AppUserShowDTO> responseDTO=new AjaxListResponseDTO<>(); //datatable.js 相关参数 String[] drawStrArr=request.getParameterValues("draw"); if(null!=drawStrArr){ responseDTO.setSEcho(Integer.parseInt(drawStrArr[0])); } Page<AppUserShowDTO> appUserShowDTOPage = authUserService.findAllUserAndLawOffice(userName,officeName,be_valid,null!=start?start:0,null!=length?length:20,lawOfficeOrderType,"超级管理员"); responseDTO.setITotalRecords((int) Math.ceil(appUserShowDTOPage.getTotal()));//实际需要传数据总数,此处值不对 responseDTO.setITotalDisplayRecords((int) Math.ceil(appUserShowDTOPage.getTotal())); responseDTO.setAaData(appUserShowDTOPage.getResult()); return responseDTO; }
start(起始条数,注意，是条数而不是页数 )和length(取多少条数据)为datatable默认会传到服务端的2个参数, userName/officeName/be_valid则为我前端自定义的附加参数。
Page是List<T>泛型集合,是开源项目PageHelper-mybatis中的类。
服务端返回给前端的json数据也有格式要求，具体见AjaxListResponseDTO类定义.
/** * Created by xinhuiyang on 2017/6/9. */ @Data public class AjaxListResponseDTO<T>{ private Integer sEcho; private Integer iTotalRecords; private Integer iTotalDisplayRecords; private List<T> aaData; }
自此,就实现了带搜索功能的服务端分页效果.
首先,在之前的基础上,需要添加一个js文件引用
<!-- 固定列 插件js --> <script src="https://cdn.datatables.net/fixedcolumns/3.2.2/js/dataTables.fixedColumns.min.js"></script>
其次,在配置项中添加一项:
oTable = $('#mytable').DataTable({ //sDom: 'T<"clear">lfrtip', oLanguage: {
sZeroRecords: "对不起，查询不到任何相关数据",
sInfoEmpty: "记录数为0" },
sScrollX: "100%",
sScrollXInner: "110%",
bScrollCollapse: false,
fixedColumns: { //固定列的配置项 leftColumns: 1, //固定左边第一列 rightColumns:1 //固定右边第一列 },
bDestory: true,
bServerSide: true,
.....省略......
然后，刷新页面...至此，固定列效果就ok了。
现在的页面效果，还有2个瑕疵:
其一是后台返回"总条数"不对,我是时间赶,来不及写查询了..大家实际使用时,自己查询一下就行,这个好解决;
其二是前端页面，下角显示页码总数和页脚信息显示有问题(见下图),不知道当后台"总条数"准确时，会不会就ok了。我后面还会找个时间，去修复一下的...当我有解决方案时,会补充在下面的,大家有知道原因和解决方案的，也欢迎评论在下方。
1.左边数字没显示出来.
2.实际83条数据,每页20条,应该最多到5页的，但实际上,可以点任意页，只不过从第6页开始，数据都为空.
页面显示不对的问题已经找到原因并且解决.
原因是：后端分页时,需要返回给前端更多的信息,如总数多少，过滤后多少等,所以我代码中的AjaxListResponseDTO类就不符合后端分页时的需求了，需要改动.
修改后的类定义为：
/** * Created by xinhuiyang on 2017/6/9. */ @Data @ApiModel public class AjaxListResponseDTO<T>{ @ApiModelProperty("必要。上面提到了，Datatables发送的draw是多少那么服务器就返回多少。 这里注" + "意，作者出于安全的考虑，强烈要求把这个转换为整形，即数字后再" + "返回，而不是纯粹的接受然后返回，这是 为了防止跨站脚本（XSS）攻击。") private Integer draw; @ApiModelProperty("必要。即没有过滤的记录数（数据库里总共记录数）") private Integer recordsTotal; @ApiModelProperty("必要。过滤后的记录数（如果有接收到前台的过滤条件，则返回的是过滤后的记录数）") private Integer recordsFiltered; @ApiModelProperty("必要。表中中需要显示的数据。这是一个对象数组，也可以只是" + "数组，区别在于 纯数组前台就不需要用 columns绑定数据，会自动按照顺序" + "去显示 ，而对象数组则需要使用 columns绑定数据才能正常显示。") private List<T> aaData; @ApiModelProperty("可选。你可以定义一个错误来描述服务器出了问题后的友好提示") private String error; }
相应的，controller部分代码,也要给对应的属性附上正确的值,改动后代码如下：
@ResponseBody @RequestMapping(value = "/adminUserList",method = RequestMethod.POST) public AjaxListResponseDTO<AppUserShowDTO> getAdminUserList( @ApiParam(required = true, name = "start", value = "开始条数") @RequestParam Integer start, @ApiParam(required = true, name = "length", value = "取多少条") @RequestParam Integer length, @ApiParam(required = true, name = "userName", value = "用户名") @RequestParam String userName, @ApiParam(required = true, name = "officeName", value = "律所名") @RequestParam String officeName, @ApiParam(required = true, name = "be_valid", value = "状态") @RequestParam Integer be_valid, HttpServletRequest request) throws Exception{ // Map<String,String[]> paramMap=request.getParameterMap(); String[] orderTypeArr=request.getParameterValues("order[0][dir]"); String lawOfficeOrderType=""; if(null!=orderTypeArr){ lawOfficeOrderType=orderTypeArr[0]; } AjaxListResponseDTO<AppUserShowDTO> responseDTO=new AjaxListResponseDTO<>(); //datatable.js 相关参数 String[] drawStrArr=request.getParameterValues("draw"); if(null!=drawStrArr){ responseDTO.setDraw(Integer.parseInt(drawStrArr[0])); } int totalCountBeforeFilter=authUserService.countUserByLevel("超级管理员"); Page<AppUserShowDTO> appUserShowDTOPage = authUserService.findAllUserAndLawOffice(userName,officeName,be_valid,null!=start?start:0,null!=length?length:20,lawOfficeOrderType,"超级管理员"); responseDTO.setAaData(appUserShowDTOPage.getResult()); responseDTO.setRecordsTotal(totalCountBeforeFilter); responseDTO.setRecordsFiltered((int) appUserShowDTOPage.getTotal()); return responseDTO; }
然后，页面的页码显示就正确了(如图):
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利;
原文链接：https://www.cnblogs.com/Andrew-XinFei/p/7020055.html
文章来源：博客园
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
如今设计师不再仅仅作为一个需求的接收方与执行方，职能更加的全面，在整个产品设计研发流程中也需要我们有更强的参与度。最近工作中得到一些设计同学的咨询并参与围绕着一些项目中的问题进行讨论，比如：项目协同与执行的过程中总感觉节奏乱？对于项目缺乏整体的规划、每次设计过程中付出的成本很高。对结果验证时发现不论设计质量还是效率都还有很大的提升空间。设计感觉做的不错，但项目中的角色话语权不高？多个项目并行不知如何管理操作，有无标准方法，怎么从中创造更大的价值？本文结合日常项目管理当中的一些思考与方法，带大家了解设计师需要有的项目管理意识。
a
首先，我们思考一下，管理是什么？其实简单来说更像是很多标准化、流程化、格式化的方式方法组合，辅助我们更好的达成目标，并为整个设计团队构建一个基础的工作体系。项目中稳定与高效输出都来自于更加科学的管理。设计师链接上下游部门，也需要通过管理来解决诸多设计以外但与设计有联系的事务。对于我们的收获部分可以大致分成以下三点：
· 目标达成层面
引导促成整个产品/项目的目标高质高效达成，使之利益最大化。
· 视角变化层面
能够让我们视角产生改变，能够更全局看待问题，让自己有大局观的同时更加拥有结构化的思维。
· 影响力与服务能力的提升层面
在项目中角色话语权提升，在团队内外有更高的影响力
a
设计师运用项目管理的方法，个人认为最基本的就是要合理的规划与控制，管人管事，且贯穿在整个项目流程当中，以下几点其实我们可以重点关注。
我们工作当中实际参与的流程，基本可以归纳为启动阶段、计划阶段、执行监控阶段、收尾阶段。
· 启动阶段
在这个阶段经常会使用到6W2H方法，它有助于我们思路的条理化，杜绝盲目性，所以此方法能够快速帮助我们确定目标、里程碑、项目成员以及合作模式，例如在此前的二手车大类页改版等大型改版项目中都有所使用。
· 规划阶段
需求的梳理、排期、以及任务拆分、资源协调。我们可以尝试使用STAR模型来操作。而这部分在车业务的内部设计需求中也是在iWiki常态化留档的，以SITUATION（背景）,TASK（任务）,ACTION（行动）,RESULT（结果）几个维度构成表的基本结构。
需求规划完毕需要考虑的就是内部资源协调，在专职项目、动态项目、创新项目中协调的原则上可以是：擅长人做擅长事，挑战与执行并存，提效最大化，成长最大化。
· 执行监控阶段
在此阶段，我们可能会遇到以下一些问题，产出效率不高、质量不高、反复修改或项目推进缓慢影响业务目标。这些情况或风险在很多项目当中都存在，风险并不一定是坏事，而风险大多数都是可以预测和管理的，我们可以多使用WWH模型和STAR模型结合的方式快速的辅助我们思考、记录、评估、计划、调整。在落实的时候我们会使用到iWork工具进行需求的变更、说明、同步，包括后续的进度跟踪与回溯，在项目的管理上非常直观易用。
· 收尾阶段
对于该阶段质量控制方面，我们引入了更规范的走查文档、共建集成体验环节、以及全职能自查环节。常规的设计走查介入方式如下：
改变走查方式之后，增加集成体验环节与每个节点中的输入输出内容，保障每次项目的最终落地质量。
在收尾阶段从项目管理的角度来说另外一个希望提及的是，除了事前有规划、执行有控制、更要注重事后收尾有总结。虽然每一次的项目可能过程会有一些不同、结果目标不同，但是我们在总结复盘的过程中一定要做到以下几点：
1.拒绝形式化，避免假大空反思
2.具备借鉴意义
4.对应解决方案，具体落实到人、功能范围、时间等
w
其实我们可以发现既然是要去管理项目，在每个节点里沟通是非常重要的，可能很多设计师都会遇到一些沟通方面的问题：效率低、无结果、惧怕沟通。其实多数就是在信息通过传输渠道、媒介的时候，发送者与接受者在各阶段所暴露出的不同问题，如下图：
· 我们可以怎么做呢？大家可以多从以下几点去思考
1.沟通前的思路整理以及相关案例或设计理论的支持
2.对齐沟通方的关注点与信息交集
3.灵活正确的处理意见与分歧，开放心态、开放式话术、气氛控制、善用询问等
4.总结与使用流程管理进行规划
5.建立设计师个人品牌可信度
以上为对日常设计项目管理工作的一些个人理解，大家可在实际的项目当中灵活应用，如对项目管理方面非常感兴趣的同学也可以去看看PMP相关知识，也欢迎入群多多交流。
原文地址：58UXD（公众号）
转载请注明：学UI网》设计师的项目管理意识
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
每一个伟大的项目背后总有一个必要的契机和一个有趣的故事，而我们的故事是这样开始的。
在我们团队设计师之间经常会听到这样一些问题：
1、这个项目是谁做的？有没有源文件？
2、这个产品是设计规范是什么？我这样做符合规范吗？
3、之前那谁谁离职了，文件谁能找到？
总体说来就是设计文件管理难，规范一致性统一难，设计师对接协同难
在技术同学之间也会存在一些问题：
1、这部分代码是谁写的，怎么这么乱？
2、技术框架已经落后了，我们现在不这么写了，再优化也没有价值，我们计划重构代码
3、大量重复的UI还原工作，研发变身”切图仔”
4、明明是按照设计稿还原，设计同学总说差1px
而在产品侧的问题却是这样的：
每次都做了很多重复的事，我们版本需求量太有限了，这些问题大大影响了产品节凑和业务扩展的要求。
我们在工作协同开发过程中，一直缺少一个连通器，导致产品、设计、技术沟通协作不便，设计和技术规范落地较难。同时因为缺少容器承载导致各种资源和文件共享不便。因此使得我们重复设计和重复开发内容较多，影响了我们版本需求的吞吐量。
对于一款成熟的产品来说，夯实设计与技术的框架基础地基，这样才能助力我们在上空盖更壮丽的楼阁，基于这种契机，我们希望做一次彻底的改变
1
生逢乱世总有一些拯救世界的英雄出现。当我们带着想法和前端专家“存哥”一起聊的时候，没想到我们双方的想法不谋而合，甚至在细节和方向都出奇的一致。经过几次深度的协商沟通，我们快速制定了解决方案，同时招募研发团队，快速的开展项目，带着激情与理想，「58UXD」与「前端技术委员会」发起了共建项目「风火轮」。
主要通过两方面来解决问题：
设计插件提效：通过Sketch插件进入设计师的工作流程，聚合设计资产，解决设计规范落地、设计资产可视化承载，提升设计规范和设计资产的使用率，增强资源共享避免重复设计。
设计协同管理：通过风火轮协作平台进行团队资产、项目管理，实现设计稿在线标注解析，供研发同学在线查看研发。
在这里有的同学就会说，这不就是做了一个蓝湖吗？
那可就想简单了，我们的终极目标是：“把设计稿变成终端代码”。通过智能解析，将设计稿自动化解析生成代码，提升产研效率。
那么背后的逻辑和我们的思路又是什么呢？
3
在我们集团设计师Sketch的使用率高达90%，因此我们选择了Sketch作为UI自动生成代码的设计源，通过Picasso解析工具进行智能解析，高精度还原设计稿，支持多种代码格式，满足各种场景需求。
设计稿生成代码的主要流程如下图：
设计稿生成代码的实际效果展示：
为了提升操作效率，我们将Picasso工具在风火轮协作平台直接内置，这样设计师上传设计稿交付需求的同时，风火轮自动将设计稿转换成代码。代码生成的UI界面与设计稿几乎完全一致，并且代码的可用度高，生成代码的结构布局合理、可维护性高，提供了两种模式: 专注于高精度解析的运营版和专注于代码可用度的普通版，并且支持多种格式、尺寸的切图，导出来满足不同平台、不同尺寸屏幕的需求。
为了保证智能解析代码的还原度，我们通过以下几个方式来处理解析问题：
1、还原度计算—感知哈希算法
我们将自动生成的UI页面通过puppeteer进行截图，通过感知哈希算法与原图进行像素对比，计算出生成页面的真实还原度。
2、样式解析-渐变解析方案
在渐变处理方面，首先根据渐变类型分为线性渐变、径向渐变、环形渐变三种，然后根据渐变值、位置等信息计算渐变方向距离及渐变节点之间的比例，最终生成渐变样式代码。
3、图片处理—精准切图方案
为了精准还原图片，我们通过调用sketch API进行图层截图的方式，计算不规则图形的精准位置及大小，精准切图是保证我们的高精度还原页面的关键；
为了保证智能解析代码的可用度，我们通过以下三个方式来处理可用度问题：
1、结构重组
由于设计同学输出设计稿是以视觉为主，不太关注分组结构的合理性，因此我们需要将原有的分组去掉，按照符合开发习惯的方式进行重新分组。
2、特征分组
针对列表这种重复结构的场景，我们通过特征分组算法识别相似结构，减少代码重复，提升生成代码的合理性
3、样式优化-样式精简、样式排序
样式精简及排序，使得生成代码更贴近工程师”手写代码”，代码可维护性更高。
w
我们做一下回顾，20年12月30日成功将「风火轮」研发上线以来，历经7个月的时间，用户覆盖了集团85%的产研团队，并且覆盖了大多数的子公司。Sketch Plugin以容器的形式承载了6000+的设计资产和14调业务的设计规范，智能生成了1500+代码。
风火轮上线7个多月的时间，经历的3次版本迭代，上线核心功能点20+；风火轮插件发布了2个大版本，20多个小版本迭代，快速解决了100+的线上BUG，不断完善功能和优化体验。并且建立了完善的用户反馈机制，以最快的的方式解决用户诉求。
目前为止我们生成代码覆盖了常见终端代码格式：Web、Mini Programs、React Native、Flutter、iOS、Android等。代码解析还原精度达99.8%，生成终端代码可用度85%（目前行业顶级）
在未来我们要以解放生产力为目标，继续深耕从设计到代码的路线，以风火轮为媒介，将产品、设计、开发紧密的连接起来，为我们内部协同发光发热。同时也欢迎更多的设计师和研发工程师加入我们，共同构建风火轮生态，编写故事的下一篇章。
原文地址： 58UXD（公众号）
转载请注明：学UI网》把设计变成终端代码｜风火轮背后的故事和规划
分享此文一切功德，皆悉回向给文章原作者及众读者.
免责声明：蓝蓝设计尊重原作者，文章的版权归原作者。如涉及版权问题，请及时与我们取得联系，我们立即更正或删除。
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
蓝蓝设计的小编 http://www.lanlanwork.com