Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

谈谈微信的信息流

Posted on 08/15/201806/23/2019 by 四火

最近才更新到微信的最新版本,早有耳闻公众号变成了微博似的信息流展示信息。之前也没有太在意,这次微信客户端版本更新以后,发现坏了坏了,以往的阅读习惯已经被彻底毁掉了。下面两图都是我手机上的截图,左边是新的信息流模式,右边是信息流界面下点击右上角图标,回到的 “类似以往” 的基于订阅号发布者的模式。

image1 image2

首先我要澄清的是,我认为信息流是绝大多数 SNS 软件都乐意采用的信息传递模式,简洁而且高效,包括我经常使用的那些应用,比如微博,比如知乎,比如 LinkedIn,甚至绝大多数 RSS 软件,因此,它绝不是一个新东西。毫无疑问,基于信息和基于信息发布账号(公众号)的方式比较起来,通常前者更有优势,但是此事不绝对,而且很遗憾的是,在微信这块地盘上,对于多数用户来说它恰恰就是一个反例。

别急,听我慢慢道来。

先谈一谈这方面的老大哥微博

为什么要谈微博?因为在微博出现以前,在国内你找不到一个像微博这样能够在非双向联系,而仅靠单方面关注中迅速扩散消息的软件了。它的革命性是在多方面都是毋庸置疑的。想想微博出现以前,互联网上消息要扩散有哪些典型方式?博客?显然无助于迅速扩散消息,而且作为快餐消息的载体明显不适宜。新闻?新闻只能说还是基于 Web 1.0 的模式,它和 Web 2.0 的最大区别是,普通的用户无法成为主要的信息创造者。QQ、MSN,甚至人人网?它们虽然差异很大,但是都是基于 “好友” 的方式,利用的是 “杀熟”,而非微博这种以明星为核心用户(与草根为核心用户相反)来决定的信息传递群体完全不同,信息扩散速度也慢得多。扯一句题外话,应该说,一般情况下,信息扩散速度越快,国家机器的审查就越困难。在这个信息爆炸的时代,最大的优势当然是信息自身。可是除了信息本身的价值,信息出现的位置和时机至关重要。利用时间来组织信息,把越新的信息越往上放,非常有助于实时性软件,或者接近实时的软件扩散信息。

于是,微博出现了。和其它成熟的 SNS 产品不同,在当时你根本不可能找到一个相近功能(相近功能是指上文所述)的替代品。但是,纯粹的基于时间线来调整信息优先级是有很多问题的。虽说从技术层面来看,这种简单的方式,无论是实现还是优化,都有相对成熟而且有效的方式。比如根据不同的用户量采用 push 还是 pull 的模式,比如采用从冷到热分级存储,等等等等,我在这篇介绍系统设计典型问题的文中曾经介绍过,举的例子是 Twitter。

最大的问题就是,对用户来说,信息重要性的衡量,绝不是一个简单的基于时间的逻辑。虽说越是实时的软件,时间因素的重要性占比越大。比方说,微博的时间线重要性,就要比 RSS 软件高得多。但是,重要性的衡量不能仅仅靠时间。微博有转发机制,这个机制保证了,热门的消息,即便不那么 “新”,它依然能够经常在眼前出现。而如今的微博和 Twitter,除了转发机制自身,都还有自己评估 “重要消息” 的一套办法,即便错过了,即便没有看到它的转发,它依然有机会回到你的视野里面。这个弥补,是一定需要引入基于用户特征的机器学习的,否则对于消息重要程度的的认知无从谈起。咱们暂且不论是转发机制还是这个额外的重要消息评估机制,它们毫无疑问都是对时间线弊端的弥补。

好,再回到微信公众号消息上面。

先看看基于时间信息流这一半

首先,微信公众号文章发布的实时性如何?有一定实时性,但是远没有那么高的实时性,也就是说,9 点钟的消息,我 11 点看到,也没什么大不了的。从这个角度说,基于时间的信息流,有益,但多数情况下并不能带来特别大的好处。而且,微信信息流优先级还不完善,用户更感兴趣的内容很容易被淹没在茫茫信息大海之中。

