我看抓虾

因一些机缘巧合，我关注了一下抓虾，归纳整理一下自己的体会。

很早就知道抓虾这个产品了，一直的认识就是这是一个RSS Reader，别无他。进一步，抓虾在媒体上的一概印象，以及对比等，都是和其他的一些Reader进行的对比，比如Google Reader（我认为这个目前是纯阅读器，但是以后变动的可能很高）。第一次知道身边的人用抓虾，是看到自己的Space中的统计有抓虾的引用，然后问某女得知是夏侯同学用的抓虾。然后就是最近的一些体验了。

言归正传，说一下我体会的抓虾。抓虾居然不支持我的Safari！这个很痛苦。于是，我只好改用慢得不行的Firefox。第一印象就是抓虾不仅是个Reader，还有分享和阅读的元素在里面。这让我想到了Digg。于是，我想看看是否可以订阅其他人的分享列表，结果发现不可，觉得这应该是需要加强的一点。

抓虾的思路很好，利用方便好用的工具这一特点，吸引用户添加订阅源，随后可以把这些资源加以再利用，推荐给其他的人来看，进一步丰富浏览体验。但是，如何可以更加有效的利用这些资源？抓虾采取的一个思路是把订阅同样内容的人聚合在一起，这样可以用户很自如的通过兴趣，以及源－用户－新源的方式来发现新的内容。可惜这个思路表现得不是很清晰，应该并不是非常多人采用这样的方式来进行探索发现。

我添加一个订阅，为什么默认是公开的呢？就不能是一个非公开的添加么？这个对用户隐私方面的尊重确实是差了一点，需要加以改进。

订阅了自己的Spaces，居然发现有11个订户，很是吃惊，我怎么不觉得有人在订阅我的呢？后来研究研究才知道原来都是2007年1月附近订阅的。

添加订阅比较舒服的是我只要直接输入网址，就会自动发现源，然后添加，这样，就避免了对RSS这个概念的教育过程。只需要和人说，这个可以用来订网站，就足够了。这也应该是RSS作为工具的本质。进一步，抓虾应该考虑做Firefox扩展，做IE扩展，为用户提供更多更方便的功能。目前来说，用抓虾的，还是极客类的用户比例大一些，他们需要的就是简单方便。当然，也可以把这部分用户扔给Google，抓虾就做下里巴人。

抓虾的小组的方式很不错，可以看到后就直接转小组，然后分享给其他人。只是，假若改进一下比如把打分机制等都融合在一起，少一些功能的堆砌，可能用起来就更舒服了。不知后台统计数据里面有没有这些功能被使用的频率数据，应当根据这个对UI进行进一步的改造。

说到用户体验方面，抓虾的体验给我的感觉不是很好。对Safari的不支持就不说了，我费了半天劲才把默认的新手共享给去掉。我很喜欢的，使用Google Reader的时候很熟悉的键盘控制阅读，也是无法体验了。其实，键盘控制是一个非常好用的功能，对提升用户体验很有帮助，尤其是RSS阅读器这样一个用户群中Geek比例比较高的应用。

下面说说最关键的点，就是用了RSS Reader后，就会发现我想看的Feed会非常非常的多，以至于多到超越了我对信息的处理能力。这样的事情也发生在许多人面前，文章不断被更新，新的内容层出不穷，那么，谁又能看完所有的东西呢？这样，带来的一个问题是，如何让好的，对胃口的文章浮现出来。我希望，这个能够成为一个核心的竞争力来做。针对读者的个性化推荐。

社区、泛社区的概念和形式

社区、泛社区的概念和形式
社区，特指虚拟社区，说的是网络上的用户由兴趣、爱好等自然组成的群落。

BBS，特指版面－文章、发贴－回贴这样的用户交流形式。

Blog，是属于个人的BBS，仅由所有者发布，他人只能回贴发表评论。

泛社区，说的是将互联网上一切用户之间的互动式交流都看作是社区中的交流，把网站（交流发生的地点）看作是社区的载体。

这里，我首先打击一下泛社区的概念。互动并不是社区，特别是一些网站中弱化了人的角色，仅提供了发言评论的功能，这不是一个社区。例子很多，比如网站的评论区，比如明星Blog和众多评论者。这些交互方式中，信息往往是单向传递的，并没有真正达成用户和用户之间的交流。

