Date: Sun, 11 Feb 1996
Last week's L3D meeting began with a presentation by Ernie of some failures of end-user programming in architecture, citing Alexander's A Pattern Language as a source of the idea that people could design their own living spaces. I would like to present a positive counter-example.
In my dissertation I cited Alexander as claiming that his patterns of architectural form were to be used by each person adapting them to their own preferences and local conditions. My thesis advisor, Ray McCall, argued against me that Alexander meant his patterns to be used in a rigid, cookie-cutter way.
After completing my dissertation, my next system-building effort was to build a house. I studied Alexander's book carefully and worked closely with an experienced architect. The architect and I (and my wife) engaged in an iterative process of discussing and critiquing each other's ideas in detail. My wife and I also worked closely with individual contractors and suppliers to design and select systems like lighting, sinks, doors, paint colors, cabinetry, etc. In my design effort I relied heavily on Alexander's patterns to provide a language for conceptualizing, arranging and critiquing. The result was a beautiful and unique house that expresses our personalities, our aesthetic and our local setting. The house fits the site -- which is rare in our neighborhood -- and meets our daily living needs perfectly. Most visitors (including our neighbors, most of whom built houses without much end-user designing) are impressed with the house.
(Click here for a tour of some interpreted patterns in my house.)
When Ray toured our house recently he was struck by the way Alexander's patterns were, in every application, interpreted creatively by me. For instance, the pattern "light on two sides of every room" calls for outdoor windows on at least two walls of every room. My dining room has only one outside wall, so I left an inside wall open to the hall, kitchen and living room, so that light could flow in from those rooms. Or take Janus' critic that the sink should be under a window. Because I adapted Alexander's farmhouse kitchen pattern and put the kitchen in the center of activity, it had no outside walls. So, I left the wall above the sink counter open to the living room and to its expansive view across the plains to the flatirons. This gives the sink-user an interesting view, light and social contact. (But would Janus be happy? The idea that patterns are to be creatively interpreted means that critics must be very abstract or subject to the designer's interpretive perspective -- but that would take a dissertation to discuss.)
In summary, Alexander gave me a language for programming my house as an end-user. It was a flexible language that allowed for interpretation. It empowered me by opening up design possibilities that I had not known about without it. Having looked at a number of books, I found Alexander's the only one that really gave me a useful sense of how to think about architectural space. His 253 patterns provided critics that I applied repeatedly to the design of my house.
How does this relate to end-user programming of software? I think at least three distinctions are relevant. These were all implicit in last week's discussion, but are worth subjecting to incremental explicitness:
 | 1. Atoms versus bits. In Being Digital, Negroponte argues these are different universes. It seems hard to modify an existing house without dynamite, but trivial to modify a collection of bytes. This needs to be a more subtle distinction, I think. With tools (sledge hammer, saw) and skills (carpentry, sheetrocking) one can indeed tear down walls and erect new ones. Just watch out for load-bearing walls. In software, it also takes tools (high-level visual environments, EUP languages) and skills (understanding the structure and function of routines) to modify systems. And watch out for all those functional dependencies among routines. Software may not consist of atoms at a fundamental level, but it has its own complex kinds of inertial mass. |
| 2. Personal design versus groupware. Ernie's examples involved conflicts among multiple end-users. I only have to deal with my wife, and we can come to agreements. Even in just tailoring a software package through its preferences settings, conflicts can arise when there are multiple users. Look at our problems with EndNote, trying to adapt to a group software designed for single users. So there are issues of end-user programming and separate issues of making chanages within groups of users. |
| 3. Programming from scratch versus modification. I tried designing my house from scratch but did not get too far until an architect came up with a basic design based on my specs. Then I had something to interpret and to critique. Almost all professional programming involves heavy reuse and adaptation. Modern programming environments are supporting this increasingly with application templates and object libraries supplying typical basic functionalities. A useful and usable EUPL must have a carefully selected set of domain primitives and come with a seed of typical and prototypical implemented applications. |
. . . from the philosopher's corner . . . Gerry
Go to top of this page
Return to Gerry Stahl's Home Page
Send email to Gerry.Stahl@drexel.edu
This page last modified on January 05, 2004