在设计工作台（控制台、管理后台）的内容数据列表的时候，排序的需求是一个经常遇到的问题。但我们遇到的排序场景都一样吗？使用者的真实诉求是什么样的呢？如何设计功能才能“真的”满足😌用户呢？来吧小伙子大姑娘们~今天我们来研究下这个问题。( •̀ ω •́ )y
1. 排序的需求场景
对于数据的排序，有大概有这些排序操作的使用点：
- 控制台菜单项排序
- APP中类别排序
- 推荐位次序排序
- 内容列表排序
- 新闻内容
- 活动内容
- 资讯内容
- ……
- ……
这些排序的操作需求，基本覆盖了大部分的排序场景。
2. 为什么要排序的意图分析
2.1 那么为什么要排序呢？
不同的场景会有不同的用户故事和需求原因。比如：菜单类的排序希望更贴合使用者的习惯；推荐位类、内容列表类的排序希望能给工作人员更灵活的内容控制方式，等等。
2.2 这些排序场景有什么异同点？
虽然排序场景很多，但分析下来。他们的需求场景其实有两种：
- 有限项排序
- 无限项排序
2.2.1 有限项排序
参与排序的数量是可控的，固定数量的（或者有最大数量限定的）。
属于这种排序的比如：
- 控制台菜单项排序
- APP中类别排序
- 推荐位次序排序
2.2.2 无限项排序
参与排序的数量理论上是无数的（用户可以一直加条目切不受限制）。
属于这种排序的比如：
- 内容列表排序
2.3 那么使用者需要什么样的排序？
对于有限项，我们只要能方便的控制他们的顺序就可以了。
对于无限项，我可能需要：
- 在一段时间内把几篇内容放到列表的最顶上
比如某个新闻很重要，最近一周都需要让用户进到列表里第一个就看到。
- 我想长期调整某几条内容的排序
比如现在有5条活动相关厂商稿，厂商要求前台用户看到的顺序是12345；但我在发布的时候没注意，按照51423的顺序发出去了，我不想删了重发（可能要消耗我一个小时），我希望永久调整它们的顺序。
3. 技术实现分析
3.1 有限项的技术实现
比较简单，只要给个可变的排序依据（比如序号），再考虑交互上如何设计就行了。
3.2 无限项的技术实现
其实对于无限项的排序，是有两种排序情况的：
- 置顶类别的排序
- 长期调整排序需求
3.2.1 置顶类别的排序
所谓置顶类别，就是把无限列表中的有限个数据放到一个独立的排序列表（置顶列表），再对置顶列表进行排序操作。
所以，它的本质上就是有限项排序。
3.2.2 长期调整的排序
需要有一个随时可变的字段，来做排序依据。
3.2.2.1 ID或者创建时间怎么样？
一般情况下，对于列表，技术可能会直接使用的创建时间或内容ID。但尴尬的是，这两个字段在业务里通常不具备可变性。
3.2.2.2 那么更新时间字段可以做为排序依据吗？
回答是当然可以，但它有可能太灵活了。比如可能我修改一个错别字，这篇文章的更新时间就变成当前时间了，它也就跑到列表顶部去了。
3.2.2.3 直接加个排序字段如何？
也可以！但要注意：
这个字段要和置顶类别的排序字段区分。不然当这条内容一旦被置顶后取消置顶，它的排序位置就乱了。
-
这个排序字段需要倒序（从大到小，大的在最顶上），如果正序（从小到大），那么每发一篇新内容，所有内容的排序号都要更新一遍。
不过，这样做的确定也很明显
每次加入一条新数据，需要对先整个列表计数，+1后才是新数据的序号
各栏目序号相互独立，如后续有需要两个栏目内容合并，或两个栏目需在一个前台列表中展示，序号就可能会造成顺序bug
如果工作人员需要调整，他应该把想要提升的序号设成多少呢？（随手写一个很大的数吗？）
3.2.2.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 再处理正常序列
这里其实真实的使用频次相对置顶低很多，所以只要提供一个可更新排序时间的方法就行了。比如可以可在数据的单独编辑页面内更新排序时间，或者像更新序号一样，在列表中直接点击排序时间进行更新。
重要的是记得更新后自动刷新列表哈
思考结束~其实这里交互部分并没有深入的思考(～￣▽￣)～，所以如果有什么交互的建议，恳请在下面留下你的想法。一起探讨。
