昨天问了关于豆瓣9点的流量问题,得到了很多网友的分析。我个人觉得其中比较合理的解释是误操作,如果豆瓣在文章标题后面放一个“展开全文”的标签,那么到我这里的流量应该有显著的下降。但是,就这么把问题草草打法掉,实在是很可惜。
我看到有网友回答说,看了RSS订阅的内容,却还要跑到源Blog上看一眼的原因是想看回复。于是我想,如果豆瓣有Blog的API接口,允许在豆瓣9点里直接回帖会如何呢?同时,在抓取RSS的时候,自动匹配评论的RSS内容---至少在Wordpress架构下的Blog是有这两个输出的。那么,豆瓣9点可能就成为了一个Blog交流的超级平台,也利于豆瓣粘合用户。
但是我又想到了另外一个问题:如果有天电子书可以折叠,可以随身携带,甚至可以翻页,人们是否就不需要纸质的书了?怕是不会。即使电子书的精确程度已经可以乱真,但是读者还是会想弄一本纸质书来。就像RSS的内容哪怕和源Blog完全一致,但是还是会有人愿意跑过去看一眼。人性是件很奇特的事情,有时候逻辑和理性在它面前无能威力。你可以用公式推导出一个人应该如何如何,但是和实际如何如何往往是两回事。认为人的行为都服从理性和逻辑,那不过是为了方便而做的假设而已。
回到豆瓣9点,它的出现应该是有两个目的。一是加强豆瓣用户之间的互动,Blog的更新速度要比影评书评快得多。评论文字是很外在的东西,说千道万,人还是对人本身有兴趣。另一个就是筛选信息。Blog爆发性的增长,造成了信息的过载。一个网民如果愿意,那么他完全可以用自己的阅读器订阅上万个RSS。豆瓣9点采取粗略分类和Digg的方法,试图过滤这样的巨量信息,为用户提供有用有趣的内容。
就目前的情况看,实施下来并不是很理想,我的流量就是证明。豆瓣9点的二套,每天被顶上来的来来去去也就20多个人。当然,他们的Blog可读性比较高。不过,这样并不利于发现其它的Blog。豆瓣9点采取的平衡方法是侧栏滚动,在里面现实最新被推荐的文章。可这种方法究竟能起到多少效果让人疑虑。对于这个问题,抓虾做得比较好。它把Digg分开来,有最热的,也有最新的,而且加了屏幕顶端的滚动条,滚动显示现在有什么人订阅了什么RSS。
细分的方法当然可以使得内容更为具体,不利之处是增加了用户体验的不便。一个页面内如果有太多的功能,那么用户就会觉得有压力,觉得网站太过复杂。不那么做,每个频道里的二、三十个Blog就成为麦霸,永远占据频道,让新鲜人无法发出声音。我起先觉得这可能是个技术问题,总能够通过技术手段予以解决。但是现在我不那么确信了,因为那么聪明的抓虾和豆瓣人都解决不好,说明它和技术的关系不是太大。
Web2.0的兴起,解决了信息的提供和组织问题,让每一个网民都可以投入其中。但是,过载信息和冗余信息的过滤问题,到现在我都没有看到一个比较完美的解决方案。意识到自己智力上的这种穷尽,不由得觉得十分灰心。
做一件最贴身的衣服给你,你会觉得穿着很难受。
因为谈到技术问题,我想说几点.
1. Blog的API接口
现在的blog系统API都不规范,真正支持meta blog的并不多,而且即使开放API也各有各的实现方法,对于豆瓣来说,要掌握住各门各派的武功路数确实不容易做到.
2. 在豆瓣9点直接读/写blog帖子的评论.
同样的,这点也不容易,还是一个规范的问题.像QQ空间,它是适用一个特定的RSS来返回关于某个帖子的评论内容的,但其他的blog未必会这样做.
我本人就是属于那种在9点看帖子却从来不会点进去的人.这也是我第一次在这里回帖,说的不对的还请见谅.
评论接口的问题要真能解决,那真是伟大了。
就最近互动性网站审核的风波,眼前就能想到一个应用实例:评论托管。
俺们不是没时间24小时查看回复,删帖封贴嘛。把评论托管给服务商,有人集中看,集中删帖就是了。原博客主题作全文引用,回复留在托管处随时管理。
纯技术点说,还是一个数据放在哪里的问题,RSS只解决数据引用交换的问题,不解决存储,所以不仅仅是API那么简单。豆瓣RSS引用下的的评论数据到底是留在豆瓣?还是留着博客数据库里了?还有个权限的问题。数据属于谁?
怎么显示,怎么输入倒在其次了。
:em19: