豆瓣说和豆瓣的移动战略布局

“豆瓣说”是豆瓣于2011年3月末推出的“豆瓣广播”升级版本，iOS和Android的移动版也于6月末同时发布。相信也是受了Twitter和微博当下盛极一时的影响才有了“豆瓣说”，但豆瓣广播确实早就有了微博客的基本形态，没能早点走出这一步算是有些遗憾，不过我觉得目前也为时不晚。

先具体分析一下“豆瓣说”这款产品。

网页版界面

整体感觉上，豆瓣说的网页界面紧跟Twitter前卫的前端设计，尤其是点击某条豆瓣说的时候，侧边出现的叠加pane-outer层（这一点我在知乎文章里提到过），看代码是采用Ajax实现页面切换，页面内的各项元素用Mustache框架实现前端渲染。实时更新新的“豆瓣说”应该是通过Socket.io的Html5的WebSocket来实现的，有一个Flash模拟WebSocket的机制来保证在不支持WebSocket的浏览器上也能运行。

技术细节不算我的专长，不再多谈。

移动版界面（以iOS版为例）

小清新风格，图标都使用圆角的，看上去更柔和更精致（顺便提一句，豆瓣电影应用那种方头方脑，Window Phone7式的设计跟这个相比风格迥异，应该是不同的设计团队或者是外包的）。功能极简，只有下方5个按钮。分别点入，也最多只有1-2级的页面深度。操作逻辑简单易懂。

最中间的“添加新的我说”按钮是彩色的，核心功能得到突出。有新的“他们说”出现时，有一个红色的感叹号标记会出现在“他们说”图标上。没有采用常见的红色圆块加数字的做法，会让习惯了这种惯例的用户觉得陌生，我第一次看到这个标记，还以为是连接出现了问题。

值得一提的是，中间按钮还隐藏了一个快捷功能，长按的情况下会出现用于上传照片的快捷菜单：

这是我第一次在移动应用中发现类似的“手势”操作按钮，设计上很用心很超前，但是估计没有多少用户发现这个功能。不一定是豆瓣设计师首创，但或许有一天会成为流行的设计典范。

“我的回复”界面中，拖动时间线feed的效果采用了折叠抽屉式的设计（也被用在了“对角”的时间线feed里面），这是我非常喜欢的一个设计细节，拖动时的动态效果让人觉得产品做得很用心。

产品功能设计

与2007年就已经存在的“豆瓣广播”相比，“豆瓣说”增加了几项功能：

- 转播：相当于Twitter的RT，原封不动地转发别人的“豆瓣说”

- 赞：和从前Facebook的like键（现在已经接近等同于“reshare”），知乎的“感谢”是一个机制。只有作者本能会看到“被赞”的通知，给作者送去鼓励

- @：用@+个性域名提到某用户，该用户会收到通知

- 推荐照片：可以上传照片发布到“我说”

- 实时更新：最新回复的提示似乎还有问题，不显示或者不太及时

- “推荐到豆瓣”等同于“我说”

- 记录书影音之后可以“写一条我说”，否则这项活动不会像以前那样出现在广播中

豆瓣广播作为豆瓣的时间线feed，本来就接近微博客的模式，加入了这几条功能之后，和Twitter更像了。或许是因为搜索功能还不强（升级版的豆瓣搜索应该在开发中），#话题的功能没有实现。微博的私信或者Twitter的DM也没有以豆邮的形式出现，下次更新或许可以期待。

比较一目了然的问题是：图片点击放大打开加载的时间比较长；页高可以随页面下滚自动载入新条目而加长，但是缺少一个回到页首的按钮，可以考虑下次更新中在右下角空白处加入。

关于转播和评论

这一点我想挑出来重点谈谈。

豆瓣说在这一点上跟Twitter一致，跟新浪微博和人人网存在区别。豆瓣说的转播就是Twitter的RT，纯转发，不能加入自己的评价。但新浪微博和人人网都采用了保留上下文的形式(threaded conversation)，可以通过“评价同时转发”或者“转发同时评价”的形式。把自己从时间线feed里看到的内容，加入自己生产的内容后再次出现在关注自己的人的时间线feed里。

按照我个人的理解，这两种方式代表了两种对SNS内传播方式的导向性的态度。Twitter是崇尚简洁的媒介，定位更倾向于全公开化的短消息平台，140个字母的限制使得出现在时间线feed里的每一条tweet都必须精简，没有上下文使得对@某人的reply发出来的tweet让人看不明白。即使有第三方应用实现了上下文重组，但Twitter就是不做这个功能，它的导向不是鼓励群聊的，即使用于聊天也多是一对一的。但新浪微博和人人的导向不同，尤其是新浪微博，对上下文的保存使得每一条微博都有迹可循，转发和评论的计数更是对“热点话题“特征的原生支持，看到一段交流和碰撞，或者看到很多人都分享的热门内容，都会激起用户互动的欲望。所以微博和人人目前都可以观察到很高的互动程度。

我不理解为什么豆瓣说选择了Twitter的转推路线，同时还把评论的thread限制到原来的那条“我说”之下，这意味着豆瓣对评论的态度甚至比Twitter更加封闭化，更不要说像新浪微博和人人那样鼓励让更多的人看到评论或者对话的上下文了。或许是豆瓣很早就考虑过社区首页时间线feed信息过载的问题（比如早期更新中实现的把一定时间长度内“看过了xxx”的广播折叠到一起），担心评论进入时间线feed之后会引起问题。但是我认为本来就给人互动性不足的印象的豆瓣，应该积极果断地尝试新浪微博和人人的路线，以弥补自身不足。信息过载的问题可以通过其他的方式来解决。

豆瓣的移动战略布局

本文的另一部分简单谈谈我对豆瓣移动战略布局的观察。

豆瓣2010年1月就已经有了简单的WAP手机版，为豆瓣社区提供了完整的移动界面，读书和电影版块只提供搜索功能，音乐、同城和其他功能在WAP版中被隐藏。1年多过去了，豆瓣迟迟没有推出类似“人人”移动客户端的几乎涵盖所有产品的移动客户端。如果仔细看看豆瓣单独推出的针对某项产品的客户端的进程，这样的综合式的移动客户端或许永远不会出现了：

2010年2月初，豆瓣电台iOS版发布，豆瓣的第一款移动应用。

2011年6月末，3月末推出的豆瓣说的iOS和Android版同时发布。

2011年7月初，豆瓣电影的iOS版发布。

2011年7月7日，LBS应用对角在AppStore上线，虽然未被豆瓣官方承认为豆瓣产品，但是从风格和其他迹象来看，应该是豆瓣推出的产品无疑。

从这不断加快的步伐来看，豆瓣的移动战略的布局意向已经非常明显了。因为开始显得庞杂的产品线，推出综合式的移动客户端不再符合战略定位。针对豆瓣的各个产品推出独立的应用才是豆瓣选择的路线。值得注意的是，前三款是豆瓣对已有web产品推出的移动版，而“对角”完全就是一款LBS的移动产品，可以说和豆瓣现有业务是相对独立的。豆瓣选择不把“对角”正式列入豆瓣产品线，或许是想突破目前的用户群的一些困局。“对角”的用户和豆瓣的用户不可能完全相同，让“对角”保持独立性，更有利于针对有特定需求的用户，推出相应的服务。

另外值得一提的是，豆瓣电影的应用中也用到了LBS，按照离用户的距离对影院进行排序。或许这一块功能将来会和对角结合。

按照这样的逻辑推演，豆瓣将来应该还会推出其他移动应用：

豆瓣读书：在现有的试读功能的基础上，以移动设备阅读器的形式出现，在取得内容发布商（出版商）合作的情况下，甚至有可能建立Amazon Kindle一样的网上电子图书书店。

豆瓣同城：这款产品本身就很具有地理含义，在大城市已经做得很不错了，推出一款文化娱乐、活动出行指南应用也是很自然的。

豆瓣九点：本人很喜欢的一款豆瓣产品，但是看起来获得的豆瓣资源配置一直不多，产品长时间基本没变化，现在跟阿尔法城一起被打入首页“更多”的冷宫。或许跟着移动战略的布局，有机会成长为一款类似iPad类平板设备上Flipboard一样的网络杂志。

豆瓣团购：和同城休闲娱乐文化活动的性质不同，但和地理信息也直接相关，或许成为独立的应用，或许成为对角的一部分，如果豆瓣想让对角长得更大的话。

豆瓣小组：这一块是社区活动，独立出来成为app直观上感觉有些奇怪，但是不是没有可能。

这样一来，移动设备的普及和特有属性，能帮助豆瓣拥有更多用户，同时也为用户提供更好的体验；另一方面，豆瓣也能通过不同的产品的被使用情况增强对新用户和原有用户的认识，探索更有价值的商业模式。这正是豆瓣亟待解决的问题。

无觅猜您也喜欢：
互联网广告漫谈（中）	Visiting Zappos – a service company that just happens to sell shoes	必读书目云图	在帝都参加盲品游戏
无觅