Web-based Product Design Process - Spiral Model.pdf

做互联网设计最重要是为了运营，蓝图和文档好比做作业打草稿、画画先描白，经验丰富可以考虑先省下这步骤。因为如果不表现在具体web-based原型上，蓝图、文档再好也无法快速切入开发流程，做为有大局观的Producer应该尽快意识到这点。

UED团队合作与开发流程优化是以前在雅虎做产品同事写的，雅虎团队的产品工程师们技术好，而且有来自美国团队的协作经验传承，做前端编程一直是他们的强项。但传统瀑布模型进程必然要面对“前松后紧”问题，根源在于设计、技术团队要互相等。因此，如果规避必须从观念上做出调整：快速产出、快速迭代，也就是软件工程里的Agile and Iterative Development。

以前我也常抱怨做互联网设计没谱，一是资源紧、二是变化快。项目周期和人手似乎永远都无法满足，来自内部考虑不周、外部竞争压力双方的需求变更频繁。其实这就是互联网设计的常态，接下来提到的方法，分为三个大步骤，版本仅供参考。

Alpha.快速完成核心功能开发

这里“蓝图”只是个代名词，也许只有些蓝图片段，或规划片段。曾经我们在老板办公室开会，根据头脑风暴结果、会议记录直接做原型。这么说可能有点一觉回到解放前的感觉，事实如此，第一步很关键，但质量不重要。

因为开始就期望得到完善想法是不可能的。比如，你开会描述个东西，让同事提意见，可能大家什么都说不出来。但只要你动手做出具体原型，同事亲自测试体验之后，意见噼里啪啦一大堆就来了。在这层意义上，绝大多数原型是炮灰也应该。

最初工作用自己最熟悉、最快速的手法完成，别让开发团队等。当然，这部分代码质量将直接影响以后的迭代工作量，根据时间灵活安排。不要考虑的过于复杂，总结起来有三点：

1. 尽早用web原型评估设计质量
2. 制作避免过早陷入web结构和表现细节
3. 设计避免过早陷入功能细节

每个业务都会有核心功能，也就是用户的核心需求，基本上做产品前都会考虑清楚。可能核心功能内还会有核心模块，意思就是逐步提炼，找准关键点下手，这样才能搭好框架。也许经过几次迭代后，这部分工作已经是个可以跑起来的低保真产品，颇具alpha版本规模。

Beta.迭代完成固化需求功能开发

搭框架不要下手太狠，别自以为经验丰富把盘子搞大。因为刚才说了，互联网产品灵活最重要，虽然需求变化是经常的事，但我们要把风险控制在最低点。接下来在已有框架内，用同心圆放大的模式，按优先级实现辅助功能迭代，直至需求固化。

与此同时，产品设计团队除了对低保真原型的继续支持，还应并行完善和提炼高保真原型，并且着手对产品规范中复用模块的持续化整理，主要分为三部分：

1. web呈现效果迭代。先做图再切效率太低，因此我是直接用css美化低保真原型，通常这步可以把效果做的很得体。实在有必要，最后再截屏用photoshop处理细节并完善css。
2. web结构和表现迭代。我自己可以完成html framework, css framework两大块。
3. web行为迭代。需要工程师协助完成javascript framework。

也就是说，在包括beta版本以及之前，重中之重是实现功能需求层的良好用户体验。可访问性、兼容性、可用性、标准化、搜索引擎友好这些具体指标不要过早引入到应用开发中，让它们都在高保真原型的迭代内准备就绪。

比如可用性，做低保原型时尽量用最容易的方式解决问题，不要过早追求“用户体验”玩花样。大量的js互动效果和ajax异步加载会给原型维护、迭代测试带来大麻烦。

再比如标准化，良好结构的web页面，很受应用开发工程师欢迎，样式表则无伤大雅。因此我们可以多花功夫先处理html结构，节省时间让css样式表与功能开发并行迭代优化。

Release.模块化迭代提升用户体验

至此如果一切顺利的话，应用程序已经模块化并测试通过，设计规范也已经模块化、并有针对性的给出了高保真原型界面标准。用户体验的具体指标，已经在高保真原型的迭代中测试通过。

