http://blog.94smart.com 持续关注用户体验、信息架构 Mon, 12 May 2008 16:56:07 +0000 http://backend.userland.com/rss092 en 北京不是第一次震了，远的有唐山大地震，近的有张北地震，但这次给我的印象最强烈。上次张北地震我在北京也赶上了，但不如今天这次震感强。 今天下午两点多，我正在22层楼的办公室为某几个数据头疼，突然我觉得头有点晕、椅子在颤，我努力想扶着桌子站起来，但是失败了。 我第一反应是不会是过劳要挂了吧，差不多1分钟以后才站起来，这时附近同事也都感觉刚才地在震，接着twitter上有好多人说"我们这里地震了"，之后QQ群被"地震"炸了窝。这时我们才知道地震了，一时间多个城市被点名，最后确定是四川汶川为震中的7.8级强烈地震，北京等地只是有震感。 "地震"注定成为近期的热点关键词，经过门户、论坛、搜索引擎、IM、twitter、Blog等途径广泛传播，网民成为最快获得信息的人，但弊端是谣言满天飞，可能会极大影响人们的正常判断，还好地震局反应快速，要不后果不堪设想。 p.s.基于人工神经网络理论，地震历史数据可以用来训练模型，但是这个模型可以准确预测地震发生吗？现阶段可能还不行吧。 晚上听着CCTV新闻台（别的新闻台看不到），都不知道自己怀着怎样的心情在刷着USGS四川地区震情列表，每当刷出一条地震信息，就有一种难以言表的郁闷，还好现在（2008-05-13 0:45）频率降低了，希望可以无限延迟下去。 鉴于维基百科地址不方便访问，这里提供一下百度百科的《地震自救大全》，不管用不用的到都看看吧。 最后，愿受灾地区的人们平安！可以恢复正常生活！ p.s.早上上班路上，家门口有两条狗在马路中间办事，当时还觉得今天的动物够疯狂的，到了下午才明白。 Technorati : USGS, earthquake, twitter, 地震, 汶川, 网络传播 http://blog.94smart.com/cache/2008/0512_1235.html 明天就是劳动人民的节日，祝大家歇好、吃好、玩好！ 今年的劳动节我又可以去其他地方度假了，最近烦心事太多，正好可以出去散散心，Nice~ 这次去海南三亚，陪老婆看看亚龙湾蓝蓝的海和银色的沙滩~ 所以，Google Reader的阅读共享网摘暂停几天，各位看官请见谅~ Technorati : 旅游, 海南三亚 http://blog.94smart.com/cache/2008/0430_1234.html 预告：本Blog近期将开始一个到两个项目相关的系列内容连载，敬请期待~ 上周末，去jiwai的会议室（地方真不好找）参加这次的UCD产品设计工作坊，从头到尾经历虚拟项目，效果还不错，从实践的角度开阔了我对UCD方法的理解，感谢白鸦和Angela为我们上了如此有价值的一课。 从今天开始不定期更新我的心得： 第一篇：从混乱中开始 种种原因搞的从一开始就很混乱，好像来参加工作坊的人（包括我）都没作足功课：对行业不够了解、对"图像搜索比价购物"这个概念不是很清楚、对UCD的流程不大明白等等，加上各自的工作背景，也许你可以想像到有多么混乱。 早上开场，白鸦介绍了一些项目背景知识后，在场的人开始组建团队分角色，本次工作坊集中在PM、BI、UR、ID等角色，有趣的是发现大多数人属于全能型，在实际工作中多数都是自己一个人做全套工作，划分工作职能可能是我们都欠缺的，有时在阶段最后还演变为人少服从人多的"群体智慧"。 我们就是在混乱的状态下进入市场研究这个环节，时间紧迫，10~20分钟要做好用户定位、市场定位及优劣势分析，且需理出一个吸引投资的项目介绍。这对我们打击很大，我们9个人分成若干组整理相应资料，当汇总到一起的时候发现根本合不上，使我们的产品目标打一开始就不是明确。 事实也证明我们存在问题，因为在接下来的用户定位一度导致我们发生分歧。 本阶段我的小心得： PM（项目经理或产品经理）绝对不是执行层能做好的，一定得深入战略层，需要打一开始对项目负责，哪怕是分析后决定取消项目，绝对不能是一个谁让干什么就干什么的人。 BI很重要，分析行业数据及竞争对手很有用，不一定非得市场人员去做，UR一样需要，且需要多花时间去做，绝对可以影响后面的工作。 过往经历的项目从来都是半路加入，没有从前期加入的经历，所以习惯从别人处得到足够信息而不去管信息获得的途径，这在UR是不正常的，需要自己去获得/分析信息、数据，然后通过后面的工作去验证。 p.s.我跟两个Tony一组，其中有一个是UCDChina Blog的Tony，当时太投入，居然都没来得及单聊~ Technorati : PM, UCD, UCDChina, UR, workshop, 产品设计工作坊, 以用户为中心 http://blog.94smart.com/cache/2008/0421_1233.html 别紧张，只是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, 裸奔 http://blog.94smart.com/cache/2008/0409_1232.html 注：以下是我这个外行的片面之词，因为最近工作碰到相关问题，所以随便记一下，没打算误人子弟。 已经存在相当一段时间的网站，有业务也有部分用户，他所面临的其中一个问题是怎么完成业务目标（比如增加营收、扩大影响力等），这就面临一个用户转化率的问题，是怎么把现有用户转化为付费用户的？ 所谓用户转化率，我指的是从潜在用户成为特定用户类型的转化率，比如注册用户转化率、活跃用户转化率和付费用户转化率等。 举个例子说说转化率的应用，通过付费用户转化率可以计算付费用户的推广成本：（例子来自2006年Topica的一本白皮书，有改动） 数据项 数值 算法 推广费用总数 ￥4,500 举例数值 注册用户数量 3000 举例数值 付费用户数量 90 举例数值 付费用户转化率 3% 90/3000*100% 每注册用户成本 ￥1.5 ￥4,500/3000 每付费用户实际成本 ￥50 ￥4,500/90 也就是说每增加1个付费用户需要投入￥50的推广费用。 影响上例的推广效果有三种方法： 提高推广费用这应该是维持现有状况下表面上最直接的方法，事实上也是大多数推广的必然结果。 减少获得每个付费用户所需的成本这可能最理想的方法，当这个成本下降的时候，一方面推广费用可以降低，另外同样的推广费用可以达到更好的推广效果，但这同时也是不容易达成的，这需要有足够强的议价能力，才可以在市场活动、竞价排名、线上广告等付费营销上享有更多的话事权。 提高付费用户转化率可以这么说：提高转化率才是王道，以上述例子来看，同等条件下提高1%付费用户转化率，就可以增加到120个付费用户，每付费用户成本也降低为￥37.5，从而节省推广费用。（同时做到前面的两点） 那怎么提高付费用户转化率？我能想到的有： 收集用户需求和跟踪统计用户数据以合理的业务目标做目标，改进需要有基础和方向：统计用户数据就是基础，可以挖掘用户的部分实际需求；接着需要不断倾听用户的意见，贴近用户需求就是方向。 优化业务流程以一定真实数据为基础，就可以进行相应的流程优化。以网上商城为例，用户在购买流程的每一步操作，从浏览、商品放入购物车开始直到用户下订单并支付完成，或在中途放弃支付，都需统计及分析。不断去优化流程，该精简的精简、该删除的删除，让用户更容易获得商品，增加更多的正向循环流程。 提高访问体验缩短用户决策时间从页面框架、图像设计、导航等到整个网站结构，让用户更容易得去理解网站的用途，更快知道自己该怎么去用，更快决定进入业务流程（用户体验这部分UCDChina有不少好文章可以参考）。需要说明的是 ，现在的网站产品越来越重视用户体验，但不应该是为了有用户体验而重视用户体验，而应该是为了完成特定的业务目标。 保持用户转化率要增长先保持转化率不下降，活动、优惠、促销、代金券等等都只是手段，保持后方能增长。 针对关键目标用户例如像书店，来的人虽然很多，看书人的也不算少，但是最后掏钱买书的却只是一部分。也许目标用户群很广泛，转换为注册用户的也不少，但实际会转化为付费用户的却很有限，寻找关键目标用户就非常重要，且随业务发展而变化。 …… 当然上述也可以部分适用于提高注册用户、活跃用户转化率。 另外，网站需要根据自身需求，选用合适的转化率标准，比如我觉得： 一个论坛最好使用活跃用户转化率。 一个网上商城最好使用付费用户转化率。 一个交友网站可以用注册用户转化率。 其实说到底，我还是认为付费用户转化率的含金量最高，因为不需要再考虑后续转化率，这并不是说其他转化率没用，毕竟注册/活跃用户转化率对广告销售还是有很大用的。 终于写完了，这是近期令我比较困扰的事情之一，本文意在抛砖引玉，希望有相应经验的朋友可以（通过Gtalk/Gmail）不吝赐教，在这里先拜谢了~ http://blog.94smart.com/cache/2008/0331_1231.html 关于Wiki，水是这样流下来的： 前传：对于Wiki和维基百科我是早有了解，05-06年的时候曾经先后用CooCooWakka和MediaWiki在94smart.com架过，基本都是玩两下就放弃了，当时好像是因为编写习惯和权限设置的问题。 去年11月开始看《维基经济学》，可能是因为个人口味不同，这本书读到今年也没读完，也不打算继续读下去了。 今年二月底公司开始培训新的内部办公工具（据说是EA内部使用很久的组合方式），其中之一就是用Wiki写工作报告，起先我很不理解曾在twitter上说："有人听说过，用MediaWiki作公司内部报告系统的吗？"，言下之意相当的不屑。 在看了大BOSS写的快速入门后，在Wiki填充内容，从[[给文档加链接]]开始，起初不适应Wiki代码，网上搜索了很久也没找到合适的所见即所得编辑器，最后只好继续手写代码，还好后来习惯了。 我们需要把个人简历、联系方式及工作报告都填进去，就现在来看在Wiki里面写简历不是很舒服，所以我在Blog上写了个非公司版本的个人简历。 起先发现在Wiki里面的图片好像都不直接加外链，多数都是连图片描述页，也许是为了方便其他人补充说明或评论吧。 Wiki好像不是用来发布纯文本重复内容的工具吧？我认为内部链接才是Wiki的王道，能连接内部内容绝对不考虑外部链接。 使用Wiki一段时间，其间又看了些Wiki的相关资料，发现之前的部分理解有误，我很想收回之前说过的话，其实用Wiki进行工作报告是有实际意义的。 公司的内部办公工具主要由内容发布/知识库、邮件、文件版本控制及论坛组成，MediaWiki架设的Wiki主要负责工作记录/报告、内部事项通知、经验分享及岗位培训等内容发布。 Wiki的优点在于强调文档结构化，在内部关联上处理得很合适，且用户不需了解复杂的代码即可进行超文本内容编写，牺牲了部分灵活换来了相对容易的协作。 另外，Wiki可以作为Web版的文档版本管理工具，可以比对修改、恢复历史内容等。 Wiki的文档可以很开放，用来做知识库、新闻、个人资料、通讯录、Blog、Life Stream等都很合适，我现在就用Wiki来做网摘（并用ROR写了一个网摘的Wiki代码生成器）。 Wiki需要制定现实中的更新规范，比如谁可以编辑这里谁不行之类的。 最近总是听见公司同事喊：把某某事情写在Wiki里。我觉得Wiki还是作备忘吧，并不能代替直接、实时的沟通。 其实工具就是工具，不止是Wiki、CVS、SVN这些协作相关的，最后还是需要通过各种形式的直接沟通去解决冲突问题。 幻想一下，如果在Wiki监视的页面可以通过im提醒就好了，邮件提醒还是比较不及时。 我开始看好用Wiki进行内部网建设，因为贡献内容的用户可以非常多，基于工作原因大多数人都需要别人更好的协作、配合，所以贡献的内容可以比较靠谱。 …… 本流水账可以写完，多亏互联网有twitter的存在~ 还好有twitter，让我可以随时把想法发出来，不用憋很久憋成blog，也许憋到后来都忘光了、没感觉了；还要感谢twitter，因为它丢信息不是特别的频繁，让我可以找到之前记下的内容。 Technorati : Wiki, 协作, 工作报告, 沟通, 知识库 http://blog.94smart.com/cache/2008/0319_1230.html 前一段时间一直在研究ROR，就想开发一些小应用，简单记一下这段心路历程： 想做一个部门内分享资讯的webapp，用来分享图片、网页、文字，基本是想做个简单的twitter类应用。 鉴于我本人对Ruby On Rails很感兴趣，twitter就是用它开发的，而且好像可以快速开发，就决定用它实现，版本是1.2.6。 不动手不知道，ROR表面的地方真是很简单，可以快速做出一个原型，但是越深入越复杂，想全面点实现出来需要注意的地方还真不少。 ROR的学习资料还算挺多的，就是高质量的中文内容太少，我其实不是做技术的，只能用部分业余时间写代码，连学带练的拖拖拉拉写了1个多月才像点样子。 就像《用户体验的要素》里提到的"永远不能发布的项目"一样，因为前期缺少足够的用户分析和功能需求，过程中还过分修改细节，不断加入特性，导致该项目一直不能正常使用。 看到xdite用ROR快速开发Facebook App，使用CSS库做界面布局，心又乱了，想拿进行中的项目改。殊不知，需要做的事情很多，要装rfacebook的gem和plugin，要到Facebook申请key，又要熟悉Facebook专用的标记语言FBML，很多设置需要在虚拟主机上调试，Dreamhost又诸多不便，最后只能作罢。 注意到Joyent提供免费的Facebook App空间，就去申请，若干天后通过审核。进入管理界面，傻眼了，超级复杂（如果有人觉得Dreamhost的panel已经很复杂就不用去试了），虚拟服务器配置好后，开始调试FBML。 没有将现有进行中的小项目转换成Facebook App，只是简单测试了下，做了一个显示所有好友的列表，发现Facebook提供的接口很有限，同时也推翻了我的一个设想"开发通用应用，分别用Facebook、Google等开放平台优化，做成跨平台的应用"，因为有很多功能（如邀请、好友搜索/选择等）只能通过FBML实现，除非其他平台也有对等的实现，否则这个应用只能是FB专用，不是我需要的通用了。 还是回到我想做的webapp上，考虑到时效性和同事的用户习惯，最后决定还是使用QQ群解决，之后公司又推广wiki协作方式，这个东东就不了了之了。 我最后把这个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 http://blog.94smart.com/cache/2008/0312_1229.html 看了一下，最新的一篇Blog是1月底写的，现在已经3月中了，我又1个月没写过什么了，Blog确实是这样，其实我差不多每天都写东西（还算勤劳啦），有长有短，比如把短的更新到使用频率最高的twitter（Friendfeed统计出来的），其次稍长一点的都写在最近在公司推行的Wiki上（没错，我就是开荒牛~）。 进入正题，不知道为什么，最近一个月经常回忆起以前的经历，引起我回忆的是简历--要公布在公司wiki上的简历（其实也没什么东西），之前的经历像影片一样一幕幕的展现出来： 上世纪80年代末90年代初，我还沉浸在FC（任天堂红白机）的欢乐中，那时就梦想自己一个人做个游戏出来，所以立志考上大学的计算机专业。 1997年末，我还是只对电脑的使用感兴趣，主要还是电脑游戏，后来家里可以上网了，就对互联网产生了浓厚的兴趣，当然这时的兴趣完全建立在网站浏览和网上聊天上。 1998年，高中学到Basic语言编程，从此对编程开始有兴趣，同年开始用VB开发牌类游戏，当时因不懂算法设计导致失败（后来发现绝不仅是因为如此），最后只完成窗口界面，曾为此自暴自弃一段时间。为了完成儿时的梦想，后来还是报考了一个学校的计算机专业。 1999年，用记事本通过直接写HTML代码的方式，作了第一个超简单的个人主页，虽没有地方上传，还是喜欢上做网站，后来听说了网站空间，于是开始疯狂搜寻、使用免费空间，最后落户在myrice.com和heha.net。 又因为从小喜欢听歌，曾先后做了纯手动更新的四个音乐类网站，其中有一个用RealAudio做的在线听歌网站、一个学雅虎的目录搜索、一个乐评资讯站、一个歌手资料站。 1999年9月，上大学了，在学校学到C语言，发现遇到了一个喜爱的程序语言。 遇到一个可以免费得到CN域名的机会，代价是付出自己的网站，将所有权交给某域名网站，最终没有签约。 1999年底左右，在网上看到一个叫做什么社区（也就是后来的交友加强型BBS）的网站，是用ASP写的，发现确实比纯网页有意思，于是开始寻找支持ASP的空间，未果，发现自己正在使用的空间（就是香港的heha.net）支持一种叫PHP（那会还是PHP3呢）的程序，好像跟ASP差不多，学习过程中发现语法与C极其相似（这也是我一直喜欢它的原因之一），后来用PHP完成了文件型留言板、图形计数器等若干小应用。 2000年吧，找到免费解析一年顶级域名的某国外网站，注册域名yorso，网站取名乐索（不是勒索），做了我最后一个音乐网站。 2001年，用PHP和Mysql做了一个音乐社区雏形，包括歌曲库、文章发布、资源搜索、会员注册/登录、论坛（最终没完成）等，当年因为联系的站长多数不愿意分享自己的资源，所以最后还是失败了。 2001年底，在网上偶然找到一个叫有个网的国内PHP虚拟主机提供商，正式注册了自己的域名94smart.com，架起了一个仅包括近期更新的纯个人网站。 2002年初，大学快毕业了，找到在某知名游戏公司做网站的工作，头一次知道正式的网站制作要经过的流程，以前自己实在太作坊式了。发现页面设计、JS脚本和Flash都很有学问，所以曾下过一些工夫学习。 2002年底，开始深入学习CSS，以前虽然用，但是没系统学过，发现这个确实是处理页面样式的好方法。 2003年，离开上家公司，到某门户网站游戏事业部负责网站工作，我被大公司的内部工具震到了，例如支持大型站点的CMS、图片负载均衡、站点同步等等，很多工具确实可以提高效率。 2003年底，开始接触Blog，自己空间里架过几个，没玩出什么，暂时淡忘了。 2004年，开始接触SNS，下半年使用Drupal重新架设了Blog，正式开始写Blog。 2004年底，因为种种原因开始思考工作方式、目标的改变，第一次给领导写建议并获部分采纳。 2005年初，与公司UE部门合作工作，开始认识到UE的重要性。同年开始更加关注UI、UE。 2005年下半年，与技术人员一起进行玩家Blog项目，上线后因部门不重视、缺乏推广等原因搁置。于8月离开该公司，顺便回家整理自己的思路，写成建设计划提交给下家公司。 2005年第三季度至今，加入现在的公司，继续从事网站建设工作，任网站架构师。 …… 写完发现有点像简历……有些事情印象不深了，还有些事情是混在同个时期一起进行的，所以可能年月就记错了，反正主要是写给自己的，无所谓~有些经历过个七、八年，回头再看的时候，可能已经不重要了。 重点是有个目标，为实现目标需要进行一系列努力，可以学到一些技能，获得其中的经验，之后可以更贴近目标，而且越深入越能发现需要补充完善的部分，经验如此循环积累下，总会有个结果。还有一点很重要，就是在需要的时候一定要和别人合作，只有这样才能更专心于自己的目标。 我发现自己的梦想好像太多了，从不切实际的到比较靠谱都有很多（就不写出来了），好像跟我广泛的兴趣有关系，当兴趣上来了就会产生相应的梦想。 我不想放弃梦想，也许现在没有能力没有条件去实现， 但那只是暂时被封存，如果以后有机会我会努力完成它。 http://blog.94smart.com/cache/2008/0311_1228.html 冬天里下大雪，在北方也许不算什么（因为北方人都习惯了），但是发生在南方就是一场灾难。 在这场灾难里，有被雨雪压倒的房屋、堵在高速路上的车辆、无法回家的外地务工人员和能源物资缺少的城市…… 他们最需要什么？我觉得应该是摆脱困境的方法及各种实在的援助、支持。 最早知道谷歌春运交通图，是通过白鸦的twitter和blog，后来才看到谷歌黑板报的文章，春运交通图是一个架设在谷歌地图上的特殊标注及内容，整合交通线路、天气预报等相关资讯，确实很全面很强大，但这又有什么用？ 后来收到飞递（Feedsky的中文名）话题广告的邀请信，才知道谷歌在大力推广这个春运交通图，还冠以公益头衔。 我的第一反应：哦，原来是谷歌的商业行为。 想法未免有点偏激，但是我认为公不公益得看发起人以及动机，虽然公益不排除商业行为，但是跟赤裸裸的商业动机（比如大雪无情，卡巴有情）还是有很大区别的，公益不应该建立在"使用谁的产品"这个基础上。 ok，不扯了。 最后，我所能做的除了在这里说说，只剩下祝福，祝福受灾地区的人们早日摆脱困境、能够在家欢度新春！ Technorati : Google map, Guge, 春运交通图, 橙色关怀, 谷歌, 雪灾, 黄丝带 http://blog.94smart.com/cache/2008/0131_1226.html 所谓开放，是一种分享态度，开放平台是自有平台与外部应用共享用户（不一定包含数据）、流量，开放应用是把自己业务打包成模块，通过其它平台分享使用体验。 我在上篇Blog里曾表述过"单纯应用类和社区类的网站，现在有且仅有两个选择，要不自己做大做平台，要不就做成适合开放平台的纯应用"的观点（除上述类型网站外其实还包括资讯类的），大多数网站现在都面临同样的问题： 开放平台还是开放应用？ 随着最近Facebook Platform、Google OpenSocial、搜狐博客开放平台等的出现并逐渐发展，Slide、Rockyou!等应用提供商的崛起，网站运营人员不得不去面对上述的问题。 后Web2.0的思想，使资讯类、应用类网站在逐渐增强社区氛围，社区类网站在不断增强互动资讯部分，趋势是互相融合的，成为趋向交互的网站。 这也造成网站系统的重复劳动过多，几乎每个网站都有自己单独定制开发的用户系统 、好友系统、交友网络等等，使得网站操作复杂，用户永远需要去适应体验上的差异。 不管开放平台还是开放应用，都可以解决很多问题，同时精简自己的应用结构，根据网站定位更好的发挥自己的特长。 当然，开放平台并不那么好做的： 首先平台网站需要有颗包容的心，允许别人的应用借你的平台发展。 需要提供功能全面的接口，让应用可以很容易结合到平台上。 需要有良好的用户基础，用户数量级够大且用户素质有一定保证，要不没有应用会来。 像Facebook、Google这样本身就很强大的平台并不在多，还没有跳出来的也屈指可数了。 用户数据的所有权成了最大的死穴，平台如果不能照顾应用的利益，早晚被应用放弃。 受应用欢迎的平台标准也会逐渐提高。 ……（想到再补充） 开放应用稍微容易实现一点，但也有好处有坏处： 最大的优点，可以跨平台吸收用户，让不同平台的用户存在于同一个应用下。 不影响现有网站运行，可以为特定平台开发定制应用。 因为要适应各平台接口特点，用户体验可能与源网站不统一，或各平台间体验存在差异。 应用的模块化标准有待整合，现存标准缺乏通用性。 怎么将平台用户转化为应用用户将成为网站运营的主要研究课题。 ……（想到再补充） 话说回来，不管开放什么，多平台鼎立的形势已经出现，在应用数量相当的情况下，主要看用户对平台的喜好，而应用已经不能再左右用户的选择了。 对个人用户而言，在熟悉的平台下使用感兴趣的、新的应用，将成为平台网站的主要体验，哪个平台相关方面做得好就可以脱颖而出。 还有一个可能发展的方向，用户基于现有个人网站（Blog）自建平台，维系用户的（社交）关系，将开放应用自行整合。用现有工具已经可简单实现，例如OpenPNE等开源软件、老冒的OPSN项目（我最感兴趣~）等等。 最后，借用一句互联网的名言收尾：未来是如此的不可知，互联网的发展更是如此，也许事与愿违，就当是2008年第一个月的某个白天的胡思乱想吧~ 最最后，洋洋洒洒的写了一大片，一篇东西居然写了几个小时，中间经过很多琐碎的事情，可能会觉得驴唇不对马嘴，我还是感谢您能坚持看到本文的最后~^_^~ Technorati : Application, Facebook, api, google, opensocial, opsn, 开放平台, 用户体验, 网站应用 http://blog.94smart.com/cache/2008/0129_1225.html