注：以下是我这个外行的片面之词，因为最近工作碰到相关问题，所以随便记一下，没打算误人子弟。 已经存在相当一段时间的网站，有业务也有部分用户，他所面临的其中一个问题是怎么完成业务目标（比如增加营收、扩大影响力等），这就面临一个用户转化率的问题，是怎么把现有用户转化为付费用户的？ 所谓用户转化率，我指的是从潜在用户成为特定用户类型的转化率，比如注册用户转化率、活跃用户转化率和付费用户转化率等。 举个例子说说转化率的应用，通过付费用户转化率可以计算付费用户的推广成本：（例子来自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）不吝赐教，在这里先拜谢了~

关于Wiki，水是这样流下来的：

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, 协作, 工作报告, 沟通, 知识库

前一段时间一直在研究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

看了一下，最新的一篇Blog是1月底写的，现在已经3月中了，我又1个月没写过什么了，Blog确实是这样，其实我差不多每天都写东西（还算勤劳啦），有长有短，比如把短的更新到使用频率最高的twitter（Friendfeed统计出来的），其次稍长一点的都写在最近在公司推行的Wiki上（没错，我就是开荒牛~）。 进入正题，不知道为什么，最近一个月经常回忆起以前的经历，引起我回忆的是简历–要公布在公司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. ……

写完发现有点像简历……有些事情印象不深了，还有些事情是混在同个时期一起进行的，所以可能年月就记错了，反正主要是写给自己的，无所谓~有些经历过个七、八年，回头再看的时候，可能已经不重要了。 重点是有个目标，为实现目标需要进行一系列努力，可以学到一些技能，获得其中的经验，之后可以更贴近目标，而且越深入越能发现需要补充完善的部分，经验如此循环积累下，总会有个结果。还有一点很重要，就是在需要的时候一定要和别人合作，只有这样才能更专心于自己的目标。 我发现自己的梦想好像太多了，从不切实际的到比较靠谱都有很多（就不写出来了），好像跟我广泛的兴趣有关系，当兴趣上来了就会产生相应的梦想。 我不想放弃梦想，也许现在没有能力没有条件去实现， 但那只是暂时被封存，如果以后有机会我会努力完成它。

冬天里下大雪，在北方也许不算什么（因为北方人都习惯了），但是发生在南方就是一场灾难。 在这场灾难里，有被雨雪压倒的房屋、堵在高速路上的车辆、无法回家的外地务工人员和能源物资缺少的城市…… 他们最需要什么？我觉得应该是摆脱困境的方法及各种实在的援助、支持。 最早知道谷歌春运交通图，是通过白鸦的twitter和blog，后来才看到谷歌黑板报的文章，春运交通图是一个架设在谷歌地图上的特殊标注及内容，整合交通线路、天气预报等相关资讯，确实很全面很强大，但这又有什么用？ 后来收到飞递（Feedsky的中文名）话题广告的邀请信，才知道谷歌在大力推广这个春运交通图，还冠以公益头衔。 我的第一反应：哦，原来是谷歌的商业行为。 想法未免有点偏激，但是我认为公不公益得看发起人以及动机，虽然公益不排除商业行为，但是跟赤裸裸的商业动机（比如大雪无情，卡巴有情）还是有很大区别的，公益不应该建立在"使用谁的产品"这个基础上。 ok，不扯了。 最后，我所能做的除了在这里说说，只剩下祝福，祝福受灾地区的人们早日摆脱困境、能够在家欢度新春！

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

所谓开放，是一种分享态度，开放平台是自有平台与外部应用共享用户（不一定包含数据）、流量，开放应用是把自己业务打包成模块，通过其它平台分享使用体验。 我在上篇Blog里曾表述过"单纯应用类和社区类的网站，现在有且仅有两个选择，要不自己做大做平台，要不就做成适合开放平台的纯应用“的观点（除上述类型网站外其实还包括资讯类的），大多数网站现在都面临同样的问题： 开放平台还是开放应用？ 随着最近Facebook Platform、Google OpenSocial、搜狐博客开放平台等的出现并逐渐发展，Slide、Rockyou!等应用提供商的崛起，网站运营人员不得不去面对上述的问题。 后Web2.0的思想，使资讯类、应用类网站在逐渐增强社区氛围，社区类网站在不断增强互动资讯部分，趋势是互相融合的，成为趋向交互的网站。 这也造成网站系统的重复劳动过多，几乎每个网站都有自己单独定制开发的用户系统 、好友系统、交友网络等等，使得网站操作复杂，用户永远需要去适应体验上的差异。 不管开放平台还是开放应用，都可以解决很多问题，同时精简自己的应用结构，根据网站定位更好的发挥自己的特长。 当然，开放平台并不那么好做的：

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

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

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

