Biography

Paul Dourish is a Member of Research Staff in the Computer Science Laboratory at Xerox’s Palo Alto
Research Center (PARC). His primary research interests lie in the relationship between computer systems
design and ethnomethodological studies of practice. Currently, he is exploring these issues as part of the
Placeless Documents project, a prototype document management system for personal, workgroup and
organisational document collections. Before coming to PARC, he worked at Apple Research Laboratories
and at Rank Xerox EuroPARC, where he was the primary developer of the RAVE media space, including
the Portholes awareness system. He holds a B.Sc. in Artificial Intelligence and Computer Science from the
University of Edinburgh, and a Ph.D. in Computer Science from University College, London.

Aspects of Appropriation

This position paper takes “appropriation” as its basic stance towards the issues of evolution of groupware.
What are some of the elements of which appropriation consists?
· Flexibility. Appropriation arises from the ways in which a technology is flexible.
 Flexible has at leasttwo possible meanings here.
Flexibility can arise through control or through openness.
 Flexibility through control means offering ways for people to adjust settings, reprogram the system or otherwise technically adjust it to their own needs. Flexibility through openness means that a system is simply
uncommitted to particular forms of use or content (e.g. in the way that email is not committed to
particular styles of conversation or content).
· Community. Appropriation is a communal activity. It takes place within a community; in fact, specific
uses only become appropriated practices when they are taken up and shared.
· Visibility. Appropriation is a collective phenomenon. In order to share patterns of use and
customisation within a community, their effects have to be visible to others.
· Incrementality. Appropriation is a gradual process; a gradual accumulation of variations in practice and
technology that build on each other over time. As a result, then, technologies that provide for
incremental development lend themselves more easily to this sort of use.
· Persistence. Similarly, since appropriation happens over time, it can happen more easily in systems
which hold their state stably from moment to moment. Persistence allows changes and adaptations to
survive, and in turn (along with visibility and incrementality) to provide the basis for further
appropriation.
Of course, appropriation is not simply a technical phenomenon. The same general process can be seen at
work in the development of working styles and practices, for instance, as new organisational processes are
adapted and arranged to fit local needs. However, in the technical domain, we can begin to see how specific
features of computer systems can either enhance or interfere with the gradual intertwining of technology
and practice that constitutes appropriation and evolutionary use. Any understanding of how evolutionary
use emerges needs, then, to be grounded in understandings of the relationship between design and practice
that these examples begin to uncover.

Making Customisation Intelligible

Appropriation often involves adaptation and customisation. The problem with standard approaches to
customisation is that, by specialising the behaviour of a system to one individual or group, they
simultaneously make the system less useful or intelligible to others. So, while customisation can support
appropriation through the adaptation of technologies to immediate local needs, it also interferes with the
ability to share information with others. (This is a familiar problem to programmers, who must balance the
issues of change and reuse; we need solutions that tackle these problems in other domains without
introducing the rigid structures of software.)
One setting in which we have recently encountered this is the management of a large collection of
workgroup documents in a local government organisation (Trigg et al., 1999). We have been developing a
prototype system called Macadam (Dourish et al., 1999) which attempts to address these issues. Macadam
is a system for managing documents according to customisable category structures. However, when a user
or a group customise the category structure, Macadam retains the relationship between the original and new
structures. In this way, when document collections are presented to a different user who does not share the
same set of categorisations, the customisations can be “unrolled” and so the documents can be presented in
a way that makes sense to whoever is looking at them.

Creating Digital Genres

In an exploration of the emergence of new digital media genres, Erickson (1999) discusses a particular
pattern of communication in an on-line discussion environment.
 In the example, a group of people using
the system engage in a “limerick game,” in which they construct a limerick collectively and
asynchronously, individuals contributing lines one at a time until the whole has been assembled (until, in
the particular incident Erickson discusses, one person makes a joke by contributing an unrhymable line.)
Although one can imagine textual games of this sort arising in a variety of online chat systems, Erickson’s
analysis shows how the details of this game are, in fact, organised around very specific details of this
particular system.
 For instance, he shows how the presentation of the message transcript as a single, largely
seamless body of text (rather than as separate messages with extensive headers) contributes to the
development of the “contributary narrative” genre, and in particular encourages users to play off each
others remarks and collaboratively construct the text. In other words, this appropriated use of the discussion
system is based in a number of particular interface details. Similarly, Cherny (1999) discusses a variety of
textual practices that emerge around the specific features offered by the virtual environment she studied.

Communication through Portholes

Portholes (Dourish and Bly, 1992) is a media-space-based awareness system developed jointly at
EuroPARC and PARC in 1990, and which was subsequently the basis for related designs at U. Toronto,
NYNEX and other sites. In Portholes, period “snapshots” of offices and public spaces are distributed across
a computer network and made available through “viewers”, which present a simple at-a-glance view of
activity within a distributed work group. The original Portholes system was originally introduced within a
small group in late 1990, expanded through 1991-2, and was in continual use until the technology on which
it was based became unavailable around 1994, although related systems continued to be used within the
same group. The adoption process was, then, relatively successful.
A number of specific examples of the use of the Portholes system within the PARC/EuroPARC media
space groups illustrate the “appropriation” process at work. One of the most striking was a the use of
Portholes to send messages. On one occasion in late December, the EuroPARC users arrived in the office
one morning to find that our colleagues in Palo Alto had left us “Christmas cards” in the form of visual
displays arranged in front of their video cameras, appearing in Portholes. Most of these involved cut-out
images of themselves with festive greetings and other traditional items. Portholes created a “space” that
could be used for indirect communication. On another occasion, the communication was more directed.
Those of us in Cambridge, including a visitor from PARC, noticed that S, one of our PARC colleagues,
was working at his desk at noon Cambridge time, which was 4am in Palo Alto. The reason for this late
night work was that he was completeing his PhD dissertation. Noting that he seemed both stressed and
lonely, we conspired to cause all the EuroPARC Portholes users to wave at him at once, at which point I
also took down the server so that the images would “stick” and S’s Portholes window would be filled with
Cambridge users waving at him.

Buttons and the Tailoring Culture

Buttons was an early project at EuroPARC exploring collaborative customisation (MacLean et al., 1990).
Buttons were on-screen objects that encapsulated code. Pressing the button caused the code to be activated.
Buttons could live on the desktop, or be encapsulated into documents, which also allowed them to be
collected together (lots of buttons on a single document), incorporated into software documentation, and
included in email.
Early versions of buttons included simply the Lisp code to be executed to perform their actions. Later
versions introduced customisable appearances, so that buttons could be distinguished from each other and
given a personal flavour; and separable “parameters” so that the buttons could be tailored more easily by
non-programmers. Along with the ability to pass buttons around through electronic mail, these features
made it easier for people to share their buttons and adapt those of others to new or specialised purposes.
Heavy users of buttons might end up with as many as fifty buttons on their screen, specialised to all sorts of
different personal needs.
One thing that turned out to be crucial in the Buttons project was the fostering of what MacLean et al.
describe as “a tailoring culture”. Not only was it critically important that the technology of Buttons was
easily shareable and malleable, but it was also necessary to develop a workgroup ethos that encouraged
tailoring. This included, for example, establishing that a button you received through email or copied from
a colleague was “your button”, and hence, available for you to modify (and not still “their property” and
inviolate).

Appropriation in Action

In this paper, I want to sketch some aspects of appropriation, drawing on a couple of examples. The
examples I draw upon here are ones that I’ve been involved in myself in one way or another. They are
cases where appropriation has turned out to be a critical perspective on the development, deployment and
uptake of a technology.