今年的劳动节我又可以去其他地方度假了，最近烦心事太多，正好可以出去散散心，Nice~

这次去海南三亚，陪老婆看看亚龙湾蓝蓝的海和银色的沙滩~

所以，Google Reader的阅读共享网摘暂停几天，各位看官请见谅~

Technorati : 旅游, 海南三亚

上周末，去jiwai的会议室（地方真不好找）参加这次的UCD产品设计工作坊，从头到尾经历虚拟项目，效果还不错，从实践的角度开阔了我对UCD方法的理解，感谢白鸦和Angela为我们上了如此有价值的一课。

从今天开始不定期更新我的心得：

第一篇：从混乱中开始

种种原因搞的从一开始就很混乱，好像来参加工作坊的人（包括我）都没作足功课：对行业不够了解、对”图像搜索比价购物”这个概念不是很清楚、对UCD的流程不大明白等等，加上各自的工作背景，也许你可以想像到有多么混乱。

早上开场，白鸦介绍了一些项目背景知识后，在场的人开始组建团队分角色，本次工作坊集中在PM、BI、UR、ID等角色，有趣的是发现大多数人属于全能型，在实际工作中多数都是自己一个人做全套工作，划分工作职能可能是我们都欠缺的，有时在阶段最后还演变为人少服从人多的”群体智慧”。

我们就是在混乱的状态下进入市场研究这个环节，时间紧迫，10~20分钟要做好用户定位、市场定位及优劣势分析，且需理出一个吸引投资的项目介绍。这对我们打击很大，我们9个人分成若干组整理相应资料，当汇总到一起的时候发现根本合不上，使我们的产品目标打一开始就不是明确。

事实也证明我们存在问题，因为在接下来的用户定位一度导致我们发生分歧。

本阶段我的小心得：

1. PM（项目经理或产品经理）绝对不是执行层能做好的，一定得深入战略层，需要打一开始对项目负责，哪怕是分析后决定取消项目，绝对不能是一个谁让干什么就干什么的人。
2. BI很重要，分析行业数据及竞争对手很有用，不一定非得市场人员去做，UR一样需要，且需要多花时间去做，绝对可以影响后面的工作。
3. 过往经历的项目从来都是半路加入，没有从前期加入的经历，所以习惯从别人处得到足够信息而不去管信息获得的途径，这在UR是不正常的，需要自己去获得/分析信息、数据，然后通过后面的工作去验证。

p.s.我跟两个Tony一组，其中有一个是UCDChina Blog的Tony，当时太投入，居然都没来得及单聊~

Technorati : PM, UCD, UCDChina, UR, workshop, 产品设计工作坊, 以用户为中心

Related posts

• 扯：煎饼和用户习惯记录 (4)
• 从分析自己的需求开始扯 (5)

别紧张，只是CSS裸奔节又到了。

4月9日是今年的CSS Naked Day，每年到这个日子就会看到大大小小的网站、Blog去掉CSS样式表，让网站”裸奔”，故这天也叫”CSS裸奔节”。

这个日子是为了推广CSS及XHTML等W3C标准页面代码而设的，更能突出网站在没有CSS的情况下代码结构是不是够清晰，其实我的Blog是一个反面例子，去掉CSS后作为主体的Post列表出现的太靠下了~

我使用的是Aja Lapus做的Wordpress插件来实现的效果，也可以到CSS Naked Day页面去看其他实现方法。

最后，基于大家现在什么节都过的心理，在这里说一句：CSS裸奔节快乐！

Technorati : CSS, CSS Naked Day, CSSNakedDay08, W3C, XHTML, 裸奔

Related posts

• 原来是CSS Sprites呀 (1)
• 赶上CSS裸体节 (0)
• 用XHTML+CSS实现文章列表标题时间对齐 (3)
• 某活动体验，是我理解错了 (8)
• 昨日收集 - 开源并非激进分子的游戏 (0)

已经存在相当一段时间的网站，有业务也有部分用户，他所面临的其中一个问题是怎么完成业务目标（比如增加营收、扩大影响力等），这就面临一个用户转化率的问题，是怎么把现有用户转化为付费用户的？