话说回来，不管开放什么，多平台鼎立的形势已经出现，在应用数量相当的情况下，主要看用户对平台的喜好，而应用已经不能再左右用户的选择了。 对个人用户而言，在熟悉的平台下使用感兴趣的、新的应用，将成为平台网站的主要体验，哪个平台相关方面做得好就可以脱颖而出。 还有一个可能发展的方向，用户基于现有个人网站（Blog）自建平台，维系用户的（社交）关系，将开放应用自行整合。用现有工具已经可简单实现，例如OpenPNE等开源软件、老冒的OPSN项目（我最感兴趣~）等等。 最后，借用一句互联网的名言收尾：未来是如此的不可知，互联网的发展更是如此，也许事与愿违，就当是2008年第一个月的某个白天的胡思乱想吧~ 最最后，洋洋洒洒的写了一大片，一篇东西居然写了几个小时，中间经过很多琐碎的事情，可能会觉得驴唇不对马嘴，我还是感谢您能坚持看到本文的最后~^_^~

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

2008年早就到了，可我今年第一篇现在才出来，并不是不想写，只是最近被单位的很多事情烦恼，没什么静下来写写的心情。 今天，就在刚刚，想起最近一段时间经常在用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, 校内, 海内

前两篇分享体系相关的笔记写了Pownce、Soup.io，接下来需要翻过头来再次研究twitter，我个人认为当之无愧的（自说自话的）微网志鼻祖。 虽说twitter简单，那只是表面的简单：

• twitter看上去简单到只分享文字信息，但不简单的是，它把微网志、即时消息/回复（@id前缀）、定向消息（d指令）混合在一起。
• 当然链接也可以，twitter会自动将文字里的网址转换为可点击的链接。p.s.tinyurl类的短Url应用也在twitter的激发下被广泛使用。
• 以"What are you doing?"（你在干嘛？）为题，不停的答复着，自说自话着。
• 但，有多少人真正是在回答这个问题呢（我的好友就很少照做），尤其是gtalk、twitterfox、twhirl等tw应用的流行，现在的twitter已经变成了带群聊功能的IM。
• twitter将好友的概念实质化，加好友变成跟随（follow），单方面的相当于订阅，双方面确认的是好友关系。
• twitter的分享有一定权限划分，分几个层次：
  • 跟随用户和收藏内容为任何人可见
  • 更新内容可以限制只有好友可见
  • @id前缀的回复内容被同样跟随该id的用户可见
  • d指令定向消息只有对应用户可以看到
  • 被跟踪数量和资料只用户自己可见
• twitter的网站我很少去，除了为加好友等特定功能外，能不用就不用，因为我觉得twitter网站交互性不够好，不能总是没完没了地刷新页面。
• 好在twitter提供imbot，用gtalk就很方便的互动起来，而且它提供丰富的API，除了twhirl等纯客户端外，还有twitterfox、twiiterbar等firefox插件，另外还有一批特殊应用将twitter可以共享的内容无限扩大，比如twitterfeed可以把feed按自定规则发布到twitter，其中长地址还自动转换为tinyurl。
• twitter可以自定义部分页面CSS。
• 可以通过手机短信、wap移动更新、分享。
• 使用Amazon S3服务存储用户的头像文件。
• 页面用户信息使用vcard。

为了这个系列的统一，我还是放出这个简单到不行的分享架构图： 分享体系这个系列，我已经写到第三篇了，也许还会有第四篇、第五篇……这个系列一半为了工作需要，一半为了记录自己的即时想法，如有不同意见欢迎留言或gtalk交流，有些内容没有提到是因为我一时还没有理解，也欢迎来点化我，我会在不影响原文的基础上进行补充。 p.s.我现在使用twitterfeed发布Google Reader的阅读分享，一般每天发布也就在一个小时内进行，且数量很有限，应该还不够干扰别人的视线。

Technorati : API, IM, MicroBlogging, twitter, 分享体系, 微网志

