Full Circle Associates

Christopher Allen nails some critical issues in Intimacy Gradient and Other Lessons from Architecture. I am snipping some key parts here, but I strongly encourage everyone to go read the full article, which is also rich with links.

The concept of Intimacy Gradient comes from architect Christopher Alexander, in his book A Pattern Language: Towns, Buildings, Construction. (Oxford University Press, 1977):

Pattern #127 - Intimacy Gradient:

Conflict: Unless the spaces in a building are arranged in a sequence which corresponds to their degrees of privateness, the visits made by strangers, friends, guests, clients, family, will always be a little awkward.

Resolution: Lay out the spaces of a building so that they create a sequence which begins with the entrance and the most public parts of the building, then leads into the slightly more private areas, and finally to the most private domains.

He gives some other great examples, then narrows down to interaction software.

In social software design, there also needs to be an Intimacy Gradient. One of the problems with Wikis is that there is often very little transition between public and intimate, and doing so can be quite jarring.

He points to an interesting study by Krebs and Holley (I need to pursue this one):

That's the main point of Building Sustainable Communities through Network Building by Valdis Krebs and June Holley. When studying a community over time, they suggest a vibrant community is made up of four stages:

1. Scattered Clusters
2. Single Hub-and-Spoke
3. Multi-Hub Small-World Network
4. Core/Periphery

The ideal core/periphery structure affords a densely linked core and a dynamic periphery. One pattern for social software that supports this is an intimacy gradient (privacy/openness), to allow the core some privacy for backchannelling. But this requires ridiculously easy group forming, as the more hardened the space the more hard-nosed its occupants become.

What I notice about this is how it echoes the structure of communities of practice, where this idea of core and periphery is one of the very hearts of a vibrant CoP. It also echoes some classic community literature.

Christopher goes on to write

Part of the solution might come from the architecture world as well -- here are some other Patterns by Christopher Alexander (see the link for Alexander's resolutions for each):

Pattern #31 - Promenade: Each subculture needs a center for its public life: a place where you can go to see people, and to be seen.

Pattern #61 - Small Public Squares: A town needs public squares; they are the largest, most public rooms, that a town has. but when they are too large, they look and feel deserted.

Pattern #69 - Public Outdoor Room: There are very few spots along the streets of modern towns and neighborhoods where people can hang out, comfortably, for hours at a time.

Pattern #42 - Sequence of Sitting Spaces: Every corner of a building is a potential sitting space. But each sitting space has different needs for comfort and enclosure according to its position in the intimacy gradient.

Pattern #147 - Communal Eating": Without communal eating, no human group can hold together.

He concludes:

We are still breaking ground and exploring new ideas in the world of social software. However, there are already extant fields of study which may give us insight into this new venue. Architecture is one of them. By better understanding ideas of intimacy gradients, pattern language, refuge and prospect, savannas, and defensible spaces, we may gain new understandings of how to build social environments which are attractive and enjoyable to more people.

Having designed and facilitating in a variety of online interaction environments for the past 8 years, itimacy, privacy, the expansion and contraction of different gradients has been a key part of building the appropriate types of social bonds for a variety of online interaction purposes. Whether it is done with the base configuration of software, with how we deploy the software, or at the most basic, how we choose to act and support agency in the simplist of interaction tools (like one email thread) matters. It is not just the simple exchange of text. It is interesting to see how this is now a much more central concern to designers and implementation folks. Glad to see it.