内容排序产品与交互的设计思考在设计工作台（控制台、管理后台）的内容数据列表的时候，排序的需求是一个经常遇到的问题。但我们遇到的排序场景都一样
吗？使用者的真实诉求是什么样的呢？如何设计功能才能"真的"满足用户呢？1.排序的需求场景对于数据的排序，有大概有这些排序操作的使
用点：这些排序的操作需求，基本覆盖了大部分的排序场景。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.这个排序字段需要倒序（从大到小，大的在最顶上），如果
正序（从小到大），那么每发一篇新内容，所有内容的排序号都要更新一遍。不过，这样做的确定也很明显1.每次加入一条新数据，需要对先整
个列表计数，+1后才是新数据的序号2.各栏目序号相互独立，如后续有需要两个栏目内容合并，或两个栏目需在一个前台列表中展示，序号就
可能会造成顺序bug3.如果工作人员需要调整，他应该把想要提升的序号设成多少呢？（随手写一个很大的数吗？）3.2.2.4有更好
的方案吗？必须要有！个人建议，不要使用单纯的序号，继续用时间来排序。这里，我们可以建立一个新的字段（排序时间），数据创建的时候将当
前时间赋值给排序时间。工作人员可修改排序时间，前端按时间倒序排列即可。对比序号场景的问题：1.置顶再取消的排序序号问题。使用排序
时间，就不存在这个问题了2.加入一条新数据，对列表计数。使用时间也就不存在了3.两个栏目内容合并的场景。使用时间也没问题了4.
工作人员手动调整。直接用时间，也没有到底要设多大的疑问（想放到上面，就把排序时间设成当前时间就好了）3.3规整一下看看完整的需
求场景，我认为：有限排序用序号无限排序用排序时它们的排序优先级如下：有限项：序号优先、其次ID无限项：置顶序号优先、其次排序时间、
最后ID4.可选的交互设计方案4.1指导思路所见即所得：在列表中排序，排序结果需要实时反馈给操作人。4.2有限项排序交互对于
有限项，还需要区分项目数量（一个页面是否能展示完成）。不同的数量，因为需要考虑分页的情况，所以在交互设计上也需要做出区分。4.2.
1一个页面能展示完所有内容4.2.1.1控制台拖动对于控制台的这种操作，可以直接选择使用各类前端框架集成的拖拽组件，或者诸如S
ortable之类的前端拖拽组件直接实现。这个组件名字是我随手搜的这种操作的结果就实时展示在页面上了，给使用者很明确的反馈。是当前
的首选交互方式。4.2.2多个页面才能展示完成多个列表因为分页的存在，页与页直接的数据排序略有麻烦。不过我们也有两种办法：4.2
.2.1在列表里直接编辑序号既然不能拖拽，那我就直接在列表中暴露序号字段，让使用者直接点击修改。保存修改后立刻刷新数据列表，也能
实现实时的修改反馈。4.2.2.2提供向上/向下箭头供人点击排序或者担心使用者乱输序号（其实有3.3的排序规则，乱填也没啥大影响
）。也可以提供向上向下的箭头，点就完了。不过这里注意最好同时给提升至顶部之类的按钮。但这个设计有弊端：·每点一次，你的数据就变化
一次位置，数据如果比较多，真的操作起来会很烦只能说，不推荐这样设计（个人认为，哪怕让使用者自己填序号都比这方式方便）4.3无限项
排序交互我们再来看看无限项的排序。这里可以根据技术实现的分析，把整个列表分为前边的置顶序列以及后面的正常序列。4.3.1先处理置
顶序列可以通过给数据提供一个置顶按钮，把数据加入到置顶序列。置顶序列内，可考虑直接提供4.2.1.1的控制台拖动设计，或者采用4.
2.2.1的直接编辑序号的方法。4.3.2再处理正常序列这里其实真实的使用频次相对置顶低很多，所以只要提供一个可更新排序时间的方法就行了。比如可以可在数据的单独编辑页面内更新排序时间，或者像更新序号一样，在列表中直接点击排序时间进行更新。 |
|
