一、豆瓣手机客户端
先看看豆瓣官方现在做了哪些手机客户端吧：豆瓣FM、豆瓣电影、豆瓣说、豆瓣活动、豆瓣Bookcart、对角。在豆瓣出手机客户端之前，我一直期盼有一个豆瓣的手机客户端，实现豆瓣Web上所有的功能。但是，当豆瓣陆续推出了一系列手机客户端之后，我先是觉得有点奇怪，之后理解这是正确的移动互联网手机应用策略。
试想，豆瓣如果真的出一个手机客户端实现其Web所有的功能，将会是何等的庞大，或者这个应用进入的首页就是“豆瓣电影”、“豆瓣图书”、“豆瓣音乐”的Icon，那既然这样，为何不分开来做各个应用呢？
二、豆瓣为什么要分开做各个客户端？
上面其实已经谈到了一些，个人觉得豆瓣将客户端分开来做主要的原因就是，移动应用适合这样来做。大家也都说移动互联网和互联网很不一样，这一点相信很多人都是认同的。
在手机上个人认为应用大致可以分为这样几类：
- 第一类：手机应用是Web内容的延伸。这一类应用中用户使用客户端，更多是因为其Web上的内容或者品牌认知度，比如NYTimes，用户会为了想在手机上看其内容而安装手机客户端；
- 第二类：基于手机独特功能组织信息。手机的独特功能除了电话和短信以外，一是照相，二是地理位置，尤其是围绕地理位置，可以衍生出很多的独特的应用（大家称之为LBS）。这类应用里面，有一些是之前Web应用所没有的，也有一些是Web内容在做成手机客户端时会引入的特性，比如Quora是社会化问答，其手机客户端就引入了位置元素，可以向周围的人问答，豆瓣电影可以查看周边的影院，所以从这个角度来看，从Web网站到手机应用的过程中，应用场景将会变得尤为重要，而这种场景也会使用户在使用应用的时候，有着相对明确的目的性，将应用针对这些基于场景的目的进行设计就显得尤为重要了；
- 第三类：基于手机的智能控制，这类应用目前数量还不多，不过个人觉得这个领域未来会有很大的发展潜力。
手机应用在很多情况下，不是简单的把Web内容合适手机去展示，需要更多的去考虑手机应用的使用场景和手机的特性。从目前大部分手机应用而言，大部分应用都在挖掘第二类应用的潜力和价值，以豆瓣来看，其有着大量优质的内容，这些内容当然可以打包成一个应用，不过不同内容在手机上的展示特性不同，在手机上和手机特性结合的点也不同，从这个角度而言，分开做应用无疑是最好的选择。
目前移动互联网领域的创业项目很多，比如陌生人交友的应用，估计国内可能都过百家了，从故事的角度而言，貌似有需求，故事也算圆满，但是这些真的能做成么？个人持怀疑的态度。
手机应用应该如何定位是个很大的话题，在这里谈谈个人的一些想法，欢迎大家探讨；
手机移动应用对于需求的把握应该从三方面去考虑：
- 一是应用场景，应用使用有没有很明确的场景。这个是做手机应用最核心的点，只有找到这个应用场景，你在产品设计时才能更有针对性；
- 二是在特定场景中应用功能的触发频率。比如优惠券，比如看电影买电影票，这些都是有着一定触发频率的；
- 三是应用本身对于用户的后续需求的满足。比如陌生人交友，有场景，有触发频率，那之后这些用户去哪呢？聊熟了上QQ聊？移动应用相比Web而言，被复制的门槛更低，那如果希望自己的用户能够沉淀一些无法被复制的东西，这些用户更本质的需求是需要去思考的；
最近手机上面出了很多基于地理位置的活动相关的应用，最近豆瓣也出了豆瓣活动，从活动的角度而言，创建活动肯定是在Web是最方便的，在手机上面更多的是查找活动，基于地点发现活动，分享活动，当然在手机上可以考虑的是更多的和线下结合的需求点，比如幸会的名片交换就是一个很好的切入点。所以在手机上做应用更难的地方是，是否可以发掘线下的需求点，通过手机应用来满足这种需求。手机应用绝对不是在Web网站功能前面加个基于地理位置的***就可以的。
如果你现在提供的是一个Web服务，在做手机客户端的时候，个人建议，不要只是考虑将整个网站制作成一个手机客户端，需要更多的去考虑你的服务解决了用户哪些需求，这些需求是否在手机上有个明确的应用场景（是否可以和手机的某些特性结合，比如拍照，比如地理位置），如果各个需求都有这明确的应用场景，触发频率也合适，那就可以考虑分开来做。
移动互联网机会很多，不过个人认为，要想抓住这种机会也不是很容易的事情，需要对可以和手机相结合的需求点了解的非常透彻，甚至你必须对于某个线下领域非常了解。做手机应用很容易，但是想清楚应用满足了哪种既有特定场景，有触发频率，又有后续需求的确不那么容易：）
（本文由天涯海阁授权转载，原文链接：http://www.web20share.com/2011/10/douban-apps-talk.html）