所谓用户转化率，我指的是从潜在用户成为特定用户类型的转化率，比如注册用户转化率、活跃用户转化率和付费用户转化率等。

举个例子说说转化率的应用，通过付费用户转化率可以计算付费用户的推广成本：（例子来自2006年Topica的一本白皮书，有改动）

那怎么提高付费用户转化率？我能想到的有：

• 收集用户需求和跟踪统计用户数据
  以合理的业务目标做目标，改进需要有基础和方向：统计用户数据就是基础，可以挖掘用户的部分实际需求；接着需要不断倾听用户的意见，贴近用户需求就是方向。
  
• 优化业务流程
  以一定真实数据为基础，就可以进行相应的流程优化。以网上商城为例，用户在购买流程的每一步操作，从浏览、商品放入购物车开始直到用户下订单并支付完成，或在中途放弃支付，都需统计及分析。不断去优化流程，该精简的精简、该删除的删除，让用户更容易获得商品，增加更多的正向循环流程。
• 提高访问体验缩短用户决策时间
  从页面框架、图像设计、导航等到整个网站结构，让用户更容易得去理解网站的用途，更快知道自己该怎么去用，更快决定进入业务流程（用户体验这部分UCDChina有不少好文章可以参考）。需要说明的是 ，现在的网站产品越来越重视用户体验，但不应该是为了有用户体验而重视用户体验，而应该是为了完成特定的业务目标。
• 保持用户转化率
  要增长先保持转化率不下降，活动、优惠、促销、代金券等等都只是手段，保持后方能增长。
  
• 针对关键目标用户
  例如像书店，来的人虽然很多，看书人的也不算少，但是最后掏钱买书的却只是一部分。也许目标用户群很广泛，转换为注册用户的也不少，但实际会转化为付费用户的却很有限，寻找关键目标用户就非常重要，且随业务发展而变化。
  
• ……

当然上述也可以部分适用于提高注册用户、活跃用户转化率。

另外，网站需要根据自身需求，选用合适的转化率标准，比如我觉得：

• 一个论坛最好使用活跃用户转化率。
• 一个网上商城最好使用付费用户转化率。
• 一个交友网站可以用注册用户转化率。

其实说到底，我还是认为付费用户转化率的含金量最高，因为不需要再考虑后续转化率，这并不是说其他转化率没用，毕竟注册/活跃用户转化率对广告销售还是有很大用的。

终于写完了，这是近期令我比较困扰的事情之一，本文意在抛砖引玉，希望有相应经验的朋友可以（通过Gtalk/Gmail）不吝赐教，在这里先拜谢了~

Related posts

• 昨日收集 - 用户体验与产品管理(完整版) (0)
• 昨日收集 - 体验之美 兼记录一下5大UE心得 (0)
• 门户网站的RSS应用猜想 (0)
• 胡扯：红绿灯和用户体验 (9)
• 昨日收集 - 面向任务，还是面向信息？ (0)

