B端的分页组件，如何设计？
正文4800字，阅读30分钟
设计师疑惑：图中三种分页的使用场景有什么讲究吗？如何区分[大量页面]和[少量页面]这两种情况呢？
刨根问底，分页组件的设计研究。
各个设计系统对[分页Pagination]的定义：
采用分页的形式分隔长列表，每次只加载一个页面。Ant Design
当数据量过多时，使用分页分解数据。Element
用于模块内切换内容的控件。Tdeisgn
采用分页控制单页内的信息数量，也可进行页面跳转。Arco Design
分页用于将内容或数据拆分为多个页面，并带有导航到下一页或上一页的控件。IMB Carbon
经验告诉我们：分页未必都应用于列表。
一篇很长的文章，可以按照固定字数进行分页；一组相关的图片，每张为一页……这样可以创造更多的“页面”，便于搜索引擎收录，提升SEO效果。
“长列表”的标准是什么？“数据量过多”的标准是什么？只能分页吗？
很巧，作者查到了另外一份资料《分页和增量加载以及它们对 Google 搜索的影响》，其中提到分页、（手动）加载更多、（自动）无限滚动三种显示“较大列表的子集"的用户体验模式，并对它们进行了优缺点比较。
图片来自 developers.google.com
表格来自 developers.google.com
在Google的文章中，多次强调了“无法处理数量非常多的结果”只能分页，这句话的主语是什么？到底是谁“无法处理”呢？很明显，这里指的是技术层面，并不是用户认知层面！
所以，“长列表”与“数据量过多”的标准，设计师恐怕要咨询开发人员，各个公司的研发团队也许会给出不同的答案。
如果技术层面能够支持，根据Google的文章，手工加载的设计模式应该更优秀~~分页的优点，它基本也有，并且避免了分页的缺点：“需要进行复杂的操控”。
Google的文章忽略了一种情况：如果使用分页，用户可以收藏或分享某一个具体页码的URL；如果是手工加载更多，当然也能实现收藏或分享，只要每次加载拥有独立的URL即可。
但是，直接访问手工加载N次之后的URL，如果把前面加载的数据也渲染，将非常繁琐，少有研发团队愿意付出额外成本。
所以，手工加载往往只实现收藏或分享第1次点击之前的显示数据，无法按照分页独享URL，这算是手工加载的一个缺点。
当然，Google的文章是专门针对搜索结果，也少有用户会专门收藏或分享某一页搜索结果（因为结果会不断变化）。
小结：分页，主要是技术层面“无法处理数据量过多”的需要，站在用户体验角度，它的缺点是操作复杂，当不得不采用分页时，尽量保证用户掌握总页数和当前位置。
第二，分页组件的解构
如图，根据常见设计整理的“大而全”的组件，构建元素分为两种：见得，表示状态；操得，改变状态。
接下来，针对构建元素进行分析：
作为分页组件，必备元素有三个（红色标出）：
下一页(操作)
它们是完成翻页功能的“最低配置”，如下图
更加极端的例子，比如Polaris的分页只给了[上一页]和[下一页]两个操作，它看起来更像是浏览器/看图软件“前进/后退”的工具条。站在可用性角度，强烈建议加上[当前页(码)]，给用户足够的暗示：这是分页！
总记录数(状态)
它成为分页的组成部分，是一件奇怪的事：[记录计数器]应该独立成为一个组件。
原因之一：不使用分页，也需要计数器。比如“数量稳定保持较少，没必要分页”或者[手动加载更多]的情况。
原因之二：支持多选，计数器要变化。比如200项记录选中8项，将显示为“8/200”。
有一种怪异的设计类似 Displaying 61~90 of 103 items……完全把分页变成了一道数学题，用户难道还要思考：61是[步长]与[当前页-1]的乘积再+1的结果？！
这种倒装句式转换中文即“展示108项记录中的第31~40项”，如果正在设计国际化产品，这将是灾难的……并且，因为存在[当前页码/总页码]，这种数字游戏完全没必要存在。
如果展示邻页较少，它就变成了一个鸡肋的配置：如图，当前在第8页，7/9两页已经与[上一页/下一页]等效，完全就是浪费；6/10两页存在的意义也就微乎其微了，连点两次[上一页/下一页]即可。
所以，采用左右邻页一定不要吝惜空间，尽可能展示更多的页码。美观要给功能让位，请仔细观察google和百度在搜索结果中的分类：当前页左右的邻页是非对称设计，左5右4，加上本页，一共10页。
此类简单、有效、易于实现的设计，却被某些“设计语言”扭扭捏捏实现着。
例如，Arco 的提供了一个bufferSize的参数，用来控制左右邻页的数量，假如把参数设置为5，那么理想中的页码应该是这样的~~~
而实际上，这个设置在第1页就遇到了麻烦，右侧显示了7个邻页~~~
按照此参数设置上线，用起来的感觉如下面的动图（请注意选中第4/5/6/7页时的跳动）
作者试图寻找控制默认显示页码数量的方法，Arco好像并没有提供。
如果Arco的示例尚能接受，那么看看Tdesign是如何实现类似的效果：提供了两个参数foldedMaxPageBtn和maxPageBtn，用来控制页码显示数量。
在默认第1页的时候，如果分别设置参数为10/11/12，很明显是生效的~~
随着不断的向后翻页，出现了奇特的现象，当设置显示页码数量为10的时候，实际显示11个页码（为了保证当前页的左右邻页都是5）；同理，当设置12的时候，实际显示13个页码。
保持当前页的左右邻页相同，属于过度设计，一种功能向外观妥协的本末倒置。
至少目前来看，“追求对称”玩坏了很多“设计系统”，这也是行业普遍现状：体验就是视觉漂亮，没人关心是否逻辑自洽。
当然，Ant Design没有上面这些问题，因为它压根不支持自定义页码显示数量，无论你喜欢不喜欢，最多显示当前页的左右各2个邻页。（至少作者是没找到相关变量，也许是笨吧）
只有1页数据就隐藏页码，这也是一种过度设计。
仅有1页的页码，会有什么不妥呢？如果用户点击[前一页/后一页]那么就相当于刷新显示第1页，完全可用，完全不需要特殊处理。
只有1页数据就隐藏页码，主要问题：
如果项目激增，很快超过1页，没必要为了小概率事件进行开发和测试；
如果项目数量几乎不变，并且几乎只有1页，那压根就不需要页码；
如果列表有23个项目，步长为[10条/页]，显示为共有3页，此时切换步长为[50条/页]，那么按照规则~~~页码隐藏了？！
[尾页]和[总页数]需要分开考虑设计，没有总页数也能去往尾页。
用户几乎一定是从第1页开始，然后逐渐翻页，那么用户会抱着什么样的好奇心直接奔赴尾页呢？
如果是“最新在前”的列表，尾页就是考古挖掘；如果是“最旧在前”的列表，尾页就是最新项目~~~
那么，既然用户默认在第1页，为什么不能用排序功能直接考古挖掘呢？为什么一定要去往尾页？
提供[总页数]的确会给用户带来“安全感”，但是海量数据和巨额页码也会给用户带来压迫感。
通过搜索和筛选能缩小列表的数据范围，“总记录数”比“总页数”更贴近用户的期望，因为默认步长也许并不是[10条/页]或[100条/页]，总页数代表了访问全部数据的操作次数，并没有其他的意义。
没有总页数也能去往尾页，所以对于海量数据，应该尽量不显示页码，用来减少请求压力。
如果是时效性很强的内容，旧数据没有任何意义，也不需要显示总页数。
这种设置类的操作，本不应该直接放在分页组件中，更建议在限制设置中统一管理（字体、夜晚模式、字段显示等）。
变更步长可能给用户带来某些困扰，如果用户此时不在第1页，那么可能无法继续查看当前的内容了。
第一种设计方法，切换步长将强制返回第一页，目前Arco/Carbon都是采用此设计。
另一种设计方法，切换步长将始终保持在当前的页码，这会付出额外的开发成本，目前Ant/Element/Tdesign都是采用此设计。
保持当前页码看起来给了用户退路：比如用户当前在第8页，不小心切换了步长，快速切换回来，就能继续看刚才的内容了~~但是，用户记得刚才自己在哪个步长吗？
另一种情况：步长[20条/页]，用户当前在第8页(也是尾页)，此时切换步长为[100条/页]，第8页就消失了，按照规则用户将落在第2页（也是尾页)，那么这个时候用户切回步长[20条/页]，就永远回不去第8页了，依然将在第2页。
控制步长来自另外一个设计需求：希望在一屏展示一页，这样切换页码直接查看，无须滚动页面。
开发自动占满窗口功能，一键自动计算每页步长，也许是[13条/页]，也许是[27条/页]，就看谁的显示器更大，岂不是更好？
即便这样，用户使用非全屏窗口，或者改变窗口大小，依然没办法解决根本问题。希望在一屏展示一页，几乎只能是[10条/页]才能100%满足了。
在某些情况下，超大步长似乎更有意义，比如精准算法推荐的内容，[100条/页]甚至[200条/页]能大大减少翻页操作。
在某些情况下，切换步长可能带来另一种灾难，例如一个页面中存在多个列表的情况，其中一个列表步长变化，可能影响整体的美观和可用性。
“必须要前往某个特定的页码”，这种需求非常罕见，除非内容排序和页码之间存在特殊关联。
用户居然记得自己要找的内容大约在某页？或者，某个用户告诉另外一个用户去某页找某个内容？为什么不直接分享一个URL？
谁能保证两个用户看到的列表完全一致，在某页的内容也一致？
没有总页数，当然也可以跳转某页，因为“输入压根不存在的页码”永远可能发生；所以尽量不要在[跳转某页]元素中显示总页数，这种设计可能带来冗余，见下图。
要在列表中找到某些内容，最便捷的方法依然是搜索，如果不知道关键字就用筛选，为什么一定要直达列表的某页呢？收藏或分享URL下次直接进入，岂不是更好？
跳转页码这种桌面客户端的陋习，居然能在Web网页大放异彩，令人百思不得其解。
切换页码是一种精细操作，尽量提供键盘操作替代鼠标点击，比如PageUp/PageDown/←/→与Alt/Ctrl的组合等~~~桌面环境可操作的组件，都应该重视热键，特别是对专业用户而言，热键习惯是提升效率的核心之一。
回答设计师的疑问：大量页面/少量页面并不是影响分页设计的关键。
哦，好像找到了某些想法的原始出处~~~
那么通过前面的分析，总结设计分页组件时，设计师应该考虑数据内容的特点，而不是凭空想象分页的用法。
如果数据频繁新增，那么少量页面很快就变成大量页面；
如果数据新增缓慢，那么少量页面还是少量页面；
如果数据新增缓慢，大量页面不会变成海量页面；
如果数据基本不新增，并且只有几百条记录，那就压根不分页！
如果24小时内的数据才有价值，那么百万条陈旧数据就无须统计总数量，也不需要跳转到某页，甚至默认筛选近期的数据即可。
动态和静态数据混合的情况，谨慎地提供总页码和总记录数，必须与研发团队协商一致，比如今天的股票价格随时在变化，昨天的交易记录已经成定局。
通过按日期时间筛选，配合列表排序变化，合理缩减页码数量，避免用户在海量页码中翻来翻去。
如果用户时刻关注某个列表，他们可能真能记住某个东西大概在第几页；
如果用户一个星期都没有访问列表，期间产生了几百条全新数据，他们怎么可能记住某个东西大概在第几页？
如果用户半年才访问一次列表，真的会关心[总记录数]，但为什么不去统计界面查看呢？
如果用户不得不访问某个列表，恐怕真是来找东西，一个非常重要的东西，无论翻多少页，执着地找到它。
产生新数据，通过Ajax自动更新列表，或者用户手工刷新后体现，还是提醒用户手动刷新，这些也会影响分页设计。
如果用户正在第3页，如果自动刷新数据，那么第3页的数据就自动改变了（正在浏览就变化了） 。
如果用户正在第3页，如果产生新数据，询问用户是否跳转到第1页查看新数据（最新在前的排序）。
如果用户正在第3页，如果产生新数据，完全依靠用户手工刷新，当用户去往第4页的时候，依然能看到某些在第3页看过的内容（新数据向后挤压造成重新排序）。
避免非此即彼
例如，某些用户每天会收到大量的工作邮件，并且邮件列表自动刷新，此时设置较大步长，保证第1页展示尽可能多的新邮件，就能避免用户频繁的翻页！此时除了[上一页/下一页]，不需要太多操作入口。
采用什么样的分页，并不是由[总页数]决定，不能简单分为[大量页面]和[少量页面]，需要设计师灵活掌握，具体问题具体分析。
(正文完)
微信号“狗子他爹”的拼音