design principles: web 2.0 & permaculture

Tim O’Reilly’s 8 Web 2.0 design patterns:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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."

6. 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.

7. 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.

8. 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.

--
David Holmgren’s 12 Permaculture design principles (paraphrased):

1. observe and interact – engage in continuous observation and reciprocal interaction with the design subject

2. catch and store energy – use existing wealth to make long-term investments in natural capital

3. obtain a yield – use captured and stored energy to maintain the system and capture more energy, i.e. to obtain a yield

4. apply self-regulation and accept feedback – use positive and negative feedbacks to design systems that are more self-regulating, thus reducing the workload

5. use and value renewable resources and services – in business terms, use income over capital assets

6. produce no waste – design systems to make use of all outputs so that no waste is produced, à la Bill Mollison’s ‘it’s not an excess of snails but a deficiency of ducks’

7. design from patterns to details – use patterns in nature and society to understand what is seen, and use patterns from one context/scale to design in another

8. integrate rather than segregate – place elements in such a way that each serves the needs and accepts the products of the others; each element performs many functions and each function is supported by multiple elements

9. use small and slow solutions – design systems to perform functions at the smallest scale that is practical and energy-efficient for that function

10. use and value diversity – incorporate diversity to enhance resilience

11. use edges and value the marginal – recognize and conserve the value of edges, the marginal and invisible aspects of a system, and actively expand them to increase system productivity and stability

12. creatively use and respond to change – design to change in a deliberate and co-operative way, and respond to unforeseen and uncontrollable change creatively

--
I’ll try making some sense. (But we make sense like we make pie: we just make it.) Using O’Reilly’s patterns as the basic recipe, and embellishing it with Holmgren’s principles:

1. The Long Tail – reaching out to edges of the entire web and not just the center as Holmgren’s 11th principle of using edges and valuing the marginal (easy as pie)

2. Data is the Next Intel Inside – seeking to own a unique, hard-to-recreate source of data as an aggressive variation on Holmgren’s 2nd of catching and storing energy mixed with his 3rd of obtaining a yield (data as a yield of energy?)

3. Users Add Value – involving users both implicitly and explicitly in adding value as Holmgren’s 5th of using and valuing renewable resources and services, and 8th of integrating rather than segregating (user integration as a renewable resource/service?)

4. Network Effects by Default – setting inclusive defaults as Holmgren’s 2nd, 3rd, 8th, and 11th principles, with a dash of his 6th of producing no waste (confusion of flavors, including escargot)

5. Some Rights Reserved – designing for hackability and remixability as Holmgren’s 4th of applying self-regulation and accepting feedback, and 8th of integrating rather than segregating (design self-regulating applications by making their elements/functions hackable and remixable)

6. The Perpetual Beta – not packaging features into monolithic releases but adding them on a regular basis as Holmgren’s 12th of creatively using and responding to change, with a counterintuitive sprinkle of his 9th of using small and slow solutions (the perpetual beta as small-scale design for change)

7. Cooperate, Don't Control – supporting lightweight programming models that allow for loosely-coupled systems as Holmgren’s 8th of integrating rather than segregating (cooperation as integration, segregation as control)

8. Software Above the Level of a Single Device – designing applications to integrate services across handheld devices as (yet again) Holmgren’s 8th of integrating rather than segregating (devices as elements that perform multiple functions and/or functions supported by multiple elements)

--
Which leaves the question of how to incorporate:

1. observe and interact
7. design from patterns to details
10. use and value diversity

into Web 2.0. Or 3.0. Or Webs. So…when can we start up the Macy Conferences again?