如何理解消息列表

七月 2024-08-19 11:09:23

一、前言

消息列表是IM产品的标配，无论是类似微信这种C端沟通工具还是类似飞书这种企业办公工具，消息列表都是用户访问频率最高的界面。从一个IM产品的普通用户到IM产品的设计者，随着对IM产品的深入，我有了更多的认识。

二、从问题开始

1. 消息列表和联系人列表的区别是什么？

为什么IM产品要抽象出消息列表和联系人这两个概念？他们可以只保留其一吗？

联系人是是稳定的、静态的，消息列表是临时的、动态的。从业务上看，用户可以同时拥有1000个，或者更多的联系人，但是近期与用户有沟通的通常只是很少的人。

如果只有通讯录，用户不得不时刻面对大量的联系人列表，这种信息负载是没有必要的，如果只有联系人列表，用户则无法通过移除来减少列表的长度。

有了消息列表这个临时的视图，用户可以更方便的管理列表，强迫症的用户甚至可以每天阅读完消息并清空消息列表。

同时消息列表提供了良好的扩展性，我们可以将消息列表理解为一个为用户提供信息的视图，我们除了聊天消息以外，理论上我们可以通过消息列表向用户呈现任何我们想触达用户的信息，不妨大胆设想，消息列表是否可以插入广告呢？

理论上是完全可以的，消息列表的确具备这样良好的扩展能力。

2. 消息列表的排序策略应该考虑什么？

消息列表是用户访问最高频的界面，它的设计再如何用心都不为过。如何处理排序逻辑才能够让用户更加高效的接收消息？在我们的项目中，我们考虑了以下的场景。

1）收到新消息

当收到新的消息，用户想要的是立马看到这条消息，因此在消息列表上，当收到新消息后，我们将会把这条会话置顶。

2）在会话列表发起对话

当用户找到消息列表排序靠后的一个会话，并与他发生对话后，那么在这个时刻这位发生对话的联系人将是用户关心的焦点，后续很有可能继续与他对话，因此我们将会把这条会话置顶。

3）搜索或者从联系人列表找到联系人并与之对话

同2所述，在这个时刻这位发生对话的联系人将是用户关心的焦点，后续很有可能继续与他对话，因此我们将会把这条会话置顶。

4）用户主动将会话置顶

随着会话越来越多，尤其是每天的沟通对象非常多时，遗漏消息的情况就很难避免了。用户的注意力和精力是有限的，我们需要帮助用户解决这种不平衡。

会话置顶是一个行之有效的策略，置顶本质上是把选择权交给用户，让用户可以选择哪些会话时更重要的，这样用户可以优先处理重要的信息。

3. 会话太多了、消息太多了怎么办？

在我开始做企业协同办公产品后，我时常收到用户的反馈，会话太多了、消息太多了，处理不过来。通常作为一般的个人用户，很少遇到这样的问题，毕竟个人之间的沟通量总是有限的，但是作为企业用户，这个问题变得十分突出，有些岗位每天都要做大量的沟通，他们加入了无数个群、同时还有无数个单聊的咨询。为此我们做了以下设计。

1）会话置顶

前面已经提到了会话置顶，这里再次说明，它的确是十分行之有效的策略之一。

2）抽离“@我”会话分组

在用户加入的无数个群聊里，通过是否@我，将新消息做优先级排序，我们认为在任何一个群里，@我的消息相对于群里其他新消息对我来说是更重要的，如果时间有限，用户应该有限处理@我的消息。

3）抽离“未读”分组

通常消息列表非常冗长，往往是已读会话和未读会话混在一起，在这个大列表里寻找未读会话总是存在噪声的，为此，我们抽离出“未读”分组，将所用当前未读的会话单独拎出来，方便用户逐一处理。

4）抽离“稍后处理”分组

我们时常遇到这样的场景，收到某个消息后，我们不能立即给予答复，承诺稍后给答复，但总会忘记。为此，我们抽离“稍后处理”分组，用户可以将这种会话添加都稍后处理分组中，待处理完以后再移除，这样就可以避免遗忘。

5）允许用户自定会话分组

前面我们提供了3个定义好的分组，帮助用户解决几个场景的问题，但我们总是无法覆盖用户个性化的需求，对每个用户而言，他们认为重要的会话是不同的，因此我们提供了自定义分组，用户可以将自己的会话分门别类的管理起来。