经验丰富的Producer可能都了解，成熟网站真正模块化后的内容其实不多，无非头、尾、导航、页签、表格、列表、搜索等等。传统方法流程的没有把操作体验与功能体验割裂开来，以至于来回折腾，反复做了大量工作才让产品模块化。根据设计规范迭代提升用户体验有两步：

1. 先处理界面视觉效果，比如分情况美化数据表格、文章列表等。
2. 再处理界面交互效果，比如可以把某些跨页流程改为层异步加载等。

永远记住不可能一步到位，花本钱的创意设计要用保守方案，用户体验是奢侈的。对多数应用开发工程师来说，使用样式表控制表现是件神奇而时髦的事情。光秃秃的一个架子，加上css马上就能风光起来，并且还不影响已经开发出来的程序，有点不可思议。

其他

敏捷设计思路同样来自前辈们总结过的软件工程思想，只不过换在了设计支持角度。真正的敏捷设计必然与开发绑在一起，只在产品阶段的砍掉文档、砍掉步骤、砍掉管理对全局影响不明显。

对产品团队来说，应该不断利用等待空闲调整规划，用任务分解、故事板等专业手法出文档优化结构。敏捷设计关键不在技术有多高深莫测，而是动作要跟得上节奏，前后衔接得当，才可能把时间一点点抠出来。不墨守陈规，把专业方法打散使用，融会贯通于每个思考点。

UCD翻译小组的同学们已将Boxes and Arrows的这篇Prototyping with XHTML译成中文，操作细节和心得很丰富，关于快速迭代总结的相当好。类似方法我们也已实践近两年，并且主导执行过两款大型产品，核心思想超过90%重合，以上补充了部分本地化快速产出经验。

原文说“只需要花费几个小时，学习一下网上众多的在线教程，你就可以立即开始书写xhtml。”事实上即使计算机背景的同学，没有两三年功力，要实现兼顾前后的无缝协作都很困难，搞不好还会返工增加工作量。但长远来看，这样的训练很有意义，用web方式做web-based产品设计的优势将更垂直的专业、体系化发展。

Spend just a few hours following any of the innumerable online tutorials and you’ll be writing XHTML markup in no time.

团队成员越少，沟通效率越高；每人承担越多，整体风险越低。这是行云流水的产品、技术并行迭代的优势体现。总之，除对瀑布模型进程深刻认识，方法流程得靠团队的内力来推动。

Web-based Product Design Process - Waterfall Model.pdf

递推流程有明显的阶段划分僵化劣势，优点缺点显而易见：

1. 适合技术较弱或缺乏经验的设计团队。
2. 适合容易理解但很复杂的产品，易于组织和管理。
3. 适合稳定的产品定义和很容易被理解的设计解决方案。
4. 适合对产品规模的升级和架构扩展，质量容易保证。

与软件工程思想并无二致，基于以上特点，递推流程尤其不适合互联网产品的创新设计。虽然经过江湖前辈的努力总结提炼，我们在处理并发和迭代实践上已经有了不少突破。但我个人认为，都没有从根本上脱离“递推”的思路，做个简单搜集整理：

需求 > 设计 > 构建 > 测试 > 发布

基础调研 > 产品分析 > 交互设计 > 原型设计 > 详细设计 > 设计维护

概念阶段 > 探索阶段 > 定义阶段 > 细化阶段 > 开发阶段 > 发布阶段

可行性评估 > 产品原型 > 界面设计 > 规范整理、功能实现 > 上线 > 分析报告、优化方案

需求定义 > 快速原型 > 交互式模型 > 开发与上线

很多时候，往往以为自己理解了概念，却只有等再理解下个概念之后，才明白以前认识还不够。我们都是在某个点出发，逐渐放大试图了解全局，然后才可能正确认识自己的位置，并找到适合自己的突破口。

长久被专业名词困扰和误导，我知道它们肯定是一体的，但如何分类、组织、建立联系，让整个框架立体化，合理解释似乎并不是那么容易。基于自己现阶段知识结构，以及同行们反馈的各种观点，重点介绍新突破。

1. 行业，在何种业务内做事？
2. 指导理念，在哪些原则下做事？
3. 工作方式和流程，一个人怎么做事？
4. 团队协作，一群人怎么做事？

