月份：2010年11月

微博的产生和传播信息的形式虽比较新，信息量增大之后，会面临垃圾信息和重复信息的问题，推荐系统也会有用武之地。

在新注册之后，会推荐人气用户以供初始化，在SNS中常见的做法是导入邮箱或者MSN中联系人，或者像Kik Messenger手机客户端扫描用户的手机联系人。对于社会化严重的应用更需要利用已有关系网来完成产品初始化，并且再形成产品在关系网中传播，造成产品用户的指数型增长，像早期的QQ、邮箱或者手机这样一个个手动添加联系人已经不适用，用户也没有这种耐心。越多的朋友参与，用户粘度越高，产品的转换成本也越大。

而根据填写的籍贯、教育和职业资料推荐用户，这种方式都比较老套，社区化网络使用的形式不一定适合微博，微博是靠兴趣和话题将人聚合在一起，不像社交网络那样靠看看他人的相册和头像就决定是否添加为好友，起码微博的社交成分会更低。对于普通用户而言，或许只是一个类似于聊天和围观的工具，对于信息的获取存在机会主义，而更高端的用户是否会期望获得更有价值的信息。

从个人短期使用微博的经历来看，期望能fo产出信息质量高的用户，通常是查看该用户之前的发言识别，自己人为过滤。再者以专家为线索，查看专家fo的用户，再选择是否同样fo。微博本身也会设立官方发言人（比如新浪科技），这会增加运营成本，产生的信息过于大众化，同样能在其他媒体或者rss中获得的信息，官方发言人的价值就会减小。

新浪微博的产品比较零碎，功能多，有实际使用效果的少。推荐的人气用户看不出来有任何依据，个人关注的话题对于推荐的用户产生不了过滤。手动添加了标签之后推荐的用户价值也不高，单靠是否有共同话题和是否在一个学校不能立即评价是否fo，查看之后通常发现该用户的粉丝数比较少，要么就是发言质量不高。微博本身希望这些普通用户被fo，增加他们的用户粘度，而对于查看之后产生的失望情绪也有损用户体验。

新浪微博开发者大会中，王煜全提到的重复信息和类似于签到的垃圾信息确实烦人，个人并不关心这些陌生人去了哪里，对于纯转发而且已经阅读过的信息应该明确过滤掉。如果开发更专业过滤的第三方应用，每天显示最有价值的50条微博，也许会有不错的发展前景。

信息架构是一个整理信息，斡旋信息系统与使用者需求的过程，主要是要将信息变成一个经过组织、归类、以及具有浏览体系的组合结构。

手机与用户交互的过程，其实是信息的交互，手机和用户都在输出和输入信息，触摸屏和按键只是用户输入信息的方式。

Web信息架构包括组织系统、标签系统、导航系统和搜索系统，这些对大量数据的处理方法，和Web属性比较强（和互联网的数据库交互频繁处理大量数据）的手机产品，如wap网站、web app和部分手机客户端，这些方法也是适用的，只是由于屏幕和操作方式等手机的特点导致实现方式有所区别。

Web属性比较弱的手机客户端遇到最多的是信息的组织问题。导航系统通常使用手机操作系统中自带的控件，比如iPhone界面底部的标签栏。标签系统和搜索系统是处理庞大数据时才会使用，对于数据多是由用户手动输入的手机客户端来说，这两种系统使用较少，对于数据的手动分类是很初级的标签，比如输入手机号码时选择分类同学或者同事。

如Android手机中点击“拨号”和“联系人”进入的界面有拨号、通话记录、联系人和收藏，除了对联系人有按字母排列，还有非常实用的按联系次数排列，显示用户的常用联系人，可以满足个人90%查找联系人的需求。按字母、拨出、接入、未接和常用排序都是组织信息的具体方式。

再以Awesome Note为例，首页中间主体显示便签的类别及条目，包括新建、同步、编辑分类和增加分类等功能，界面整体还是以任务来组织。

整体设计在手机客户端中算是非常复杂的，使用个别的iPhone自带控件，功能繁杂，用户自定义能力强。界面设计美观，图标过于精致，有些图标点击并不方便，但界面组织结构逻辑清晰。

微博、浏览器、邮箱和SNS等国内常见的手机客户端首页多以任务分类为组织体系，具体体现在九宫格、表格和标签栏的组织界面方式，这也符合客户端操作方便和富交互体验好的特点。个人总结树形结构（或者称作等级式系统）有以下设计方法：

1.树枝之间尽量不交叉。像Web网站那样界面之间交叉跳转在手机客户端上非常少，保持结构清晰。交叉跳转的原因是数据量大，树枝及其繁多，返回上级在选择链接会导致操作复杂，也不宜发现内容之间非结构化关系。

2.控制分支的数目。首页显示常用的功能，不常用的功能放置设置中，有使用情景的功能分散到更低层的界面中。功能太多，会弱化最重要的功能，即使严格按照结构化的组织体系，用户每天使用在手机产品上的时间有限，难以花时间使用所有功能，也不要寄希望把电脑的功能照搬到手机上。

