前几天我写了《人面不知何处去――blogcn 的失误》，有两个网友的留言很有意思。一个网友说，“楼主好像只点明了blogcn的失误，而没有提出一些建设性的意见”，是的，但我现在的工作和blogcn存在潜在竞争关系，虽然写博客是私人行为，但也没必要为竞争对手提供“建设性意见”吧？所以今后可能还有类似的文章，我依旧只能“解构”，而不能去提供“建设性意见”。另外一个网友和我讨论文中提到的blogcn的博客客户端产品rabo，他认为：“一，網頁上直接寫blog，容易遺失。 二，rabo可以備份blogcn的日誌”，有了这两点，所以rabo“是個好東西”。所以这篇blog就从这个网友的留言开始，从rabo的设计，谈谈我对产品设计的一点想法。
我几乎可以打赌，当初blogcn的决策者决定上马rabo的时候，主要的考虑也就是上面那位网友的两点。（也许还有第3点考虑，就是通过rabo客户端，能渗透到用户桌面，达到对用户的真实控制）。我们以前两点来分析。
“网页上直接写blog，容易遗失”，所以用户需要rabo――这是想当然了。当一个用户在网页上写blog而发表失败时，用户即时地有两个反映：第一，臭骂BSP一顿；第二，继续再用web方式发表――大家可以想想自己是不是这样的。而直到n次遇到发表失败的情况后，用户才会尝试如果web端发表长文章之前，先ctrl＋c复制一下；然后又n次失误之后，用户才会选择先在客户端书写好，然后再提交――直到这个时候，rabo可能才有点用；但遗憾的是，word和写字板的存在，又剥夺了rabo此时的位置：我为什么不能word写好后，复制到web端发表，而非得用rabo这个新玩意儿？！所以这么细细分析下来，“网页上直接写blog，容易遗失”根本不可能促使用户实用rabo，而只能使用户使用word或写字板。
“可以备份blogcn的日志”，所以用户需要rabo――这依旧是想当然了。在说明这点之前，我先说个数据：据我统计，坚持每周至少更新一篇博客文章的blogger只有总blogger的5％。这5%才是真正可能需要“备份”自己的日志的用户。对于其余95％的blogger，想想我们是怎么对待自己的硬盘突然损坏的吧――我们想过要预先每隔一段日子就备份自己的数据吗？没有，我们多数都是等硬盘坏了，才欲哭无泪。同样，用户对BSP服务器的信任会多过对自己硬盘的信任，他们不会想到要按时备份的，一则没有这个用户习惯，二则这95％的人也没发表太多数据值得备份。
Rabo表面上成立的两个理由，细细分析下来，就荡然无存。这样产品设计失误，根源在于设计者有一种本能：多功能症。
我们每个人的内心都是在贪婪和恐惧之间寻求平衡。这点在产品设计上也同样体现，特别是“贪婪”――总认为自己能满足用户的n多需求，而超越了自己的能力。其实以BSP来说，blog是一个低技术含量的玩意，第一是快速，第二是稳定，做好这两点，基本就是一个好的BSP，其余的都是锦上添花的玩意儿。而2005年，blogcn的主要问题恰恰是速度和稳定性，但他们没有解决这个关键问题，去做一些rabo之类的产品，即是因为设计者的“贪婪”――试图即做bsp，又一网打尽客户端。
而web设计中，有太多这样试图给用户“全面解决”的例子，我把它叫“多功能症”。比如大家访问一下新浪天气频道，你看看那么多功能，其实我打赌，估计90%以上的用户在这个频道页面只需要一个功能：我所在城市的、文本的天气预报。那“新浪天气”频道为什么要设计那么多功能呢？估计是因人设事――有了天气频道的编辑，总得做点事吧，就推出了若干新功能，显得自己也挺忙的，页面也挺花哨好看的――并且认为用户也需要这些功能。
但实际上用户并不需要。
“多功能症”在软件产品设计中其实早就存在，比如越来越复杂的word功能菜单。这可以说是一个顽疾了。但，软件产品因为是客户端的应用，不牵涉到网速问题，所以其“多功能症”虽然讨厌，但不烦人；而web端的“多功能症”却对用户体验有极大的负面影响，危害非常大。
据说google的创始人曾经仔细数过google首页的文字数目，相比而言，我们新浪之类的门户却是十几屏的首页还意犹未尽。BTW.我本人见过最长的首页是伟大的博客家顺风先生的博客首页，好像超过70屏了――所以请大家打开的时候，务必镇定。
又坐沙发了：）“多功能症”是要外科手术的.要有勇气摒弃90%的人用不到的那10%。
web上写是不太保险，所以字写得多时常会ctrl+c一下，或者直接在记事本中写。
顺风是个牛人
很正常,我也是搞产品设计的，从产品的角度来看的话，如果要备份日志完全不用这么麻烦,搞个rss全部导下来就可以了，何必做个客户端这么麻烦呢。
我也觉得，用用记事本足够了。而且BSP本身可以加上定时自动保存的功能，就类似于writely那种。那样rabo这种产品更没活路了。
咳，当初我本来也想写那两个理由反驳你~幸好写到半截的时候浏览器死了。嘿嘿嘿。
多功能症确实是产品设计的大忌!! (开源的自定义表单工具,在: my5151.meibu.com )
“多功能症”反映了对产品改进重点方向不清，从深层次反映了国内重表面功夫，浮躁浅薄的一面。
赞同这种观点。现在各个网站的开发成本还是太大，但80%用不上，用户实际使用或者使用得很多的还是只有那最基本的20%。把精力放到最基本的最使用的功能上，最到最好，或许是小创业公司的出路。
这个调调被office的各路竞争对手反复唱过,听起来很有道理,但过后该用word还得用word.为什么呢?因为:你根本不会知道到底哪些功能对用户是所谓的10%.比如”文字统计”对一些用户来说是垃圾,对另一些就是宝贝.用户群大到一定程度,功能扩张便不可避免,功能多的干掉功能少的.即便是web设计,功能多少与页面简洁与否也是两个不同的问题.google首页简洁,但它的功能少吗?无非把各种功能藏在边边角角,数量上,功能总是在扩张的.
偶觉得，楼主意见偏执了点。只能说blogcn的工具做的不够好，不够吸引人。1.专业一点的blogger确实应该有一个客户端的writer。这个writer也不一定就是word，记事本，rabo。2.BSP们应该提供一个备份工具。比如blogbus那个移植别的bps的工具。当然应该更完善一些的。如果rabo能把上述二功能合一，就很不错了。不需要更多，但需要这些功能。偶觉得实用和多功能是不矛盾的功能。
如果多功能不化银子，多也无妨。但简练从来是中国人追求的目标。上下五千年的历史长河里，相信你能从古文中，以及现在的很多粗制滥造的Y货中，看出国人对简练的狂热追求。否则，就一定是另有所图。
楼主观点有些偏激只能说明rabo做得不够好，完善一下，这样的工具还是很实用的前阵爱搞搞那个工具那么受欢迎，足以说明问题
一个网友说，“楼主好像只点明了blogcn的失误，而没有提出一些建设性的意见”，其实能 解构 已经很不错了，应该有悟性自己来 拿出解决之道吧。 还要别人把饭做好吗？这里有个blog 博客备份：blog 博客备份申请地址: blog 博客备份申请http://www.search-analysis.com/bloganalytics/blog-offline-book-generator.php备份blog博客范围：所有bsp( msn space , bokee , donews , blogbus , blogcn etc. )和非bsp 个人的blog chedong.com , dbanotes.net etc.)。
结构从另外一个角度来说，不也等于为解决之道提供了参考么？
TrackBack来自《麦田 多功能症――再谈产品设计》：道理说对了，理由没说对，招了一堆板凳沙发数落。其实谁不想花钱买的东西没有浪费啊？很多时候一个认做结论或判断是基于已有的认知、曾经的经验，在圈子里混久了，一出手就知道啥份量，姑妄判之也八九不离十。但总凭经验判断往往会露了自己的怯，否则就不会有“没有调查就没有发言……rowdy在“板儿砖”拍你＝＝＝板儿砖–砖头馒头齐飞，口水共长天一色！
顺风的博客是54屏，报告完毕。
跟分辨率和显示器大小有关，呵呵，刚才在一台机器上看顺风的blog是106屏
我用过rabo, 个人觉得blogcn出发点还是不错!但软件界面设计的太过复杂了!这年头, 简单太重要了, 有时候想得太多,并不是太好, 对于产品,给用户一个选择, 比给他几个选项做选择题要来得好!
这年头, 简单太重要了, 有时候想得太多,并不是太好, 对于产品,给用户一个选择, 比给他几个选项做选择题要来得好!楼上的说得很形象。
word也具有“多功能症”？word的许多高级功能一般人根本用不到，并不能说明word的功能设计有问题，而只能说明你没有碰到需要word出手解决问题的时候。从你对word的观点来分析，估计记事本或者写字板也足够你用了
“多功能化”不仅是软件产品或者web产品，我们生活中用到的家电、手机、PDA哪一个不是如此呢？两方面入手：1、作为产品开发者的开发惯性，会希望产品十全十美，同时也不排除体现个人工作业绩和工作量的考虑。因此，产品设计变得日趋复杂和“完美”。2、顾客也有类似的心理反应：我要买，就要买功能多样的好产品。而实际上，大部分功能买来了完全不用。 这样，“好”和“实力”等正面评价 会不自觉地影响顾客的购买心理。 因此很多生产商会去迎合这种消费心理。所以“多功能化”一定还会成为惯性。 只有少数的聪明企业能够恰当地控制这种惯性。这不仅需要产品设计者的智慧，也需要公司体制的支持。奈何老板或者产品评审委员会的“头头”们说：我付给你这些薪水却只给我弄出两行字来，那你回家卖红薯去吧。 他如果认识不到那两行字与其他字的价值区别所在，也是麻烦大大的。
TrackBack来自《“断桥”的批评和我的回应》：
TrackBack来自《上周技术关注：XP应该是老板的最爱》：结对编程――最有效的相互监督机制结对编程――最有效的内部培训机制测试驱动开发――最有效的质量保证体系User Story＋客户现场办公――最低成本的需求收集、分析机制每日集成――有效降低集成、测试成本
TrackBack来自《我有了8块3毛5分钱的虚拟收入》：
我有了8块3毛5分钱的虚拟收入。
你不要听了一头雾水，事情是这样的：那天土豆AD刚上线就被我用rss迅速地给逮住了，并且copy了“China Web2.0 Review”上的英文版本，贴在自己的blog上为之大肆宣扬了一番，然后当然制作了几个视频放上去，哈哈，指望它像Google Adsense一样为带来收入。果然，收入就来了，就是上面的――“我有了8块3毛5分钱的虚拟收入。”这真是让人生气啊，到100元的时候才能拿到钞票就不说了，可恨的是居然我的视频广告每被点击播放一次才只有一分钱的收入呀，到底广告商给了土豆多少钱？他们分给我们这些内容提供者又是多少钱？太虚了吧，使我忍不住要揭揭土豆的疮疤了，虽然我是个绅士。
先说说优点吧。因为我是个绅士。土豆的名字真的还是不错的，有趣好记，他日土豆能有大的发展，名字绝对功不可没。去年播客在王微的推动下，一时大热，我便是在那时把土豆放进自己的收藏夹，从看《男生艳舞》，《后舍男孩》到自己制作视频内容上传，没有想到体验从high宕到very very low。为什么呢？你说后台有多复杂就有多复杂，晕得找不着北，虽然在一些细节上，他的措辞很体贴，但是用户体验你依然不能说他好。
说的太有道理了，设计者总认为功能越多越好，其实用户并不需要。
当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！当一个作者带着感情色彩或作为一个竞争对手去分析问题时,难免会遭到读者的质疑!强烈鄙视你！
你能踏下心来做点实事吗？现在看来你也只是会稍微有点偏执的见解来这里撒泼而已。