组织理念并分层

思想信仰——以用户为中心的设计
实现目标——良好用户体验
具体指标——可访问性、兼容性、可用性、标准化、搜索引擎友好

接受来自IBM的概念定义启发，依次分为思想、目标、指标三大逻辑层面。关键在于指标问题上，我认为web-based产品因为客户端多样性原因，远不止可用性这一项，经过补充排序结果如下：可访问性、兼容性、可用性、标准化、搜索引擎友好。

可以看到可访问性、兼容性、标准化、搜索引擎友好都是web-based产品独有的，这也是做web比做soft麻烦的根本原因。相对来说，我处理可访问性、兼容性、标准化、搜索引擎友好，比可用性更得心应手，这与我的背景、经验和兴趣有关。因此我不会去做soft-based的事情，并且完全有理由相信，可用性不是最重要的指标。

理念只是贯穿全局的方针原则，并不具有实操的指导意义。虽然理念都有独立中心思想，但操作层面有交集，所以容易引起各种争论。在做事角度，任何理念角度深入下去，都可能不同程度见到效果。但要把事情做到极致，需要平衡各项指标。

组织流程和方法

概念阶段——网站目标、用户需求、功能规格、内容说明
设计阶段——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计
制作阶段——原型制作、客户端编程

曾在纵深协作方式中提出扁平结构协作初步设想，减少沟通环节避免理解缺失，用灵活性来适应互联网的快速产出和快速迭代，整个流程就分概念、设计、制作三大阶段。《用户体验的要素》所提的战略、范围、结构、框架、表现五层对理解帮助很大，但不适合走操作流程。

同时，书中观点对应提出来的各专业方法，我认为还缺少对web-based原型工作的支持，因此容易造成与开发之间的断层。这部分俗称“前端开发”工作一直都处在前后不搭的尴尬地位，补充两个关键点，第一属于产品设计范畴，第二还有原型制作、客户端编程两个层级。

组织角色和交付物

产品经理——蓝图
产品设计师——文档
产品工程师——原型

曾在模拟高效团队中提出标配三人团队的初步设想，也是Google的行事作风。

交付物部分值得商榷，按照《Communicating Design》的总结有需求、设计、策略三类，但我认为有两大问题，第一把所有产出都叫documents欠妥，第二缺少对web-based产出的指导。按属性分为蓝图、文档、原型三类比较恰当，把蓝图从文档中独立出来，原型则是必要补充。

去年曾提出过使用页面线框图提速设计流程，也不止一次公开分享其成果，核心指导思想是提高灵活和可控性，用web的方式做web-based产品设计。最近更有Prototyping with XHTML作者称之为“一个伟大的方式从xhtml原型开始。”

a great way to embark on that journey is to start prototyping with XHTML.

关联理念、流程和交付物

思想信仰——概念阶段——蓝图
实现目标——设计阶段——文档
具体指标——制作阶段——原型

理念都是前人花时间花精力总结出来的、带有哲学观点的清晰表达，是做知识传承的重要参考。肯定都是虚的，实际的东西没资格叫理念。理念只可能“引导”做事，而无法指导，易学难懂也最无趣。但为避免混淆，和更有针对性的解决问题，还得努力搞清楚。

典型如标准化，针对前端开发提出了一系列颠覆性思路，但目前互联网还是个市场占有率确定标准的时代。从操作层面看，四年前我认为太过理想化，现在依然保持此观点。

各层级概念应该对应到做事流程，并有阶段性的产出。在结合流程、交付物后，从这条纵向线索中很容易看清“以用户为中心的设计、用户体验、可用性”之间的区别。同理，迭代也应尽量保证在各阶段内完成。上线后的产品，再去试图更改概念阶段的游戏规则，基本等于推倒重来。

关联交付物、角色和方法

蓝图——产品经理——网站目标、用户需求、功能规格、内容说明
文档——产品设计师——信息架构、交互设计、界面设计、导航设计、信息设计、视觉设计
原型——产品工程师——原型制作、客户端编程