其次,微信公众号的文章数量如何?这是一个非常影响信息组织决策的因素。如果文章数量众多,那么基于信息流一定程度上可以提高浏览效率。或者说,如果有 1000 条信息,用户站在时间线的顶端,眼睛和手指一起工作,扫到了其中的 100 条,然后点开了其中的 10 条阅读,并对其中的 1 条感兴趣并完成发布者的关注。这听起来似乎是一个说得过去的场景。可是,如果没有那么多订阅号呢?公众号每日发布的文章数量是有限的,多数公众号每天就发那么一两条(其实这是微信非常有远见的一点,文章发布数量的限制必然督促发布者提高文章质量,而非单纯用数量来提高过目率,可是微信现在在抽他自己的嘴巴),而大多数用户,恰恰没有那么多订阅号,也就没有那么多需要一扫而过的标题信息块,他们更在乎的是消息的质量(这也是 “置顶公众号” 一条非常重要的功能,能获得用户置顶的公众号,想必在文章内容上有着特殊的认可)。但是信息流以后呢?文章质量的重要程度,明显下降。

再说说基于订阅号的这另一半

订阅号最大的好处,在于基于消息发布者的消息组织。比如说,我订阅了 20 个公众号,但是其中 3 个我特别喜欢,我希望不要错过它们每一条,这就是这一方式优势的一个体现。

这种方式完全脱离时间线了吗?并没有。普通公众号的排列,是根据最新发布消息来完成的,也就是说,勤奋的公众号,掌握发布时机的公众号,还是能够得以在非置顶区域占据一个有利的位置。当然,也只能占领一个位置,而且由于每日发布文章数量的限制,这种 “勤能补拙” 带来的收益,还是明显敌不过文章质量带来的好处。

这种方式还有其它缺点吗?当然。其中一条,毫无疑问它也被微信的团队认识到了,如果没有置顶,发布消息不那么频繁的公众号,特别是在订阅号较多的情况下,自然被积压到了下面,脱离了用户视线的热区。即便这样的文章质量再优秀,也很难敌国信息轰炸带来的淹没效果。

说了这些,你可能也感觉到了,如果微信的产品经理们(未必是张小龙一人的主意),我大胆猜想,他们都是重度用户(我们说一个优秀的产品经理得首先是一个产品的重度用户,这没错啊),他们都习惯于订阅大量的公众号,而且文章质量的层次对他们来说没有 “那么大” 的区分度,那么很容易就会走上信息流这样的传统路数上。但是,这就是 “重度用户” 们的短见,“越了解产品,未必就越能设计好产品” 一个绝佳的例子。

我猜,未来微信一定会回滚到以往的基于订阅号发布者的模式去。或者至少,给用户这个选项(现在这个点击信息流右上角图标的切换不伦不类,不但需要额外的一次点击,而且在切换后 “未读消息” 的功能也丢失了)。

从大的互联网 SNS 产品生态的角度来说,我是更希望看到多种信息推送模式的,信息流已经泛滥成灾了,基于订阅号的模式,其实本是很好的求异而生。

这件事又让我想起,在朋友圈中推广告等等的事情。朋友圈也好,公众号也好,腾讯自己先革的 QQ 的命,再把它做大,所以才有了如今微信这块大蛋糕。腾讯的产品经理们,敢于去革很成功的产品的命,我还是非常佩服的。但是能不能保持头脑清醒,明确核心价值,守住节操而不短视,犯了错又敢于回头,就是另一回事了。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 珍爱生命,远离微博
  2. 吐槽一下新浪微博网页版的 UI 设计
  3. 自欺欺人的故事
  4. 闲言碎语
  5. 幸运的时代

1 thought on “谈谈微信的信息流”

  1. Anonymous says:
    09/03/2018 at 3:33 PM

    这就是为什么我还在用 RSS 的原因

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme