为少数人准备的一款产品
发布日期：2018-06-21 08:35:59 +0000
虽然这款产品微信端用户量并不算多，但团队还是再次投入开发资源，为 Readhub 小程序 重新设计了一个版本。
这款产品几乎不具备火爆的潜质，传播路径单一，加上微信对小程序功能的限制，无法达到 抽奖助手 那样级别的用户量。
但 Readhub 还是传递了无码团队的产品理念，作为用户，也为我们自己提供了许多便利。 满足了看行业资讯的需求，节省了时间 。所以，它会一直延续下去。
如果你对这款产品有想法或建议，留言给我。
感谢你看完以上内容，以下内容是附送。
微信订阅号改版，不少人持反对态度。我觉得大家可以耐心再看看，等待一下后续版本的改进。
不少朋友特别怀念 Google Reader，但我觉得不过是在怀念某种错觉。这个产品从没好用过，也算不上一个高效率的阅读工具。 Google 的天才们一直到产品下线也没有一丁点解决产品问题的意愿，任由读完的文章一遍一遍的浮现出来。如果今天微信是这样，估计用户早就疯了。
在 Google Reader 的时代，发布(Publish)/订阅(Subscribe)机制并没有得到足够高的重视，至少呈现在产品层面还不够。Google 当然做了一次很好的尝试，但是很明显，这款优秀的产品被定义成了小产品，最后等来的是被关闭的命运。
人们怀念过去，是对现实的不满。但是，现在跟过去已经完全不一样。过去，没有那么多的内容源，通过 Google Reader 的阅读行为，对内容生产者是不公平的，内容源得不到任何有效激励。现在，内容消费的供需方都已经找到，也有了更多激励内容生产者的方式，这是巨大的进步。
另一个差异是，在 Web 端阅读的效率自然比手机端要高很多，而手机端的优势在于有更多的碎片式阅读时间和阅读场景，这时候再不断追忆过去如何之好，是抱残守缺。
有的时候，我也认为 Google Reader 比较遗憾，如果产品延续到现在，或许在移动平台能迎来爆发。更为遗憾的是 Google Wave，一次非常伟大的尝试，但是产品过于复杂，最后 Google 也叫停了这个项目。有的时候我设想，如果对 Google Wave 进行简化，是否会像 Unix 继承了Multics 那样，最终赢得用户呢？
另一个值得说的产品是 FriendFeed，在当时被定义成「个人信息聚合服务」，为什么要聚合个人信息？因为当时整个互联网的信息量跟今天相比，信息分散而且信息量总体并不大。如果按照今天产生的信息量，个人信息的聚合是没有意义的，手机就是一个聚合器。
但是，从早期的 IRC、电子邮件、Digg，到 Google Reader，到 FriendFeed，甚至是Paul Graham 的 Hacker News，这些产品形态都影响过微信和今日头条。对于微信团队来说，早在 QQ 邮箱时代就已经进行过各种阅读模式的尝试，这些尝试如今已经孕育出了两个成功的产品，一个是公众平台，一个是被外界忽视但是非常成功的微信读书。
现在被用户诟病较多的微信群功能，一直做的不够好。深层次的原因是什么呢？微信团队过于年轻，没经历过 IRC 的时代，如果他们深度用过 IRC，就可以把微信群做到更好。这也是为什么 Slack 能够把群聊天做好的一个客观原因。国外技术群体到现在还能从 IRC 上吸取灵感，而中国互联网上，IRC 从来只是骨灰级用户才用过的东西。
做一款依托订阅/发布机制的产品，是一个产品人的必修课（我认为的），也是内容型产品的入门钥匙。这也是为什么无码团队要做 Readhub 这样一款产品的一个原因。这个产品的想法植根于十年前，只是要适应新的场景。产品最后是不是成功都是次要的，重要的是要具备这种能力。
获取信息是人类的永恒需求。当信息量少的时候，聚合是有必要的。当信息量大信息噪音足够大的时候，过滤就有必要。当用户接受到足够多信息的时候，继续推给他们信息，用户会拒绝接受，这时候，就要考虑能否达到某种平衡。正如手机上各种应用不加克制的推送信息给用户，现在越来越多的用户不堪其扰，干脆关掉了推送通知。
当微信团队在这个时间点对公众号阅读形态进行改进的时候，我是有些欣赏的，这意味着他们还在不断进步。反观，作为行业从业者的我们，怎么就无法接受变化了呢？
题图：Marcel Duchamp
Poster after Self-Portrait in Profile 1959- screenprint
提示：如果想在自己公众号绑定 Readhub 小程序，这是 App ID：
wxd83c7f07a0b00f1b
一般一天之内会确认完毕。数量有限，先到先得。
延伸阅读：