曾在用户体验的误解中提出角色对应方法初步设想，我非常不赞同专业“用户体验团队”的协作方式，难道产品经理们做事不考虑用户体验么？还是说把用户体验先留着，等某些人来做？显然不可能，因为方法一旦脱离具体业务就成了学术论证，方法不可能创造结果，只可能加速完成。

根据专业方法制定角色，或走设计流程，我觉得都不可取。做互联网设计，应该学会身兼数职。况且所谓的专业方法其实就那么点东西，上手很简单，现在全球知识共享又几乎没门槛，学会做事太容易了。在人才培养角度，懂方法再熟练业务的难度，肯定要超过懂业务再学方法。

最好的Producer，有人可以带领大家做的更好，没人自己也能抗下来。

——————————

Ver1.1 为更细致体现专业性，对专业方法做出调整，严格对应《用户体验的要素》所做总结。
Ver1.0 图右上增加了目标导向说明文字。Web-baesd Product Design ver1.0

首阳代表来自纽约的首阳斋，也是胡盈莹、范季融夫妇的私人收藏斋名，十八年积累所成。

偶然碰到，事前并没有查找资料。我打小喜欢古董，看不懂也喜欢，初中开始在尔虞我诈的古玩黑市跑江湖。古董最美不是东西本身，而是背后积淀的文化内涵，和收藏者留下的曲折故事。

偶尔有老者饱含感情的驻足观望，或如数家珍般对身边朋友介绍。碰到好几次工作人员拭擦展柜玻璃，清理参观者紧贴玻璃留下的各种痕迹，但从来不会打扰我们，感觉特别不好意思。

上海博物馆外表毫不起眼，但大堂内便能感受那种用料奢侈的装修，还有气魄。藏品异常丰富，青铜器、陶瓷器、书法、绘画尤为特色，只是时间太紧，完全走马观花。不过，我感觉少数民族工艺展厅放在“上海”博物馆有点无厘头。

越来越发现类似大城市比较有资源的地区博物馆的特色不清晰，藏品全部中国历代、中国古代、中国明清这样的断代区划，那为什么还叫首都博物馆、上海博物馆呢？还不如第一国家博物馆、第二国家博物馆来的贴切。

值得一提的是，在“首阳吉金”展览专馆里，金发碧眼的欧美游客比亚洲人还多。在电脑模拟给瓷瓶绘画的屏幕上，有位老外可能是无比仰慕的留下了“MADE IN GERMANY”。

上海博物馆 2008
http://www.rexsong.com/photography/shanghai/shanghai_museum_2008.htm

首阳吉金——中国古代青铜器展 2008
http://www.rexsong.com/photography/shanghai/shouyang_studio_2008.htm

据说国庆期间，卖票窗口的排队可以整整绕上海美术馆一圈。

进门不远，一副毫无构图技巧、摄影技巧，而且还不清晰，带不来任何美感的东方明珠电视塔大照把我们雷的不轻。就是那种位图被放大，满脸马赛克的效果，害我看说明的勇气都没了。

很多光影、摄像头、数码片这样的高科技，实在不对我胃口。二楼展示老上海风情的影音图片、历史文献还蛮有意思。尤其有面呈现上海变迁史的白墙，通过信息块构建楼层，并用楼层高低串接时间线索，我喜欢这样静静的倾述。

无数年轻人，跑到下边摆出各种post合影留念，看来我们都老了。

上海美术馆 2008
http://www.rexsong.com/photography/shanghai/shanghai_art_museum_2008.htm

快城快客——第七届上海双年展 2008
http://www.rexsong.com/photography/shanghai/trans_local_motion_2008.htm

——读《web信息架构》

其实互联网设计阅读推荐是读此书后，受启发完成的。因为我觉得想清楚了关键点，在各自不同角度深入下去，虽然得到的东西差不多，但思路千差万别。

也许这就是交集越大，协作越顺畅的必然。在产品实践中，我发现超过80%的问题都与信息架构有关，最容易引起争论的也是。书中有一节专门讨论“什么不是信息架构？”搞清楚的目地不是更好的分离职能，而是为了在团队协作中更游刃有余。

