Web 2.0的设计模式

 在“模式语言”（A Pattern Language）一书中，克里斯多夫•亚历山大（Christopher Alexander）为精炼描述对于体系结构问题的解决方案，开了一种格式上的处方。他写道：“每个模式都描述着一种在我们的环境中一遍又一遍地出现的问题，并因此描述了对该问题的核心解决方案。以此方式你可以使用该方案上百万次，而从不需要重复作同样的事情。”
1. 长尾
小型网站构成了互联网内容的大部分内容；细分市场构成了互联网的大部分可能的应用程序。所以，利用客户的自服务和算法上的数据管理来延伸到整个互联网，到达边缘而不仅仅是中心，到达长尾而不仅仅是头部。
2. 数据是下一个Intel Inside

应用程序越来越多地由数据驱动。因此：为获得竞争优势，应设法拥有一个独特的，难于再造的数据资源。
3. 用户增添价值
对互联网程序来说，竞争优势的关键在于，用户多大程度上会在你提供的数据中，添加他们自己的数据。因而，不要将你的“参与的体系”局限于软件开发。要让你的用户们隐式和显式地为你的程序增添价值。
4. 默认的网络效应
只有很小一部分用户会不嫌麻烦地为你的程序增添价值。因此：要将默认设置得使聚合用户的数据，成为用户使用程序的副产品。
5. 一些权力保留
知识产权保护限制了重用也阻碍了实验。因而，在好处来自于集体智慧而不是私有约束的时候，应确认采用的门槛要低。遵循现存准则，并以尽可能少的限制来授权。设计程序使之具备可编程性和可混合性。
6. 永远的测试版
当设备和程序连接到互联网时，程序已经不是软件作品了，它们是正在展开的服务。因此，不要将各种新特性都打包到集大成的发布版本中，而应作为普通用户体验的一部分来经常添加这些特性。吸引你的用户来充当实时的测试者，并且记录这些服务以便了解人们是如何使用这些新特性的。
7. 合作，而非控制
Web 2.0的程序是建立在合作性的数据服务网络之上的。因此：提供网络服务界面和内容聚合，并重用其他人的数据服务。支持允许松散结合系统的轻量型编程模型。
8. 软件超越单一设备
PC不再是互联网应用程序的唯一访问设备，而且局限于单一设备的程序的价值小于那些相连接的程序。因此：从一开始就设计你的应用程序，使其集成跨越手持设备，PC机，和互联网服务器的多种服务。

原文地址：Web 2.0 Design Patterns（Web 2.0的设计模式）

Web 2.0 Design Patterns
In his book, A Pattern Language, Christopher Alexander prescribes a format for the concise description of the solution to architectural problems. He writes: "Each pattern describes a problem that occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice."

The Long Tail
Small sites make up the bulk of the internet's content; narrow niches make up the bulk of internet's the possible applications. Therefore: Leverage customer-self service and algorithmic data management to reach out to the entire web, to the edges and not just the center, to the long tail and not just the head.
Data is the Next Intel Inside
Applications are increasingly data-driven. Therefore: For competitive advantage, seek to own a unique, hard-to-recreate source of data.
Users Add Value
The key to competitive advantage in internet applications is the extent to which users add their own data to that which you provide. Therefore: Don't restrict your "architecture of participation" to software development. Involve your users both implicitly and explicitly in adding value to your application.
Network Effects by Default
Only a small percentage of users will go to the trouble of adding value to your application. Therefore: Set inclusive defaults for aggregating user data as a side-effect of their use of the application.
Some Rights Reserved. Intellectual property protection limits re-use and prevents experimentation. Therefore: When benefits come from collective adoption, not private restriction, make sure that barriers to adoption are low. Follow existing standards, and use licenses with as few restrictions as possible. Design for "hackability" and "remixability."
The Perpetual Beta
When devices and programs are connected to the internet, applications are no longer software artifacts, they are ongoing services. Therefore: Don't package up new features into monolithic releases, but instead add them on a regular basis as part of the normal user experience. Engage your users as real-time testers, and instrument the service so that you know how people use the new features.
Cooperate, Don't Control

Web 2.0 applications are built of a network of cooperating data services. Therefore: Offer web services interfaces and content syndication, and re-use the data services of others. Support lightweight programming models that allow for loosely-coupled systems.
Software Above the Level of a Single Device
The PC is no longer the only access device for internet applications, and applications that are limited to a single device are less valuable than those that are connected. Therefore: Design your application from the get-go to integrate services across handheld devices, PCs, and internet servers.