1. 前传：对于Wiki和维基百科我是早有了解，05-06年的时候曾经先后用CooCooWakka和MediaWiki在94smart.com架过，基本都是玩两下就放弃了，当时好像是因为编写习惯和权限设置的问题。
2. 去年11月开始看《维基经济学》，可能是因为个人口味不同，这本书读到今年也没读完，也不打算继续读下去了。
3. 今年二月底公司开始培训新的内部办公工具（据说是EA内部使用很久的组合方式），其中之一就是用Wiki写工作报告，起先我很不理解曾在twitter上说：”有人听说过，用MediaWiki作公司内部报告系统的吗？”，言下之意相当的不屑。
4. 在看了大BOSS写的快速入门后，在Wiki填充内容，从[[给文档加链接]]开始，起初不适应Wiki代码，网上搜索了很久也没找到合适的所见即所得编辑器，最后只好继续手写代码，还好后来习惯了。
5. 我们需要把个人简历、联系方式及工作报告都填进去，就现在来看在Wiki里面写简历不是很舒服，所以我在Blog上写了个非公司版本的个人简历。
6. 起先发现在Wiki里面的图片好像都不直接加外链，多数都是连图片描述页，也许是为了方便其他人补充说明或评论吧。
7. Wiki好像不是用来发布纯文本重复内容的工具吧？我认为内部链接才是Wiki的王道，能连接内部内容绝对不考虑外部链接。
8. 使用Wiki一段时间，其间又看了些Wiki的相关资料，发现之前的部分理解有误，我很想收回之前说过的话，其实用Wiki进行工作报告是有实际意义的。
9. 公司的内部办公工具主要由内容发布/知识库、邮件、文件版本控制及论坛组成，MediaWiki架设的Wiki主要负责工作记录/报告、内部事项通知、经验分享及岗位培训等内容发布。
10. Wiki的优点在于强调文档结构化，在内部关联上处理得很合适，且用户不需了解复杂的代码即可进行超文本内容编写，牺牲了部分灵活换来了相对容易的协作。
11. 另外，Wiki可以作为Web版的文档版本管理工具，可以比对修改、恢复历史内容等。
12. Wiki的文档可以很开放，用来做知识库、新闻、个人资料、通讯录、Blog、Life Stream等都很合适，我现在就用Wiki来做网摘（并用ROR写了一个网摘的Wiki代码生成器）。
13. Wiki需要制定现实中的更新规范，比如谁可以编辑这里谁不行之类的。
14. 最近总是听见公司同事喊：把某某事情写在Wiki里。我觉得Wiki还是作备忘吧，并不能代替直接、实时的沟通。
15. 其实工具就是工具，不止是Wiki、CVS、SVN这些协作相关的，最后还是需要通过各种形式的直接沟通去解决冲突问题。
16. 幻想一下，如果在Wiki监视的页面可以通过im提醒就好了，邮件提醒还是比较不及时。
17. 我开始看好用Wiki进行内部网建设，因为贡献内容的用户可以非常多，基于工作原因大多数人都需要别人更好的协作、配合，所以贡献的内容可以比较靠谱。
18. ……

本流水账可以写完，多亏互联网有twitter的存在~

还好有twitter，让我可以随时把想法发出来，不用憋很久憋成blog，也许憋到后来都忘光了、没感觉了；还要感谢twitter，因为它丢信息不是特别的频繁，让我可以找到之前记下的内容。

Technorati : Wiki, 协作, 工作报告, 沟通, 知识库

Related posts

• 近期流水账：我和ROR的简单接触 (1)
• 近日热点：游戏和种子 (1)
• 研究笔记：美味汤Soup.io的分享体系 (6)
• 研究笔记：Twitter的简单分享体系 (2)
• 研究笔记：Pownce的分享体系 (4)

前一段时间一直在研究ROR，就想开发一些小应用，简单记一下这段心路历程：

1. 想做一个部门内分享资讯的webapp，用来分享图片、网页、文字，基本是想做个简单的twitter类应用。
2. 鉴于我本人对Ruby On Rails很感兴趣，twitter就是用它开发的，而且好像可以快速开发，就决定用它实现，版本是1.2.6。
3. 不动手不知道，ROR表面的地方真是很简单，可以快速做出一个原型，但是越深入越复杂，想全面点实现出来需要注意的地方还真不少。
4. ROR的学习资料还算挺多的，就是高质量的中文内容太少，我其实不是做技术的，只能用部分业余时间写代码，连学带练的拖拖拉拉写了1个多月才像点样子。
5. 就像《用户体验的要素》里提到的”永远不能发布的项目”一样，因为前期缺少足够的用户分析和功能需求，过程中还过分修改细节，不断加入特性，导致该项目一直不能正常使用。
6. 看到xdite用ROR快速开发Facebook App，使用CSS库做界面布局，心又乱了，想拿进行中的项目改。殊不知，需要做的事情很多，要装rfacebook的gem和plugin，要到Facebook申请key，又要熟悉Facebook专用的标记语言FBML，很多设置需要在虚拟主机上调试，Dreamhost又诸多不便，最后只能作罢。
7. 注意到Joyent提供免费的Facebook App空间，就去申请，若干天后通过审核。进入管理界面，傻眼了，超级复杂（如果有人觉得Dreamhost的panel已经很复杂就不用去试了），虚拟服务器配置好后，开始调试FBML。
8. 没有将现有进行中的小项目转换成Facebook App，只是简单测试了下，做了一个显示所有好友的列表，发现Facebook提供的接口很有限，同时也推翻了我的一个设想”开发通用应用，分别用Facebook、Google等开放平台优化，做成跨平台的应用”，因为有很多功能（如邀请、好友搜索/选择等）只能通过FBML实现，除非其他平台也有对等的实现，否则这个应用只能是FB专用，不是我需要的通用了。
9. 还是回到我想做的webapp上，考虑到时效性和同事的用户习惯，最后决定还是使用QQ群解决，之后公司又推广wiki协作方式，这个东东就不了了之了。
10. 我最后把这个webapp发布在Dreamhost上了，没人知道，也不打算公开，也许下次再想做什么的时候可以先看看这个，作为警示自己的工具。

是我太随意，总想用复杂的方式解决本来很简单的事情，好像是挑战自己的极限其实最多算没事找事吧。

其实还没有结束，这件事情的后传是这样子地：

• 想在公司的Wiki里发网摘，觉得每条链接又要拷贝又要手写代码太麻烦，就用ROR做了个抓Google Reader阅读共享feed并转换成wiki格式的小应用。
• 结果Google用的是Atom，只能引入了Feedtools，结果页面编码出了问题，绕了个弯子才知道是Feedtools本身的问题，手动打补丁后，终于解决。
• 其实这个功能完全可以用PHP的lilina或MagpieRSS解决，我又多此一举了~
• Ruby On Rails 2.0.2出来了，颠覆了1.2系的很多用法，很多特性更加吸引我，又想以后都把小工具用2.0去写，先从这个功能开始，有点无法自拔……

Technorati : FBML, facebook, ror, ruby on rails, twitter, webapp

Related posts

• Prism，WebRunner及WebApp专用浏览器 (0)
• 昨日收集 - 网站编辑日常工作 (0)
• 昨日收集 - 用户群多大才算大 (0)
• 昨日收集 - 很多网站实际上只是Web 0.2 (1)
• 昨日收集 - Yahoo! Podcasts (0)

进入正题，不知道为什么，最近一个月经常回忆起以前的经历，引起我回忆的是简历–要公布在公司wiki上的简历（其实也没什么东西），之前的经历像影片一样一幕幕的展现出来：

