2022年4月

最近

如果不是媒体报道,完全没有意识到,朋友圈都已经10年了。翻了翻自己的朋友圈,最早一条是2018年的,因为之前的都删掉了,印象中被删的朋友圈,最早应该是2014年的,也用了8年。

极客公园创始人张鹏讲,他在十周年之际,与张小龙聊了聊,张小龙对朋友圈最满意的是:十年来朋友圈产品功能上,没有大的变化。

确实,一个十年没怎么迭代的产品,依然保持着旺盛的生命力,怎么夸也不为过。

本文记录一些看法,有些播客中有讲,有些是自己的判断。

1、

朋友圈众多功能的设计当中,如果选一个最重要的,我觉得是可见范围的控制,即:一条朋友圈下的评论和点赞,只有共同好友才能看到。

张小龙作了一个比喻,大意是讲:朋友圈就像一个广场,有很多个三五成群的人扎堆聊天,你在广场上闲逛,听到感兴趣的话题就聊上几句。

这里「三五成群的人」有个特点:两两之间互相认识。它从根本上决定了朋友圈的定位:重社交轻内容。——当然,实际应该是先有这个定位,再决定了这个设计,也更说明这个设计的牛逼之处。

大家可以想想,有多少次你在点赞的时候根本没有看内容,仅仅因为是XXX发的,你只是想与XXX社交一下。

潘乱的播客中提到一些问题,其实都可以从这个定位去解释,比如:为什么朋友圈默认不是ins那样的大图模式。因为大图模式聚焦的是内容,而朋友圈中内容并不重要。

2、

如果再选一个第二重要的,我觉得是默认发照片功能。即便后来支持发布文字,仍然坚持隐藏功能。微信有十几亿用户,我猜测仍然有很多用户不知道朋友圈可以发纯文字。

这个选择至少有两个好处:

  • 从生产端讲,降低创作门槛,无论小孩或是老人,也无论是否受过教育,几乎都能拍照。其背后的产品思想是,服务于多数人
  • 从消费端讲,有纯文字创作需求的人,很多时候是想发表观点,不够「生活化」,消费门槛高,不利于社交。想想你跟朋友在一起,是讨论观点多,还是讨论吃喝玩乐的多,而喝喝玩乐,一定是可以拍照的。

3、

第三重要的,则是坚持时间序。这是消费视角,与生产无关。

时间排序和算法排序没有好坏之分,依然是场景决定的。算法排序主要是提高内容的消费效率,但前面讲了,朋友圈的定位不是内容消费,而是社交,社交需要一定的确定性,每个朋友的每条内容都不想错过

按时间序刷,我们可以刷到上次退出时的位置,然后心里知道,这段时间每个人的动态我都看了,该保持联系的都点赞或评论了,这种确定性,算法给不了

当初朋友圈上线「跳到还没看的位置」时,就觉得把用户的心思抓的太准了:还有些人的社交工作没完成,跳过去完成它。

但时间序也有问题,如果朋友很多,朋友圈每天更新很多时,确实会影响消费(准确讲是社交)效率。单纯从社交效率讲,不同的人有亲疏之分,也有不同的社交目的,能分开处理更好。

关于这点,最好的解法是分组,每天看看亲人的朋友圈经常联系,偶尔看看客户的朋友圈维持关系。

很遗憾,微信没有做分组功能,只提供基础的黑名单能力,排除一些不必社交的人,以此提高社交效率。

我猜测不做分组应该还是基于「服务于多数人」的考虑。换句话讲,在提供黑名单功能的基础上,朋友圈的内容仍然多到半小时内刷不完的用户,非常的少。如果增加分组,对多数人而言,反而有设置的心智负担。

4、

timeline大幅提高了社交效率,timeline并不是微信的发明,此处只是记录一个观点:

在timeline以前,QQ空间,豆瓣,51空间等社交产品,用户的内容是以「空间」进行组织的,每个用户有一个主页,需要访问用户主页完成社交,也因此诞生了「互踩」的文化。而基于关注关系的timeline则彻底打碎了空间,按时间进行内容组织,在一个页面完成所有社交,大幅提高了效率。

对于内容来讲,再引入算法,进一步提高消费效率。每每想到此处,都觉得Google Reader的关闭是个遗憾,它完成有机会成为内容分发的巨头。

用了2年Obsidian,Logseq以前也知道并试用过,当时只有web版,稳定性差就没关注了。不久前看了Randy Lu关于Logseq的视频分享,被吸引到了,于是试用了2周。这期间只用Logseq,没用Obsidian。

现在,想基于经验分析下二者的功能差异及未来的可能的迭代方向。需要说明的是,这不是一个教程,但如果你正在试用这两个软件,并在犹豫选择哪一个,本文或许能提供一些视角。

这两个软件共同主打的特点是:本地存储+文本文件。这对在意数据安全、数据可迁移性的用户(比如我)来讲,非常有吸引力。

它们的核心差异点有两个:

  1. Logseq强制使用大纲视图,Obsidian是自由格式的markdown文档
  2. Logseq没有文件夹结构,Obsidian有文件夹结构。

一、首先讲讲自由格式与强制大纲带来的影响

Logseq强制使用大纲视图,其实就是block优先,先有block,然后block组成page,并且block还有层级的关系。

Obsidian自由格式,就是page优先,当它想去支持block的时候,只能从段落出发,每一段是个block,段落间当然也没有层级关系。(官方文档介绍:前后有空行包围的东西就是block)。

从通用性来讲,Obsidian的自由格式,其实兼容Logseq大纲视图。网上有很多人分享二者共用一个库的方案,无一例外的都是以Logseq库为准,然后让Obsidian去兼容Logseq,充分佐证了这一点。

以block为例,前方讲Obsidian的block是基于段落的,但大纲带也是支持的,如下图所示。

Obsidian大纲中的反向链接
Obsidian大纲中的反向链接

相比Logseq的block,Obsidian的block有两个问题:

  • Logseq能直接在反向引用中编辑和操作(比如点击链接)内容,Obsidian则必须跳转到原文档才能编辑和操作。
  • Logseq的#标签和``引用,都是作用于块的属性,通过query能直接查询到块,Obsidian通用dataview的query只能查询到page。

尤其是第2条,对task的管理非常重要。事实上,Obsidian的dataview社区已经在计划实现相关功能了。

再看看Logseq,因为是强制大纲,所以不适合写长文,有趣的是,Logseq社区呼声第二高的Feature Request就是支持长文写作

这个帖子对Logseq应该如何处理长文block给出的建议,就是Obsidian基于段落的方案。

按照这个畅想,Logseq支持定义page的类型,一类是大纲视图page,一类是长文视图page。

长远来看,Obsidian在自由格式上支持更友好的block是顺理成章的事,但Logseq在现有强约束的情况下去支持自由格式的长文,需要打破框架。不清楚Logseq团队是否会考虑支持长文(目前roadmap中还看不到),但这确实是我无法放弃Obsidian唯一的原因。

我个人比较期待二者最后殊途同归,Obsidian更好的支持block,Logseq打破框架支持长文写作。

二、再谈谈文件夹支持

这一点,同样体现了Obsidian对Logseq的兼容。

至于哪个更好,这个见仁见智,我倾向于Logseq简化文件夹的方式,减轻分类的压力。Logseq的页面支持namespace层级,可以实现类似文件夹的功能。但需要注意,这是非常定制化的能力,离开了Logseq这样的关系就丢失了,所以,如果考虑数据的可迁移性,这个功能应该慎重使用。

三、我最终的选择

我希望在笔记软件中写长文,Logseq无法完全替代Obsidian,虽然Obsidian的大纲能力比Logseq弱但也完全够用,所以本着少折腾的原则,继续使用Obsidian。但在使用习惯上,会把Obsidian中的daily note大纲化。

哪天Logseq支持长文了,会考虑迁移。也许那一天,Obsidian的block能力也能与Logseq并驾齐驱了。

最后,本文使用Obsidian写成。

相关阅读