有计算机背景的同学阅读此书可能相对容易，牵涉大量信息技术术语、以及思维模式。适合有实操经验的产品架构、内容从业者充电，相对大量方法我觉得最受益的恰恰是偏理论部分。当然，如何传达研究结果、保卫研究结果也给同行们提足了醒。

产品架构体系

曾经接受了个观点，互联网运营的架构体系有三套：业务架构、信息架构、技术架构。

以我的粗浅理解，尝试进一步解释。业务架构以赚钱为中心，信息架构以用户为中心，技术架构以稳定为中心。架构的目标，是要建立一个坚实的、经得起时间考验的体系。过度强调哪一方，都会不同程度的对整体造成影响。

在业务模式上大谈以用户为中心的唬头都是假话，时间问题而已。技术架构在软件工程学科中已发展很成熟，但在工程师主导开发的网站中容易出现不顾用户感受的“工程”模式，信息架构就是在这样的背景之下诞生的。

信息架构体系

信息架构是学术名词，互联网只是利用其基础原理来促进转换，阅过很多分析产品“信息架构”的探讨性日志，大都只单方面的从功能入手，我觉得这顶多触及到了功能结构层面。

我理解的web-based信息架构实践，最终应该是各类型方案和规划，以策略为主。比如在上周在书友会网络相册应用及策略分析中提到的“组织策略、管理策略、外链和存储策略、权限策略”都属于此，尽早搞定逻辑漏洞规避将要发生的问题，这是IA从业者的核心价值所在。

类似探讨div布局、css呈现、js行为也不适合叫“内容”架构，浏览架构还比较恰当，前端架构师的职责就是处理类似页面制作需求。在高标准压力下，架构理论的引入是必然。

真正的内容架构，我认为至少分organization, navigation, labeling三大步骤。前两点谈的多，labeling其实也好理解，比如我们会碰到类似场面，产品最高级别用户是叫站长，还是管理员？邮件系统最快的版本是叫极速，还是简约？

我的个人网站一直在做架构方面的新策略尝试，想解决个核心问题，如何让有价值的内容保持访问量？曾经在网站和博客的区别中提到“原创之后的内容细分不应该由Blog来完成。”这也是我常给朋友建议的原因“别使用www域名或目录搭建博客，这样会限制住整体格局。”

搜索引擎优化及展望

正巧前些天公司创新日听了《解密SEO-搜索引擎优化与网站成功战略》作者欧朝晖先生的讲座。国内某些大力吹捧SEO如何简单、没有技术含量的专著里，除通过小概率案列论证些显而易见的道理外。剩下几乎都是有关网站优化的内容，但又无法解释什么叫框架？什么叫结构？什么叫元数据？既不具备指导意义，也没有科学理论做依据。

其中缘由，去年在系列探讨中有详细阐述。在实践中我发现，信息架构有问题的产品根本无法进行SEO。其实在不同角度深入做事都是方法问题，但总有些小事都做不好的家伙喜欢谈大道理，喜欢阳春白雪的强调自己而忽略别人。

上次在阿里日本面试，与同事们聊天时我提到信息架构的流程引入问题，时隔一年已经更成熟。正如六月在把体验理论变成现实所提到的预期，相信随着这本《web信息架构》中文版的发行，信息架构将迎来理论执行上的第一个高峰。

Web-based UCD Books.pdf

读过的比较少，零零散散看下来感觉体系还是比较清楚，根据个人观点组织起来。特地要强调web-based，这样指导性会更强，我觉得咱们已经过了在理念上得到共鸣的阶段。

第一在职能职责维度，其中designing显然是广义上的概括，没有再细分研究、策划过程。从knowing到thinking是管理层必要的入门读物，尤其《别让我思考》有好几位朋友说受益匪浅，虽然我不觉得是那么的醍醐灌顶。

《Don’t Make Me Think》
《The Elements of User Experience》
《Communicating Design》
《Designing with Web Standards, 2nd Edition》
《Web Accessibility》

第二在知识结构维度，其中scope, structure, skeleton, surface来自《用户体验的要素》总结，但没有strategy。我觉得战略层上的UCD主要与业务有关，不适合拿出来单独谈，表现层视觉设计暂时也没找到合适推荐；prototype, application则是我自己的看法。

《The User Is Always Right》
《About Face, 3nd Edition》
《Information Architecture for the World Wide Web》
《Designing Web Navigation》
《Information Design》
《Designing Interfaces》
《Web Form Design》
《HTML XHTML: The Definitive Guide》
《CSS: The Definitive Guide》
《JavaScript: The Definitive Guide》
《Dynamic HTML: The Definitive Guide》
《Ajax: The Definitive Guide》

同时也看到行业发展带来的技术突破，比如原书定义的框架层只包含导航设计、信息设计、界面设计。我把《Web Form Design》也加了进去，因为感觉在web2.0之后，表单处理已成为web framework重要组成之一。

方法技能方面，我倾向于知识点突出、独立深入的专业书籍。市场上有大量见解浅显老调长谈、四拼八凑包罗万象的畅销入门读物，建议搞IT专业技术的编辑向O’Reilly的前辈们学习。

顺便说句，O’Reilly多年来在图书封面乱画小动物的陋习，越来越可爱了。

——————————

Ver1.1 补上了Strategy Plane，也许写出来更好。
Ver1.0 为方便打印，提高了色彩对比度。

来自Usability Post的Categories vs Tags作者认为“就博客而言，标签没有太大意义。”

I don’t think that for blogs tagging makes much sense.

首先标签重要性与使用频率无必然联系，由此判断“使用标签来浏览比较困难”的结论不成立；其次标签下的内容数量与用户满意度也无必然联系，一个内容有可能满足用户需求，数千条内容也可能不满足用户需求。

所以我完全不赞同这样的说法，标签对blog有没有用，不是标签特性决定的，关键看写blog的人如何使用。无独有偶，正好一年前我在内容、标签和分类中已记录了类似状况的解决思路。

标签既没规定呈现形式，也没说必须要给用户看到。实际上，标签适合做泛描述，是必不可少的搜索结果优化手段。下边有人评论也许最好的方式是类别+标签，而不是类别vs标签。也有人提到开源系统Drupal已同时使用类别、标签，并提供了建立之间联系的途径。

或者提个类似更新的观点，百度知道之所以创新成功，就是在给互联网贴标签。

观察过不少用户的相册，用户需求主要有如下几类：

1. 方便管理和获取，做影集或者图片仓库。
2. 方便分享和沟通，精品展示窗口，尤其是摄影作品。
3. 方便外链，当作网络存储来使用。

Flickr与Picasa就是这么两款典型产品。他们的区别在于，Flickr以网络应用为切入点，Picasa则是本地应用。在产品结构角度，Flickrs以照片为中心，Picasa则以相册为中心。

组织策略

Flickr默认提供photos单张浏览，按上传时间倒序排列，最先看到后上传的。首页提供layout个性化定制，组织形式上现在是photostream, collections, sets的三层结构，并可以根据如下列表观察到整个由简入繁的发展里程：

Flikcr > Your Photos > Sets > Photo
Flikcr > Your Photos > Collections > Sets > Photo （付费用户增加collections功能后）
Flikcr > Your Photostream > Collections > Sets > Photo （增加vedio支持后）

Picasa组织上简单的多，默认就提供albums浏览，类似Flickr的sets类型，也是按上传时间倒序排列。本地管理提供有平铺文件夹结构、文件夹树结构两种模式。

Picasa > My Photos > Albums > Photo

管理策略

在方便快速浏览的需求上，Flickr因为页面宽度固定默认sets内照片为固定最小规格，Picasa由于页面宽度自适应则提供有针对albums内照片预览的大小调整功能。

Flickr即使花费大量时间组织collections, sets后，我还是更愿意用搜索功能。其上传过程也一直在尝试良好交互促进用户保证每张照片的tag, title, description信息量，通过对数据挖掘的关键性引导，大大提高了管理有效性，其实就是系统内的SEO理论应用。

Picasa本地albums可以选择创建日期、最近修改日期、大小、名称做关键索引，但搜索只能匹配文件夹、文件命名两个字段。可见Picasa组织关系单一，比较适合对已知数据的管理，量大时效率会明显低下来。

此外，Flickr提供了独立的archives功能，支持对拍照日期、上传日期两条索引检索。

外链和存储策略

