[备份] 关于即时聊天的理解

八月初一次内部交流时整理出来的一些东西, 关于即时聊天的一些思考
讨论的立足点是我们当前的产品也就是简聊
我维护 React 社区当中想过不少这方面问题, 而且对我很重要, 所以把文章扒出来出来备份一遍

大致梳理了我在社区参与微博, 论坛, QQ 群, 微信群维护的一些想法
另外实时协作工具 Google Wave 对我的影响非常大的, 相关的一些产品我也考虑到过
问题的核心是, 不同电脑上的多个人, 持有不同的信息, 怎样交流更高效

另外对于产品, 我认为功能是用户需求和使用场景挤压出来的, 而不是设设计出来
在技术功底充分之前我很难准确做好这之间的压力的传递, 所以先不去讨论

---

从编程的角度, 聊天就是多个客户端之间同步数据(大脑通过 JavaScript 同步数据)
而且会是某个客户端发生了事件, 其他客户端需要同步
这样思考, 问题简化跟死板一些, 然后按照下边的思路走

切入点: 消息源, 参与者怎么互动

聊天跟论坛, 消息源的是流量聚集的首要条件, 比如发事情, bug, 请假, 工资这些
然后是其他成员如何参与进来而且不会流失, 不同的情况下会怎样

消息源

消息源, 一般企业用户只要事情多, 不愁没有消息源, 重点在消息怎么进入简聊
比如我看到一个 bug, 一篇文章, 我发布在哪里能达到我想要的效果
简聊是 group + timeline 的形态, 那比较重要 group 如何选择的问题
只有我有明确的 group, 消息发到简聊才有准确的意义, 比如设计的文章发在设计讨论
不算重要的问题, 但多少有点限制, 简聊是群组, 也就有左边侧边栏群组的限制

参与者加入

分成不同场景来讨论吧:

1. 首先发起聊天的人, 需要操心的事情, 消息发在哪里? 时间是否合适?
   这个在上边说了, 基于 group, 受 group 好处和坏处的影响

1. 首先参与讨论的成员, 怎么加入? 可能是从时间线上看到了, 回复一下
   一个问题他怎么找到这个消息? 因为有很多 group 需要事先加入, 才能收到消息
   接着, 他如果是只是加入很多个组等着消息, 会不会太干扰?

1. 其他的人, 看到他们正在聊天, 是加入聊天还是直接无视掉?
   消息可能相关, 可能不相关, 有那么点负担在这里, 稍微要考虑下

1. 其他有人, 看到他们在聊天, 但是有别的内容, 怎么办?
   直接插话, 会干扰到其他人, 聊天室两个话题一起聊, 串线很累
   包括一个话题跑题出来, 出现了两个话题, 话题分叉了, 会不会也串线
   剩下丢掉想法不聊的话也说不过去...

1. 聊天完了第二天或者几天, 想看当时的记录, 只有时间线太长没法看
   我们加标签, 加整理, 想解决问题, 但很容易交互太复杂, 开发跟用户都纠结
   而且前面说的消息源, 在聊天记录里是散落的, 本身很难整理

1. 比如 Teambition 里有个任务隔了很久需要重新做一遍, 怎么集齐相关人员
   在 group 的聊天当中, 有上边说的 timeline 太长的问题, 也不够方便

Point

上边的几个问题, 我主要是从论坛(thread/message 结构)回过头来对比的
技术社区交流的方式, 有论坛有 IM, 论坛线索清晰缓慢, IM 混乱但实时方便
但是曾经也有 Google Wave 结合两者, 而且也是以消灭 Email 作为口号的

那么我想说, 我们此前在 QQ 群讨论技术遇到的各种不开心的地方
由于简聊也是一款 IM 应用, 只是多了 group, 不少的问题也会重现
比如说聊的人太多, 串线混乱, 比如说整理不方便, 比如说干扰

还有比如基于文件讨论, Google Wave 里就是, 消息也可以是一个话题
既然文件是话题, 基于文件的讨论就是带文件的话题的讨论, 理解上简单
我觉得这个是单纯技术来说, 我理解问题的思路
不过因为 Google Wave 跟简聊是完全不同形态的产品, 我不能想太多

总之我觉得简聊还是会继承不少群组结构的限制
不清楚具体会怎么影响, 但认为有必要纳入观察考虑