1. 上世纪80年代末90年代初，我还沉浸在FC（任天堂红白机）的欢乐中，那时就梦想自己一个人做个游戏出来，所以立志考上大学的计算机专业。
2. 1997年末，我还是只对电脑的使用感兴趣，主要还是电脑游戏，后来家里可以上网了，就对互联网产生了浓厚的兴趣，当然这时的兴趣完全建立在网站浏览和网上聊天上。
3. 1998年，高中学到Basic语言编程，从此对编程开始有兴趣，同年开始用VB开发牌类游戏，当时因不懂算法设计导致失败（后来发现绝不仅是因为如此），最后只完成窗口界面，曾为此自暴自弃一段时间。为了完成儿时的梦想，后来还是报考了一个学校的计算机专业。
4. 1999年，用记事本通过直接写HTML代码的方式，作了第一个超简单的个人主页，虽没有地方上传，还是喜欢上做网站，后来听说了网站空间，于是开始疯狂搜寻、使用免费空间，最后落户在myrice.com和heha.net。
5. 又因为从小喜欢听歌，曾先后做了纯手动更新的四个音乐类网站，其中有一个用RealAudio做的在线听歌网站、一个学雅虎的目录搜索、一个乐评资讯站、一个歌手资料站。
6. 1999年9月，上大学了，在学校学到C语言，发现遇到了一个喜爱的程序语言。
7. 遇到一个可以免费得到CN域名的机会，代价是付出自己的网站，将所有权交给某域名网站，最终没有签约。
8. 1999年底左右，在网上看到一个叫做什么社区（也就是后来的交友加强型BBS）的网站，是用ASP写的，发现确实比纯网页有意思，于是开始寻找支持ASP的空间，未果，发现自己正在使用的空间（就是香港的heha.net）支持一种叫PHP（那会还是PHP3呢）的程序，好像跟ASP差不多，学习过程中发现语法与C极其相似（这也是我一直喜欢它的原因之一），后来用PHP完成了文件型留言板、图形计数器等若干小应用。
9. 2000年吧，找到免费解析一年顶级域名的某国外网站，注册域名yorso，网站取名乐索（不是勒索），做了我最后一个音乐网站。
10. 2001年，用PHP和Mysql做了一个音乐社区雏形，包括歌曲库、文章发布、资源搜索、会员注册/登录、论坛（最终没完成）等，当年因为联系的站长多数不愿意分享自己的资源，所以最后还是失败了。
11. 2001年底，在网上偶然找到一个叫有个网的国内PHP虚拟主机提供商，正式注册了自己的域名94smart.com，架起了一个仅包括近期更新的纯个人网站。
12. 2002年初，大学快毕业了，找到在某知名游戏公司做网站的工作，头一次知道正式的网站制作要经过的流程，以前自己实在太作坊式了。发现页面设计、JS脚本和Flash都很有学问，所以曾下过一些工夫学习。
13. 2002年底，开始深入学习CSS，以前虽然用，但是没系统学过，发现这个确实是处理页面样式的好方法。
14. 2003年，离开上家公司，到某门户网站游戏事业部负责网站工作，我被大公司的内部工具震到了，例如支持大型站点的CMS、图片负载均衡、站点同步等等，很多工具确实可以提高效率。
15. 2003年底，开始接触Blog，自己空间里架过几个，没玩出什么，暂时淡忘了。
16. 2004年，开始接触SNS，下半年使用Drupal重新架设了Blog，正式开始写Blog。
17. 2004年底，因为种种原因开始思考工作方式、目标的改变，第一次给领导写建议并获部分采纳。
18. 2005年初，与公司UE部门合作工作，开始认识到UE的重要性。同年开始更加关注UI、UE。
19. 2005年下半年，与技术人员一起进行玩家Blog项目，上线后因部门不重视、缺乏推广等原因搁置。于8月离开该公司，顺便回家整理自己的思路，写成建设计划提交给下家公司。
20. 2005年第三季度至今，加入现在的公司，继续从事网站建设工作，任网站架构师。
21. ……

写完发现有点像简历……有些事情印象不深了，还有些事情是混在同个时期一起进行的，所以可能年月就记错了，反正主要是写给自己的，无所谓~有些经历过个七、八年，回头再看的时候，可能已经不重要了。

重点是有个目标，为实现目标需要进行一系列努力，可以学到一些技能，获得其中的经验，之后可以更贴近目标，而且越深入越能发现需要补充完善的部分，经验如此循环积累下，总会有个结果。还有一点很重要，就是在需要的时候一定要和别人合作，只有这样才能更专心于自己的目标。

我发现自己的梦想好像太多了，从不切实际的到比较靠谱都有很多（就不写出来了），好像跟我广泛的兴趣有关系，当兴趣上来了就会产生相应的梦想。

我不想放弃梦想，也许现在没有能力没有条件去实现， 但那只是暂时被封存，如果以后有机会我会努力完成它。

Related posts

• 昨日收集 - 王建硕: 客齐集的商业模式 (0)
• 昨日收集 - 概念的狂欢 (0)
• 昨日收集 - 改进blog评论部分的10点建议 (0)
• 昨日收集 - 我们要做什么样的BSP (0)
• 昨日收集 - 微软Live与Web 2.0 (0)

在这场灾难里，有被雨雪压倒的房屋、堵在高速路上的车辆、无法回家的外地务工人员和能源物资缺少的城市……

他们最需要什么？我觉得应该是摆脱困境的方法及各种实在的援助、支持。