Flickr提供有Square, Thumbnail, Small, Medium, Large, Original六种大小规格形式，除Square是固定75*75规格，Original是原图，其他都是等比缩放。

• http://farm4.static.flickr.com/3032/2941250850_c5055b8fdd_s.jpg
• http://farm4.static.flickr.com/3032/2941250850_c5055b8fdd_t.jpg
• http://farm4.static.flickr.com/3032/2941250850_c5055b8fdd_m.jpg
• http://farm4.static.flickr.com/3032/2941250850_c5055b8fdd.jpg
• http://farm4.static.flickr.com/3032/2941250850_c5055b8fdd_b.jpg
• http://farm4.static.flickr.com/3032/2941250850_4ca779e21c_o.jpg

其中farm4是服务器，曾经被GFW掉的是farm1, farm2两台，新增的farm3, farm4国内都能正常访问。另外，Flickr各尺寸规格由特定参数控制。唯一特殊的是原图命名经过再次加密，因为曾出现过参数规律泄漏原图地址，然后被用户投诉的状况。

Picasa提供的全部是等比缩放，根据宽度分144px, 288px, 400px, 800px四种规格，并且根据此宽度标准来判断是否压缩图片质量。比如预设宽度为800px的情况，当实际等于或大于800px时，一张400k大小的图片，会被压缩到一百多K；如果实际小于800px则显示原图。

• http://lh3.ggpht.com/songvision/SPX9LaKkXoI/AAAAAAAACAY/FCa0r1v9jAc/s144/P1160855.jpg
• http://lh3.ggpht.com/songvision/SPX9LaKkXoI/AAAAAAAACAY/FCa0r1v9jAc/s288/P1160855.jpg
• http://lh3.ggpht.com/songvision/SPX9LaKkXoI/AAAAAAAACAY/FCa0r1v9jAc/s400/P1160855.jpg
• http://lh3.ggpht.com/songvision/SPX9LaKkXoI/AAAAAAAACAY/FCa0r1v9jAc/s800/P1160855.jpg

其中lh3也是服务器，但Picasa是通过对路径加密来保证url唯一性，不会更改原图命名。显然，Picasa仅判断尺寸的做法不太符合常规，另外所有尺寸规格都有镜像，而不是接收请求后再做计算输出，财主办事果然有风度。

权限策略

Flickr首先简单分公开、私有两种级别，紧接着在私有的情况下，可以增设对朋友、家人的分享，这样的权限结构更接近真实生活圈子。Picasa仅支持对albums的权限设置，并且只有公开、不公开两种设置，社区感欠缺不过倒也符合产品定位。

同时Flickr不支持直接控制Sets权限，只是在organize中提供有一系列较方便的批量操作。典型简化产品结构规避技术难度，同时强化交互弥补结构不灵活的优秀案例。

上周末自虐，早上5点50起床，吃完早餐6点30从中关村出发。

到健德桥拐上八达岭高速，然后往北过回龙观到昌平与小强、高大他们汇合，比约定整整晚了1个小时。路上问路、找路花时间不少，另外辅路上车太多，还有成群结队逆行的自行车。

昌平出来向北，旅游区的路就是好，这省道显然比普通国道都好走。黑山寨已经爬的有了内伤，结果他们告诉我是热身。放坡下去便是黄花城，感觉有点不对，身上没电了一样，才想起昨天晚上在白鸦那光喝酒了，饭都没吃。赶紧买了德芙巧克力（假货）和康师傅饼干。

接着就是他们所说令人崩溃的长坡，看数据黄花城到四海观景台大概是16公里的连续爬坡，爬升海拔有600多米。我的越野车无小盘，连推带骑上了杏树台，休息了半个多小时，体力奇迹般恢复，再爬到顶似乎很容易。

我的习惯，如果速度低于5km就下来推，堪比步行但更费体力。放坡速度严格控制，一来大齿胎阻力大，人轻车轻惯性小；二来很早很早以前在马路上摔过车，阴影始终挥之不去。

下来到黄花城，面对野长城，三点多吃过下午饭，再慢悠悠往回走，回昌平天已快黑完。搭呆总车到回龙观，再走软件园、上地、北大，回中关村，20点10分自虐完毕。