美味汤Soup.io我是今天才知道的网站，之所以叫她美味汤是因为她本身提供文字、引用摘要、链接、图片及视频发布外，还可以融入很多不同类的包括美味书签del.icio.us、twitter、flickr、digg、youtube等流行的元素，她这样的特性让我想起了已经被G.F.W掉的Vox。（p.s.说到Vox，我还是挺喜欢用的，可惜被墙了:( ） 和Vox有一些相似点：

• 都以分享、展示为主要目的。
• 都可以聚合（混合）其他应用的数据元素，比如flickr、youtube等。
• 自选显示界面模板

当然Soup.io跟Vox并不是一类的应用（放在一起说纯粹是因为我的个人爱好），她有自己的特点：

• Soup.io定位为剪贴板，可以贴出非常丰富的页面。
• 她无需注册，即可发布分享内容、导入内容。 p.s.分享的时候快一点永远是令人喜欢的，其实就是开一个匿名帐号（或公共帐户），这算是一个不错的引子，当你试用后觉得好用的话可以通过快速入口注册成正式用户。
• 发布内容包括文字、引用摘要、链接、图片及视频，给我的感觉Soup.io更倾向于视觉上的分享，音乐和其他文件并不在主要分享范围内。
• 导入更加开放，可融入更多的元素，比如包括twitter和jaiku在内的几种微网志内容、美味书签del.icio.us的网摘、在Ebay的（商品）信息、Vox的更新内容等等，如果还觉得不够，可以直接使用RSS格式导入其他内容。
• 自定义界面，包括字体、字号、前景背景颜色等，还可以修改CSS。

现阶段Soup.io有些部分还很薄弱：

• Soup.io有好友系统，但并没有分享权限的设置。p.s.也许分享就应该是广博的。
• 也许是以展示用户自己分享信息为主，好友的分享信息没有很好地体现出来。
• 暂时没有可以和桌面互动的方法，我没听说她如Twitter一样有众多IM和客户端作为发布工具，也没有Pownce那种功能性十足且够眩的Air客户端。

最后补充一张图，暂时记录这么多，更深入的有待我去整理。 p.s.我并不喜欢网间传播Soup.io的时候，用瘦皮猴这个名字，不够形象。 **Update1：**soup.io的IO意在输入输出，好多人把他定义为Life Streaming还是挺合适的。 **Update2：**上传文件存储在自己的服务器上，这样未来的发展瓶颈可能会出现在文件服务器的负载上，为啥不学习Pownce和Twitter把文件上传到S3之类的服务器上呢？

Technorati : MicroBlogging, Pownce, RSS, Vox, soup.io, twitter, 分享体系, 微网志, 美味汤, 聚合

除了不能使用中文，我觉得Pownce还是很不错的。 今天粗浅的整理了一下，画了张图： 然后随便说说Pownce的产品架构：

• 分享是Pownce的核心功能，并依据用户间的关系来限制分享内容的范围、权限。
• 支持文本（twitter类碎碎念）、超链接、文件、事件日程格式的分享。
• 文本方面并不如twitter那么好用，而且因为不支持中文（我英文又很菜），用得很少。
• 超链接分享应该是一个亮点，除了文本链接这种形式，还支持引用Flickr、Youtube等图片/视频/音乐站的内容，可以直接将该内容显示在页面上。
• 文件方面就马马虎虎了，对10M以下的文件支持还可以，使用的是Amazon文件存储服务S3，所以并不适合大量文件的共享，因为超出的容量是要花钱的。
• 使用微格式（MicroFormats）完成个人信息（地址等）、好友信息（hCard）、事件日程（hCalendar）等信息的发布，并支持XFN来用网页形成关系网络，好像很方便日后的数据导出。
• Server端，Pownce可谓LAMP架构的典型代表，使用Debian+Apache+Mysql+Python和django。
• 客户端使用比较先进的（还在测试中的）Adobe Air，感觉还不错。 p.s.不过Air的应用有通病，就是点击关闭就直接关闭，我好像还没看过最小化到任务栏的应用。
• Pownce开放API方便第三方开发基于客户端、Web的mashup产品。

看上去很简洁，其实Pownce表现出的精简只是暂时的表面现象，Pownce未来可以扩展得更全面、更复杂。 扯开一点说，Pownce抓住的是网络功能一个比较重要的部分，内容的分享，且是小型内容的分享。为什么这么说呢？大容量内容完全可以使用FTP、BT、emule解决，但是小文件呢？网络硬盘很好，但是要分享需要操作的步骤比较多：找地方上传、找地方发布、把URL通过IM发给需要的人……实情可能更繁琐，但是现在微网志应用满街飞的情况下，越来越多的人通过微网志分享自己的内容，用Pownce基本可以一步到位。 扯回来，Pownce的分享体系值得研究，国内有不少有实力可以做到Pownce的应用（这里并不是指复制），就看他们愿不愿意了。 ok，今天的笔记结束~ **Update：**Pownce分享类型其实很明确，无论是文字、链接、文件还是日程安排，这些类型基本上都是唯一的，用户只用考虑分享内容的格式就好了，例如链接是图片、视频还是音乐的都无所谓，全部由系统来特定呈现。

Technorati : MicroBlogging, MicroFormats, Pownce, event, file, im, link, text, 分享体系, 微网志