最早知道谷歌春运交通图，是通过白鸦的twitter和blog，后来才看到谷歌黑板报的文章，春运交通图是一个架设在谷歌地图上的特殊标注及内容，整合交通线路、天气预报等相关资讯，确实很全面很强大，但这又有什么用？

后来收到飞递（Feedsky的中文名）话题广告的邀请信，才知道谷歌在大力推广这个春运交通图，还冠以公益头衔。

我的第一反应：哦，原来是谷歌的商业行为。

想法未免有点偏激，但是我认为公不公益得看发起人以及动机，虽然公益不排除商业行为，但是跟赤裸裸的商业动机（比如大雪无情，卡巴有情）还是有很大区别的，公益不应该建立在”使用谁的产品”这个基础上。

ok，不扯了。

最后，我所能做的除了在这里说说，只剩下祝福，祝福受灾地区的人们早日摆脱困境、能够在家欢度新春！

Technorati : Google map, Guge, 春运交通图, 橙色关怀, 谷歌, 雪灾, 黄丝带

Related posts

• 昨日收集 - 用户贡献内容还是竞争对手贡献内容 (0)
• 昨日收集 - 交互设计：不是什么和是什么 (0)
• 昨日收集 - Google和谷歌 (0)
• 近日热点：游戏和种子 (1)
• 转发招聘信息会不会成就话题广告？ (2)

我在上篇Blog里曾表述过”单纯应用类和社区类的网站，现在有且仅有两个选择，要不自己做大做平台，要不就做成适合开放平台的纯应用“的观点（除上述类型网站外其实还包括资讯类的），大多数网站现在都面临同样的问题： 开放平台还是开放应用？

随着最近Facebook Platform、Google OpenSocial、搜狐博客开放平台等的出现并逐渐发展，Slide、Rockyou!等应用提供商的崛起，网站运营人员不得不去面对上述的问题。

后Web2.0的思想，使资讯类、应用类网站在逐渐增强社区氛围，社区类网站在不断增强互动资讯部分，趋势是互相融合的，成为趋向交互的网站。

这也造成网站系统的重复劳动过多，几乎每个网站都有自己单独定制开发的用户系统 、好友系统、交友网络等等，使得网站操作复杂，用户永远需要去适应体验上的差异。

不管开放平台还是开放应用，都可以解决很多问题，同时精简自己的应用结构，根据网站定位更好的发挥自己的特长。

当然，开放平台并不那么好做的：

• 首先平台网站需要有颗包容的心，允许别人的应用借你的平台发展。
• 需要提供功能全面的接口，让应用可以很容易结合到平台上。
• 需要有良好的用户基础，用户数量级够大且用户素质有一定保证，要不没有应用会来。
• 像Facebook、Google这样本身就很强大的平台并不在多，还没有跳出来的也屈指可数了。
• 用户数据的所有权成了最大的死穴，平台如果不能照顾应用的利益，早晚被应用放弃。
• 受应用欢迎的平台标准也会逐渐提高。
• ……（想到再补充）

开放应用稍微容易实现一点，但也有好处有坏处：

• 最大的优点，可以跨平台吸收用户，让不同平台的用户存在于同一个应用下。
• 不影响现有网站运行，可以为特定平台开发定制应用。
• 因为要适应各平台接口特点，用户体验可能与源网站不统一，或各平台间体验存在差异。
• 应用的模块化标准有待整合，现存标准缺乏通用性。
• 怎么将平台用户转化为应用用户将成为网站运营的主要研究课题。
• ……（想到再补充）

话说回来，不管开放什么，多平台鼎立的形势已经出现，在应用数量相当的情况下，主要看用户对平台的喜好，而应用已经不能再左右用户的选择了。

对个人用户而言，在熟悉的平台下使用感兴趣的、新的应用，将成为平台网站的主要体验，哪个平台相关方面做得好就可以脱颖而出。

还有一个可能发展的方向，用户基于现有个人网站（Blog）自建平台，维系用户的（社交）关系，将开放应用自行整合。用现有工具已经可简单实现，例如OpenPNE等开源软件、老冒的OPSN项目（我最感兴趣~）等等。

