Yafei's Blog

关于瀑布「历史信息必须保留痕迹」的思考

最近对一款团队沟通产品很感兴趣,国内的一款类 Slack 的产品,瀑布IM。

坦白的讲第一次听说 Slack 时我是不怎么感冒的,第一反映是「有哪个团队会再单独需要一个微信/QQ 呢」,但一段时间之后的好奇心驱使,第一次体验的时候便完全被「俘虏」了,在我看来,Slack 根本不能单单的认为是一款团队 IM 工具,而是一款团队信息流整合工具。

借用前几天接受「瀑布IM」专访时我说的一句话,如果说在之前我们使用的那些优秀的服务是一个个超级英雄,那瀑布(类 Slack 工具)就是把这些超级英雄组成「复仇者联盟」从而发挥更大力量的「神盾局」。

好了,你看出来了,以上的内容就是在安利「瀑布」,下面进入正题。

偏(chu)执(nv)狂(zuo)的思考

在使用瀑布的过程中,我注意到了一个应该只有偏(chu)执(nv)狂(zuo)才会在意的问题。

在使用瀑布的时候,每一步的操作,比如应用的开启/删除/配置、频道的归档/恢复、用户的加入/离开,都会在频道中留下历史信息,大概是下图这样,而作为一个第一次体验产品的人,势必会留下很多测试信息,比如刚进来好奇随手发个「hi」、「哈哈」、「测试」,或者对应用的配置规则不熟反复的开启/关闭应用,再或者体验新功能留下的「xxx频道已归档」、「xxx频道已恢复」等信息,这些信息按照瀑布的规则是无法删除的,因此如果你体验完成想拉团队进来,但又苦于留下这么多测(la)试(ji)信息,只能另开新账户,抛弃测试账户。

作为一个勤(mei)于(shi)思(zhao)考(shi)的产品经理,由此联想到更深的问题:

  1. 作为团队协作软件,必须忠于「历史痕迹必须保留」的信息自由的理想吗?
  2. 如果上一个问题是肯定的,那么,作为一个新产品,在垃圾信息和历史痕迹之间,该如何做取舍呢?

![](~/屏幕快照 2015-09-02 上午4.54.52.png?r=62)

瀑布团队对历史信息保留痕迹的坚持

V2EX 中有一条规定,社区成员不能删除任何自己的回复和已经被回复过的主题,@Livid 对此的解释是「为了创造一个所有人对自己说过的话更加负责的社区氛围」。在这一点上我想瀑布团队应该也持相同的观点,在有一次用户群里有人问到如何删除频道时,其中的团队成员回答道「不提倡删除频道和消息,因为办公用的消息你不确定什么时候会需要」。

对于此观点我持保留意见,因为产品的设计者对于这种问题无论持哪种态度都无绝对的对与错,对「保留历史痕迹」是一种说不清的坚持,但从另一个角度讲,作为一个团队内部使用的产品,是否必须保留历史痕迹是否应该由团队的负责人自己决定呢?

关于瀑布内「历史信息保留痕迹」大概有这些体现:

  1. 频道不能删除,只能归档;

![](~/屏幕快照 2015-09-02 上午4.53.47.png?r=64)

  1. 系统通知信息(服务配置信息、成员加入/离开信息等)无法删除;

![](~/屏幕快照 2015-09-02 上午4.54.52.png?r=63)

  1. 刚开始的时候消息可以删除,后来很快瀑布团队就把规则改为无法删除,只能在一定时间内撤回,而撤回后会像微信那样在原消息位置下留下提示痕迹。

![](~/屏幕快照 2015-09-02 上午4.56.27.png?r=63)

问题

这就好比学生时期我们好不容易买到心爱的笔记本,怀着小心翼翼的心情颤颤巍巍在扉页写下姓名座右铭一半时圆珠笔突然坏掉墨水漏出很多在扉页,或发现自己写错位置了,再翻一页就是笔记本原本设计好的姓名座右铭位置。这个时候你怎么办?继续用下去,则对于大(chu)多(nv)数(zuo)来说都已经无法接受,丢掉?那又太可惜了,起码太浪费。

在瀑布的使用上我碰到的就是这样的问题,以至于在这里不得不承认因为刚开始的不熟悉或姿势不对,在或者是系统还不怎么稳定,在我初体验瀑布的时候留下了很多在我看来跟(狗皮膏药)一样的垃圾信息。这些信息无法被删除,而我如果拉新同事入伙的话,面对这么多的垃圾信息明显是降低他们的接受程度的,所以就不得不折腾一翻,重新去注册新的账户,开通新的团队。

不知道究竟具体有多少,但我想大多数初次使用者,都会面临这样的问题,这部分「吃螃蟹的人」往往是一个团体中最爱尝鲜的人,所以也是瀑布在各自团体中的「传道者」,因此作为传道者,我希望在花费心思推动团队使用某款产品时,我希望给团队成员看到一个最干净、整洁、好用的东西。

可能的解决方案及思考逻辑

  1. 重新审视之前对「历史信息保留痕迹」的坚持,看是否可以在完善删除信息操作相关权限及交互的情况下,打破「历史信息保留痕迹」的坚持,就像上文说的,如果说@Livid 对 V2EX 无法删除历史信息的坚持是维护一个开放空间的秩序,但在一个团队的协作空间中相对开放社区并不属于公共空间,因此对于私密空间的信息制度,选择权应该交回团队管理者本身。
  2. 如果坚持「历史信息保留痕迹」,但也依然可以分阶段实施。在新用户引导及全站界面交互不成熟,服务不稳定(误操作几率比较大)的情况下,暂时实行宽松的历史信息痕迹机制,比如频道依然不可删除只能归档,但应用的配置通知、用户的加入/离开通知允许删除。
  3. 待有足够精力去完善全站界面交互、增强应用稳定性,使新用户误操作减少后,再去施行严格的「历史消息保留痕迹」机制,这样会大大降低新用户在产品学习过程中留下垃圾信息的几率。
  4. 可以学习 Tower 的方法,新团队建立之后自动生成一个用于演示功能/新用户学习的项目,待用户全部熟悉功能之后,可以自主的选择把演示项目归档/删除。