Buildings that learn and interfaces that might do the same?
There is a long list of interesting issues to be pursued at this stage in the application of design patterns to interaction design. Some of the questions weíve asked ourselves at Brighton and in Edinburgh at InterCHI have been concerned with:
The topic Iíve chosen to concentrate on derives from the last of these, and was motivated by a rereading of How Buildings Learn, Stewart Brandís stimulating study of the ways in which buildings can more or less successfully change over time to support new uses. Brand aligns himself with a small band of humanistic, use-oriented architects, designers and analysts, including Kevin Lynch, Jane Jacobs, Frank Duffy and most strongly, Alexander, concentrating on the idea of designing with future change in mind. One of the central ideas in the book is that the architect/designer cannot predict exactly how people will be using the building and that some buildings - those whose structure and space plan lend themselves to flexibility - have a much better chance of being happy places to live and work, and more capacity for successfully enduring than those whose every detail is fixed by the architect. Brand identifies six layers of the building: site, structure, services, surface, spatial layout and "stuff". The site is fairly fixed (indeed a particularity of Alexanderís own practice has been based on site visits which lead to modifications of plans for structure), but other layers of a durable building can often change. The "deeper" levels such as structure and services change relatively slowly, while "stuff" can change almost daily.
This description of the evolution of a "blue jeans" building lead to advice more suggestive of patterns for building, such as "donít concrete over the service supply pathways". Brand draws freely on Alexander, who himself is vocal in his advocacy of resuable, modifiable buildings. But how, if at all, should we translate this into the domain of interaction design? The obvious answer is to find a parallel with giving end users the ability to tailor various aspects of software to their own tastes and needs. There are parallels between inflexible, over-specified software and some of the failing buildings discussed by Brand. For instance, he describes buildings where even door handles and window fittings are specified by the architect, or where extensive work is needed to add a new service such as computer cabling, making change by the building user difficult to implement. Presumably like the architects of these buildings, I have never liked the notion of tailorable interfaces. This has been an intuitive and shallow reaction, but I have always felt they represented a kind of dereliction of duty on the part of the designer. How to reconcile this instinctive distrust with the very strong approval suggested by Brand et al? Should I ignore Alexander et al and go with my instinct?
Perhaps a reason for the instinctive dislike is the experience of certain software products overflowing with functions are designed to be helpful but that interfere in annoying ways with the natural flow of work - things like automatic grammar checking, the presentation of intelligent help agents and so on. They can be turned off, i.e. the software is tailorable, strictly speaking, but the default setting seems to be on rather than off, making for fussy, interfering software.
Whatís more, the link between the switched-on functionality and its effect on the screen is often difficult to trace. How are we to know that our mistyped words are miraculously corrected as we type because of Autocorrect? A new user could spend a long time searching through menus to find the command that might possibly have produced this effect.
Perhaps whatís needed is a warning to designers against creating interfering software. The default would be that if thereís a function that can be activated, it should be turned off when the software is started for the first time. An alternative approach would be for a function to be turned on, demonstrating that itís available, but very easy to turn off the first time it appears, perhaps even offering to turn itself off in some way. Obviously, though, this sort of approach risks creating another sort of annoyance.
Whichever approach is taken - all turned off or "Here I am - turn me off" - it isnít the fact of user tailoring facilities that creates the problem, but rather an unwise implementation choice.
Another example of tailoring that I hadnít recognised as such before I thought about it in this context is the Mac desktop interface. This seems to me to be a well implemented version of tailorability. Rather than attempt the impossible, i.e. predefining any sort of directory structure forcing, say, applications and documents to be stored in specific places, the Mac allows users the freedom to use the semantics of spatial relationships to organise their "stuff" using whatever "spatial layout" they choose. In the absence of a user-defined organisation, though, the Mac is ready to propose a sensible, low key, modest and unintelligent option, i.e. via the "arrange" or "clean up" function. This seems right: we have the freedom of tailorability but thereís a reasonable default if we donít want to take advantage of the facility.
Another, different, example of the place of tailorability in interface design, is found in environments such as control rooms, where people may be required to take over a colleagueís machine and particularly where itís important for one person to be able to interpret anotherís screen holistically, possibly while passing by, not really paying attention. Here, individual tailoring is a bad idea and possibly shouldnít even be be designed in. The architectural parallel might be a large, special purpose building such as a theatre or cinema: these really do need to be designed from top to bottom.
The details of these three rather vague examples are not too important. What I want to suggest (apart from the obvious thought that over the three examples some hints of a "tailorabilty" pattern begin to emerge) is that thinking about them with buildings firmly in mind suggests that the spatial metaphor, under attack in some quarters, and for good reason (see Gentner and Nielsen, 1996), is nevertheless still a very suggestive source of parallels for interaction designers. It also suggests to me that ignoring a particular aspect of the original pattern language work, as I was tempted to do, because at first glance it doesnít feel right, can be a mistake: we should be careful about picking and choosing, because the parallel between building and interaction design really is very strong, rich and direct. It also suggests to me that we move away from the roots of the Pattern Language movement at our peril, i.e. if the Interaction Pattern Language community were a political movement, I would be campaigning for the conservative wing.
Brand, Stewart. 1994/1997. How Buildings Learn: What happens after theyíre built. MIT Press.
Gentner, Don and Jakob Nielsen. 1996. The Anti-Mac Interface. Communications of the ACM, 39, 8, pp. 70 - 82.
Lynch, Kevin. 19
Jacobs, Janet. 1961/1993. The Death and Life of Great American Cities. Modern Library.