最后，借用一句互联网的名言收尾：未来是如此的不可知，互联网的发展更是如此，也许事与愿违，就当是2008年第一个月的某个白天的胡思乱想吧~

最最后，洋洋洒洒的写了一大片，一篇东西居然写了几个小时，中间经过很多琐碎的事情，可能会觉得驴唇不对马嘴，我还是感谢您能坚持看到本文的最后~^_^~

Technorati : Application, Facebook, api, google, opensocial, opsn, 开放平台, 用户体验, 网站应用

Related posts

• 近期流水账：我和ROR的简单接触 (1)
• 昨日收集 - 专业博客还是私人博客–兼谈百度空间和donews广告门 (0)
• 昨日收集 - 谁是规则的制定者 (0)
• 昨日收集 - 说说123体 (0)
• 昨日收集 - 让用户尽快离开自己的网站 (0)

今天，就在刚刚，想起最近一段时间经常在用Facebook类网站（还包括海内等），比较关注相关八卦，趁现在有感觉赶紧趁热打铁地写出来：（BT思维，所以跳跃是免不了的了~）

• Facebook值150亿美元？一批人、一批网站马上坐不住了~
• 买了本译言翻译的《Inside Facebook》，中文名叫《从零到百亿Facebook创业故事》，但看了看大半部分是一个前员工在爆内幕，并不是什么创业故事，估计标题极有可能是出版社编辑改的。
• Inside Facebook里面说：poke这个功能原意是暗送秋波，是用户间的一种挑逗。
• Inside Facebook里面还说：网站有一个早期复活节彩蛋，可以让某人发送短信求爱，如果对方同意的话回复将是对方的房间号，确实是挺刺激的一个隐藏功能。
• 看来Facebook也是靠ONS起家的，这个国内的校友录类网站应该学不来吧？
• 据说，Facebook不只是Paypal黑帮的，它的早期资方就有美国情报机关方面的投资公司，让人产生对用户隐私的不安全想法。
• News Feed和Mini Feed是Facebook重要特点，News Feed更变成现在SNS的默认配置，Facebook类的就不用说了，Linkedin、Orkut将用户首页个人消息改成了这样，国内的Wealink也跟进了。
• 印象中，这个小花招早在以前的个人主页时代已经被站长们用过了，就是网站更新记录类的东西。
• Facebook率先推出基于SNS的开放平台，让各应用网站通过API，用自身功能分享Facebook的流量，也催生出了一批专门开发Facebook类应用的公司，例如rockyou!、slide都有风投支持，开发了多款受欢迎的应用。
• Google推出开放平台了，搜狐博客也有开放平台了，新浪游戏频道变游戏服务社区了（这个有点牵强~）。
• 看起来，单纯应用类和社区类的网站，现在有且仅有两个选择，要不自己做大做平台，要不就做成适合开放平台的纯应用。
• xdite用ruby on rails非常快速的作了一个Facebook的应用，震撼到我了，原因是如此容易即可进入Facebook。
• 校内的广告北京的公共汽车上有很多，看着怪怪的，于是有人指出是因为Logo太像杜雷斯了~
• 王兴说校内是照着Facebook外观做的Myspace，海内流的才是Facebook的血？看来血战在所难免了。
• 海内确实挺Facebook的，比如没完没了的打招呼和回复。
• 恶搞某内的好像也不少，至少有qiangnei.com和qiangne.com。
• 百度很早以前就开始布局了，最近有消息称要和教育网合作Facebook类的社区，锁定各大院校，又一个披Facebook皮的。
• 好像就在上述消息公布的同时，腾讯公布了不知道哪条产品线上的个人档案测试版。
• 关于Facebook的八卦还在继续……

一口气写这么多也够八卦的了，下次再说~

Technorati : Application, Facebook, hainei, sns, xiaonei, 校内, 海内

Related posts

• 昨日收集 - Web2.0的技术本质 (0)
• 昨日收集 - 我最喜欢的商业模式 (0)
• 昨日收集 - 谁来定义“流氓” (0)
• 昨日收集 - 让用户尽快离开自己的网站 (0)
• 昨日收集 - 让你的Web交互更有快感 (0)