在设计工作台（控制台、管理后台）的内容数据列表的时候，排序的需求是一个经常遇到的问题。但我们遇到的排序场景都一样吗？使用者的真实诉求是什么样的呢？如何设计功能才能“真的”满足😌用户呢？来吧小伙子大姑娘们~今天我们来研究下这个问题。( •̀ ω •́ )y

1. 排序的需求场景

对于数据的排序，有大概有这些排序操作的使用点：

• 控制台菜单项排序
• APP中类别排序
• 推荐位次序排序
• 内容列表排序
  • 新闻内容
  • 活动内容
  • 资讯内容
  • ……
• ……

这些排序的操作需求，基本覆盖了大部分的排序场景。

---

2. 为什么要排序的意图分析

2.1 那么为什么要排序呢？

不同的场景会有不同的用户故事和需求原因。比如：菜单类的排序希望更贴合使用者的习惯；推荐位类、内容列表类的排序希望能给工作人员更灵活的内容控制方式，等等。

2.2 这些排序场景有什么异同点？

虽然排序场景很多，但分析下来。他们的需求场景其实有两种：

1. 有限项排序
2. 无限项排序

2.2.1 有限项排序

参与排序的数量是可控的，固定数量的（或者有最大数量限定的）。
属于这种排序的比如：

• 控制台菜单项排序
• APP中类别排序
• 推荐位次序排序

2.2.2 无限项排序

参与排序的数量理论上是无数的（用户可以一直加条目切不受限制）。
属于这种排序的比如：

• 内容列表排序

2.3 那么使用者需要什么样的排序？

对于有限项，我们只要能方便的控制他们的顺序就可以了。

对于无限项，我可能需要：

1. 在一段时间内把几篇内容放到列表的最顶上

比如某个新闻很重要，最近一周都需要让用户进到列表里第一个就看到。

2. 我想长期调整某几条内容的排序

比如现在有5条活动相关厂商稿，厂商要求前台用户看到的顺序是12345；但我在发布的时候没注意，按照51423的顺序发出去了，我不想删了重发（可能要消耗我一个小时），我希望永久调整它们的顺序。

---

3. 技术实现分析

3.1 有限项的技术实现

比较简单，只要给个可变的排序依据（比如序号），再考虑交互上如何设计就行了。

3.2 无限项的技术实现

其实对于无限项的排序，是有两种排序情况的：

1. 置顶类别的排序
2. 长期调整排序需求

3.2.1 置顶类别的排序

所谓置顶类别，就是把无限列表中的有限个数据放到一个独立的排序列表（置顶列表），再对置顶列表进行排序操作。
所以，它的本质上就是有限项排序。

3.2.2 长期调整的排序

需要有一个随时可变的字段，来做排序依据。

3.2.2.1 ID或者创建时间怎么样？

一般情况下，对于列表，技术可能会直接使用的创建时间或内容ID。但尴尬的是，这两个字段在业务里通常不具备可变性。

3.2.2.2 那么更新时间字段可以做为排序依据吗？

回答是当然可以，但它有可能太灵活了。比如可能我修改一个错别字，这篇文章的更新时间就变成当前时间了，它也就跑到列表顶部去了。

3.2.2.3 直接加个排序字段如何？

也可以！但要注意：

1. 这个字段要和置顶类别的排序字段区分。不然当这条内容一旦被置顶后取消置顶，它的排序位置就乱了。

2. 这个排序字段需要倒序（从大到小，大的在最顶上），如果正序（从小到大），那么每发一篇新内容，所有内容的排序号都要更新一遍。

   不过，这样做的确定也很明显

3. 每次加入一条新数据，需要对先整个列表计数，+1后才是新数据的序号

4. 各栏目序号相互独立，如后续有需要两个栏目内容合并，或两个栏目需在一个前台列表中展示，序号就可能会造成顺序bug

5. 如果工作人员需要调整，他应该把想要提升的序号设成多少呢？（随手写一个很大的数吗？）

3.2.2.4 有更好的方案吗？

必须要有！
个人建议，不要使用单纯的序号，继续用时间来排序。

这里，我们可以建立一个新的字段（排序时间），数据创建的时候将当前时间赋值给排序时间。工作人员可修改排序时间，前端按时间倒序排列即可。

对比序号场景的问题：

1. 置顶再取消的排序序号问题。使用排序时间，就不存在这个问题了
2. 加入一条新数据，对列表计数。使用时间也就不存在了
3. 两个栏目内容合并的场景。使用时间也没问题了
4. 工作人员手动调整。直接用时间，也没有到底要设多大的疑问（想放到上面，就把排序时间设成当前时间就好了）

3.3 规整一下

看看完整的需求场景，我认为：

• 有限排序用序号
• 无限排序用排序时

它们的排序优先级如下：

• 有限项：序号优先、其次ID
• 无限项：置顶序号优先、其次排序时间、最后ID

---

4. 可选的交互设计方案

4.1 指导思路

所见即所得：在列表中排序，排序结果需要实时反馈给操作人。

4.2 有限项排序交互

对于有限项，还需要区分项目数量（一个页面是否能展示完成）。不同的数量，因为需要考虑分页的情况，所以在交互设计上也需要做出区分。

4.2.1 一个页面能展示完所有内容

4.2.1.1 控制台拖动

对于控制台的这种操作，可以直接选择使用各类前端框架集成的拖拽组件，或者诸如Sortable之类的前端拖拽组件直接实现。这个组件名字是我随手搜的
这种操作的结果就实时展示在页面上了，给使用者很明确的反馈。是当前的首选交互方式。

4.2.2 多个页面才能展示完成

多个列表因为分页的存在，页与页直接的数据排序略有麻烦。不过我们也有两种办法：

4.2.2.1 在列表里直接编辑序号

既然不能拖拽，那我就直接在列表中暴露序号字段，让使用者直接点击修改。保存修改后立刻刷新数据列表，也能实现实时的修改反馈。
只是操作看起来不酷炫，/(ㄒoㄒ)/~~

4.2.2.2 提供向上/向下箭头供人点击排序

或者担心使用者乱输序号（其实有3.3的排序规则，乱填也没啥大影响）。也可以提供向上向下的箭头，点就完了。不过这里注意最好同时给提升至顶部之类的按钮。
但这个设计有弊端：

• 每点一次，你的数据就变化一次位置，数据如果比较多，真的操作起来会很烦

只能说，不推荐这样设计（个人认为，哪怕让使用者自己填序号都比这方式方便）

4.3 无限项排序交互

我们再来看看无限项的排序。这里可以根据技术实现的分析，把整个列表分为前边的置顶序列以及后面的正常序列。

4.3.1 先处理置顶序列

可以通过给数据提供一个置顶按钮，把数据加入到置顶序列。

置顶序列内，可考虑直接提供4.2.1.1的控制台拖动设计，或者采用4.2.2.1的直接编辑序号的方法。

4.3.2 再处理正常序列

这里其实真实的使用频次相对置顶低很多，所以只要提供一个可更新排序时间的方法就行了。比如可以可在数据的单独编辑页面内更新排序时间，或者像更新序号一样，在列表中直接点击排序时间进行更新。
重要的是记得更新后自动刷新列表哈

006Xzox4ly1g3sm2uwg7ng306o06otl8.gif

思考结束~其实这里交互部分并没有深入的思考(～￣▽￣)～，所以如果有什么交互的建议，恳请在下面留下你的想法。一起探讨。