BBS，是虚拟社区的一个初级形式，主要表现为有注册的用户，信息都是有发布者，用户可以藉信息找到发布者并进行进一步的交流。用户关注的是和人的交流而不是仅仅为了获得答案。但是BBS中的交流颇具强制性，即版面为公共地区，在版面上发文就类似于公开演说，除非不看这个版面否则难以避免要接受这样的信息，由此导致了“广告泛滥”、“不雅言行”等问题。

Blog，拥有部分社区成分。主要是Blog所有者可以借Link、Trackback等方式和其他的Blogger发生联系，也即，Blogger之间的互动而不是作者－评论者之间的互动才是一个社区模式。因Blog突出作者，弱化评论的特点，许多评论者若有独到的见解，更愿意采用撰写自己的Blog的形式加以表达，这就是雏形。

说了这么多，都是陈述，没有一个结论，实在是对不住看客。在上面的叙述的社区表现形式和参与者的述求上加以结合，有如下的一些发展思路：

BBS社区应当包含对文章作者（主体）的特殊照顾，即在社区交互中突出人的因素而不是话题中心。BBS社区应当有一个有效的评分机制，让好文浮现。

Blog社区应当注重作者之间的交互跳转，对作者增加方便的引用功能。在评论上，也因鼓励将评论写成Trackback的形式，鼓励更有价值的评论而不是简单的“好文，很有道理”这样的回复。

至于泛社区，我认为只要脱离了人这个中心，就不是社区。假若一个社区依靠的是人贡献的内容而不是那群人所创造的文化来吸引读者，那就会有无数的转载，无数的垃圾信息充斥，从而失去了自己的特色。

探寻全站社区化的可能性

首先，这个站，指一个媒体网站，而社区化，指将整个网站作为一个互动的平台。

为什么要社区化？社区化可以提升网站的粘性，可以让用户贡献信息，从而丰富内容，吸引更多的用户。现在就先不考虑这个是否要社区化，单纯看看社区化的可行性。

内容管理系统(CMS)的设计和选型这里说了一些CMS的东西，大体上凑合可以作为这里讨论的基础。

归纳一下要求如下：

后台业务子系统管理（管理优先：内容管理）：新闻录入系统，BBS论坛子系统，全文检索子系统等，针对不同系统的方便管理者的内容录入：所见即所得的编辑管理界面等，清晰的业务逻辑：各种子系统的权限控制机制等；
Portal系统（表现优先：模板管理）：大部分最终的输出页面：网站首页，子频道/专题页，新闻详情页一般就是各种后台子系统模块的各种组合，这种发布组合逻辑是非常丰富的，Portal系统就是负责以上这些后台子系统的组合表现管理；
前台发布（效率优先：发布管理）：面向最终用户的缓存发布，和搜索引擎spider的URL设计等……
其中说的业务子系统管理方面，主要涉及的是业务流程，而其他的和一个社区系统没有什么差异。也就是，一个CMS系统，实际上就是在社区系统上加入了业务流程控制。这个业务流程逻辑，应该是可以根据需求加以调整的，而并不是固化不变的。

这里就考虑，是否可以将社区作为媒体网站的底层，而在其上加入工作流等模块，使之可以适应媒体网站的需求呢？从社区化的角度出发，我们应当鼓励用户来贡献内容，社区体系（或者Blog）是一个比较好的体系。而在前端进行呈现，完全可以用不同用户贡献的内容加以重新整理实现。这里，我们将网络编辑的采编职责分离，采，即提供信息，通常意义上的记者；编，即社区中的版主，控制信息的呈现。这里，还涉及到对信息的归类整理，设置关键词，分析关键词的层级关系。这个，主要是将零散的信息进行组合的需要，让信息可以通过多个Tag进行组合。用户在浏览某个产品的时候，就可以看到产品相关的其他信息。

关键点：

工作流在社区中的应用，让编辑、记者的工作可以在社区系统中以普通用户的身份完成。
Tag的分析，评分机制。
强大的搜索和关联能力。