3.不重复，侧重某一分支。相似的功能可以考虑合并，在绝大多数情况下，功能都会有主次之分。就像文章举例的Android手机通讯录，按字母排序看起来结构清楚，但根据用户行为排序更能方便用户操作。又如2 DO重点使用主页，第一界面就能显示大部分的内容和功能。

4.保持分支相似性。树干下的两个分支相似，便于用户学习，尽量少添加新界面布局、操作方式和操作逻辑。即使视觉上效果很好，但是没有功能上的意义，也是没有必要增加的。

5.减少分支的层级。如twitter app中点击某条微博时，直接显示相应的操作，而不是像国内手机微博那样还需要跳转到下一级界面中。不提倡界面跳转的另外原因是，下一个界面还对文字内容没有意义地重复显示。结合1和5，web中的深广度平衡在手机产品并不适用。由于屏幕和操作的关系，面对大量数据时，首先考虑的是如何保证显示最重要的信息，而不是保证每一项数据都放在合适的层级关系图中。

6.充分发挥树干的作用。主页中的界面结构尽量不变，同样的结构可以出现在分支中，即使界面发展跳转，视觉平滑过渡，用户仍感觉当前界面是主页。如新浪微博右图，底部由标签栏可以不变为工具栏，界面中可以包含评论和传发功能（点击转发[1]和评论[0]），收藏和更多可以放到menu中，省去一个返回。

采用树形结构是自上而下的做法，先头脑风暴或者收集用户需求得到产品的主要内容，再绘制相应的组织结构。这种结构除了可以保持结构清晰并宜于用户查找，也能避免因逻辑不清导致后期的产品重构，保持良好的可扩展性。

LBS（Location Based Services）是确定移动设备或用户所在的地理位置，再提供与位置相关的吃、住、行和娱乐购物等信息服务。LBS成为信息过滤的方法之一，如大众点评网基于LBS的信息搜索。LBS自身也可能成为单纯产生信息的新平台和交友社区，如街旁的位置签到和贝多的交友。

LBS可以作为信息过滤技术，极大提高信息的精准度，但提前是信息本身和地理位置强相关，位置是重要的元数据之一。大众点评网在互联网上对商户信息的积累为手机LBS提供了原始的数据，已经形成良性的信息循环体系。使用“以任务为中心”大致可以分析以下几个子任务：

1. 选择商户。一方面需要收集大量的商户信息，如产品的影响力足够大，商户会主动提交；另一方面需要吸引用户评价商户，如餐厅的平均得分、平均消费和评价。这些信息在手机上难以完成，需要在互联网上的长期积累。
2. 查找并选择合理路线。如谷歌纵横和爱帮的公交查询，根据起点和终点查询出行路线和选择合适的出行方式。
3. 地图导航。初级的如在地图中查看步行方向是否正确，高级的可以结合GPS直接全方位导航。
4. 到达目的地，选择服务。如用户签到和根据其他用户的推荐来点菜。
5. 评价商户。享受服务之后用户再产生信息。

这些只是LBS最基本的功能，除了信息的初始化比较难，其余都比较容易实现。所以未来的LBS也会往深度发展。大众点评网在web2.0的概念下产生，由用户产生内容和获取内容，信息之间的内容属于平滑流动，在形成良好的饮食的口碑和用户粘度之后，也会走较为高端的文化发展路线，不再是简单的提供饮食类信息，还有可能更深入地影响用户的饮食习惯。

当产品能为LBS带来用户时，商户也会和产品深度合作，提供广告或者打折优惠等服务来吸引用户。用户在使用手机产品时，多是基于有明确的目的时提供可靠的信息，增加有效的广告的意义在于推销商户，使用户产生购买或者享受服务的欲望，用户、商户和产品三者之间又能建立起信息循环体系和盈利模式。

餐厅有推荐菜单，景点也有游玩功略。TouchChina 系列的景点导游app是提供关于地理的丰富信息，展示每一个兴趣点的位置、语音介绍、文字和图片，通过交互式的操作，为用户提供良好的伴游体验，虽然和LBS的结合还不是很紧密，但是这种深度服务也是LBS未来的发展方向之一。

而对比目前的街旁，还只是提供签到的功能，类似于微博的信息分享平台，但这个需求点在国内还太弱，缺乏像大众点评网那样的契合点，需要某些事件或者任务去引导用户使用。考虑到手机产品的使用情景，在和朋友一起外出时，使用产品查询和获取信息，再和朋友分享信息，大众点评网的口碑传播效果好。街旁是利用互联网的产品传播，签到可以同步到豆瓣、开心网和人人等社区和SNS网站，但是否通过分享能吸引其他用户使用还需要有待观察。使用的朋友越多，签到所得到的徽章才更有意义，街旁的早期的用户积累比较困难。

基于LBS的垂直搜索和深度服务会有广阔的发展前景，而相关的交友、单纯的签到和游戏发展局势还不明朗，也许会有不错的发展，但还不会发展成为主流的应用平台。