Open Implementation and Flexibility
in CSCW Tooikits
James Paul Dourlsh
A dissertation subm itted in partial fulfillm ent
o f the requirem ents for the degree of
D octor o f Philisophy
o f the
U niversity o f London.
D epartm ent o f Com puter Science
U niversity College London
ProQuest Number: 10017199
All rights reserved
INFORMATION TO ALL USERS
The quality of this reproduction is dependent upon the quality of the copy submitted.
In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed,
a note will indicate the deletion.
uest.
ProQuest 10017199
Published by ProQuest LLC(2016). Copyright of the Dissertation is held by the Author.
All rights reserved.
This work is protected against unauthorized copying under Title 17, United States Code. Microform Edition © ProQuest LLC.
ProQuest LLC
789 East Eisenhower Parkway P.O. Box 1346
Abstract.
Abstract
The design of Computer-Supported Cooperative Work (CSCW) systems involves a variety of dis
ciplinary approaches, drawing as much on sociological and psychological perspectives on group
and individual activity as on technical approaches to designing distributed systems. Traditionally,
these have been applied independently—the technical approaches focussing on design criteria and
implementation strategies, the social approaches focussing on the analysis of working activity with
or without technological support.
However, the disciplines are more strongly related than this suggests. Technical strategies— such
as the mechanisms for data replication, distribution and coordination—have a significant impact on
the forms of interaction in which users can engage, and therefore on how their work proceeds. Con
sequently, the findings of sociological and psychological investigations of collaborative working
have direct impact for how we go about designing collaborative systems.
In support of this relationship, this thesis concentrates on the provision of flexibility in CSCW sys
tems, and, in particular, in toolkits from which they are generated. Flexibility is key to supporting
many characteristics of group behaviour detailed by observational investigations—the improvised
nature of work and activity, individual and group tailoring, customisation and re-purposing, chang
ing group membership and activity over the course of a collaboration, and so forth.
Based on an analysis of current CSCW toolkits, and on the interaction between user behaviour and
system design, I will demonstrate that, as in many other areas of system development, traditional
notions of abstraction in system design mitigate against the design of open, flexible systems. “Open
Implementation” is an emerging approach based on the systematic and principled exposure of
mechanism in system components, “opening up” abstractions to examination and manipulation.
Concentrating particularly on distributed data management and concurrency, I will show how these
ideas can be exploited to provide an open and customisable framework enabling programmers and
Dedication.
Dedication
The character of Prospère, the magus of Shakespeare’s “The Tempest”, was reputedly inspired by
the Elizabethan scientist, alchemist and Hermetic philosopher, John Dee (1527-1608). The tenets
of Hermetic philosophy, while intricate, have a simple basis— that the structure of our earthly world
reflects the structure of the heavens. By understanding the earthly world, the alchemist would learn
about the world of the spirits; by gaining power and control over the earthly world, he would gain
“magical” power and control of the higher dimensions. “As above, so below.” So the transmutation
of base matter to gold was a metaphor for the transformation of man to god; a transformation which
could be achieved by the adept once the correspondence from above to below is understood, since
the pattern of man must be the same as the pattern of god.
Since I have spent much of the past few years trying to understand and control the link between
Acknowledgements.
Acknowledgements
The work in this thesis has had three homes—the Rank Xerox Research Centre, Cambridge Labo
ratory (formerly EuroPARC); the Computer Science department at University College, London;
and the Xerox Palo Alto Research Center. I couldn’t have asked for three more interesting and stim
ulating places to have spent the last three years, and I owe a great deal to the people who have
supported me and my work at each place: Bob Anderson, Graham Button, Wendy Mackay and
Allan MacLean at EuroPARC, Jon Crowcroft and Angela Sasse at UCL, and Annette Adler, Austin
Henderson and Gregor Kiczales at PARC.
The development of the ideas presented here has been inspired, nurtured and guided by a host of
people, only some of whom can be mentioned here. Jon Crowcroft provided guidance, advice, crit
icism and beer in admirable proportions, tolerating the rather odd path of my work with bemused
grace. Annette Adler, Bob Anderson, Graham Button, Wendy Mackay and Lucy Suchman have,
wittingly or unwittingly, contributed to my inclination towards the social which underpins this work
(although they should not be held responsible). Annette also brought together a group of people
who have provided me with much intellectual sustenance over the last year or two; David Levy,
Gene McDaniel, Bob Printis, Vijay Saraswat and Brian Smith deserve especial mention. Brian’s
work has been central to much I’ve thought and done over the last few years; one day, I hope to
understand 10% of it.
Dik Bentley, Jon Crowcroft, Alan Dix, Steve Freeman, Jonathan Grudin, Rachel Jones, Gregor Kic
zales and John Lamping have all made valuable contributions to my thinking about the ideas
described here, and to the form of their presentation.
Some of my greatest debts are to those who helped me through the deepest moments of inevitable
thesis gloom. Loma Banks, Eevi Beck, Dik Bentley, Matthew Chalmers, Lynn Cherny, Laura Dek-
Acknowledgements.
Marqvardsen, Gillian Ritchie, Ellen Siegel, Lisa Tweedie, and Alex Zbyslaw all helped with email,
cynicism, laughter, silliness and beer, and they all deserve better recompense than a few words here.
I’ll get round to you all in time.
Victoria Bellotti deserves a place on her own as both an inspiring colleague and valued friend. And
above all, thanks to Beki Grinter, who’s simply more than I deserve.
Table o f Contents.
Table of Contents
Abstract...2
Dedication...3
Acknowledgements ...4
Table of Contents...6
Chapter 1: Introduction ... 11
1.1 Introductory R em arks...11
1.2 T he Em ergence of C S C W ... 11
1.3 Ethnom ethodology and C S C W ... 12
1.4 T he D evelopm ent o f CSCW T o o lk its ...14
1.5 Flexibility and Tailorability in H C I ... 14
1.6 Flexibility and Tailorability in C SCW System s and T o o lk its ... 15
1.6.1 Flexibility from Social and Technical P ersp ectiv es...15
1.6.2 A Cross-C utting View of F le x ib ility ... 16
1.7 W hat Is To C o m e ...17
Chapter 2: Flexibility in CSCW Toolkits ... 19
2.1 In tro d u c tio n ...19
2.2 Flexibility and R e u s e ...19
2.2.1 Softw are Issu e s...20
2.2.2 H C I I s s u e s ...20
2.3 A Fram ew ork for F le x ib ility ...21
2.3.1 C ollaboration Transparency and C ollaboration A w aren ess... 23
Table of Contents.
2.4.1 R e n d e z v o u s ...24
2.4.2 G roupK it...26
2.4.3 M EA D ...27
2.4.4 S u i t e ...28
2.4.5 O v a l ...29
2.4.6 C O L A ... 31
2.4.7 O ther S ystem s...32
2.5 G enericity and E xtensibility...33
2.5.1 G enericity and Extensibility in CSCW T o o lk its ... 35
2.6 Problem s in Toolkit F le x ib ility ...37
2.6.1 Structure and S em an tics... 37
2.6.2 Extending versus R ev isin g ...37
2.7 S u m m a r y ...38
Chapter 3: Computational Reflection and Open Implementation...40
3.1 Flexibility ... 40
3.1.1 Tackling F le x ib ility ...41
3.1.2 Flexibility and A bstraction... 42
3.2 A b stractio n ... 42
3.2.1 M apping D ile m m a s ... 45
3.2.2 G aining C ontrol over A bstractions...47
3.3 O pen Im plem entation...48
3.3.1 3-Lisp and the Infinite T o w er...49
3.3.2 CLOS and the M etaobject P ro to c o l...50
3.3.3 The M etaobject Protocol in G eneral...52
3.4 Reflection, O pen Im plem entation and A b stra c tio n ... 53
3.4.1 CLOS and T e lo s ... 54
3.4.2 Com pile-Tim e and Run-tim e M O P s ... 55
3.4.3 C om putational Reflection and M etaobject P rotocols...56
3.5 S u m m a r y ...57
Chapter 4: Applying Reflection in a CSCW Toolkit ...59
Table of Contents.
4.2 D esigning O pen Im plem entations... 59
4.2.1 Scope C o n tro l...60
4.2.2 C onceptual S e p a ra tio n ... 60
4.2.3 Increm entality...61
4.2.4 R o b u s tn e s s ... 62
4.3 CSCW : The Locus o f F lex ib ility ... 63
4.4 C SC W Toolkits: A reas o f C o n c e rn ...64
4.4.1 D ata D is trib u tio n ...64
4.4.2 Concurrency and Exclusion C o n tr o l... 64
4.4.3 R epresentations o f A c tiv ity ... 65
4.4.4 U ser Interface L in k a g e ...65
4.4.5 Conference and Session M a n a g e m e n t... 66
4.5 D esign Concerns in P ro sp ero ... 66
4.5.1 D istributed D ata M anagem ent subsum es A ctivity R e p re s e n ta tio n ...66
4.5.2 D istributed D ata M anagem ent subsum es U ser Interface L in k a g e ... 67
4.6 C om m unicating A pplication S em antics...68
4.7 An O verview o f Prospero... 69
4.7.1 B ase Level Program m ing in P ro s p e ro ... 69
4.7.2 M etalevel Program m ing in P ro s p e ro ... 70
4.8 S u m m a r y ...74
Chapter 5; Divergence, Data Management and Collaborative Work ...75
5.1 Introduction: D istributed D ata M anagem ent ... 75
5.2 C rite ria ... 76
5.3 D istributed D ata and C ollaborative W o r k ... 77
5.3.1 D istribution... 77
5.3.2 M an ag em en t...78
5.4 The Em ergence o f In co n sisten cy ... 79
5.4.1 Stream s o f A ctivity and Inconsistency A voidance... 79
5.5 D iv e rg e n c e...81
5.5.1 D ivergence and V e rs io n in g ... 82
Table of Contents.
5.5.3 D ivergence and O perational T ran sform atio n ... 84
5.6 C apitalising on D iv e rg e n c e ... 85
5.6.1 S calability...85
5.6.2 M ulti-Synchronous A p p lic atio n s... 86
5.6.3 Supporting O pportunistic W o rk ... 87
5.7 D ivergence in P ro s p e r o ... 88
5.7.1 Exam ple: S h d r ... 89
5.7.2 Exam ple: Source Code C o n tr o l... 90
5.7.3 Exam ple: M ulti-synchronous E d i t i n g ...91
5.7.4 Specialisation in P r o s p e r o ...92
5.8 S u m m a r y ...93
Chapter 6: Consistency Management and Consistency Guarantees ...95
6.1 In tro d u c tio n ... 95
6.2 C onstraining D ivergence— Tw o T echn iqu es...96
6.2.1 V ariable C o n siste n c y ...96
6.2.2 C onsistency G u a ra n te e s... 98
6.3 Consistency and Concurrency in D atabase R e s e a r c h ...102
6.3.1 Sem antics-Based C oncurrency...102
6.3.2 A pplication-Specific C onflict R e s o lu tio n ... 104
6.4 Encoding Prom ises and G u arantees...104
6.4.1 Sem antics-Free S e m a n tic s ...105
6.4.2 C lass-based E ncoding... 105
6.5 U sing Consistency G uarantees... 106
6.5.1 A Shared Bibliographical D a ta b a se ...106
6.5.2 Collaborative Text E d itin g ...108
6.6 S u m m a r y ... 109
Chapter 7: Using Prospero: Application Exam ples...I l l
7.1 In tro d u c tio n ... I l l 7.2 A pplication S tru ctu re ... I l l 7.2.1 Specialisation through S u b c la ss in g ...113Table of Contents.
7.3 The G eneric Function F ram ew o rk ... 116
7.4 Sam ple A p p lic a tio n s ... 117
7.4.1 Eureka, a Collaborative Polyline E d ito r...117
7.4.2 B ugspray, a B ug-Tracking D a ta b a s e ... 120
7.4.3 Bugspray in U s e ... 123
7.5 F le x ib ility ...124
7.5.1 Com paring E ureka and B ugspray... 124
7.5.2 Flexibility In Prospero and O ther T oolkits... 125
7.5.3 OI and Reflection in P r o s p e r o ...127
7.6 S u m m a r y ... 128
Chapter 8: Summary and Conclusions ...130
8.1 R e c a p itu la tio n ...130
8.2 C laim s and G o a ls ... 132
8.3 F uture W ork and O p p o rtu n ities...134
8.4 C oncluding R e m a r k s ... 136
Epilogue ...138
Collected R eferences... 139
Appendix A: Code of Application Examples...151
1. E u r e k a ... 151
1.1 eu re k a .Iisp ... 151
1.2 u i.lis p ... 153
2. B u g s p r a y ... 154
2.1 bug s.lisp...154
2.2 u i.lis p ... 156
2.3 c o m m o n .lis p ...160
2.4 gu arantees.lisp ... 161
2.5 c lie n t.lis t... 162
2.6 s e r v e r .lis p ... 164
2.7 f la tte n .lis p ... 165
2.8 d b io .lisp ...165
Chapter 1 : Introduction.
Chapter 1 :
Introduction
1.1 Introductory Remarks
This dissertation examines the issue of flexibility in toolkits for creating multi-user applications. In
particular, I will show how a novel software architecture technique— Open Implementation (OI)—
can be applied to solve a number of problems inherent in traditional approaches, and I will present
a toolkit—Prospero— which embodies and demonstrates these ideas.
The motivation for this work is not simply the technical limitations of a set of software techniques.
Certainly, previous work has applied the 01 approach to a number of technical areas to solve prob
lems of that sort. However, the support for deeper, more thoroughgoing forms of flexibility in
support of collaborative work is also driven by the need to address a split within the disciplinary
structure of the field itself,
1.2 The Emergence of CSCW
The field of Computer-Supported Cooperative Work (CSCW) traces its history as an identifiable
discipline to a workshop held at MIT in 1984 by Irene Grief and Paul Cashman (who are also
responsible for the term). It grew quickly; in 1986, MCC sponsored the first bi-annual international
conference, subsequently sponsored by the ACM; and in 1989, a bi-annual European conference
began, held in the alternate years. CSCW has spawned sub-disciplines of its own (such as workflow
technology, frequently employed within Business Process Reengineering), conferences, journals,
prototypes, studies, and jargon.
Technological and organisational trends of the last ten years have served to reinforce the impor
tance of CSCW by strengthening the motivations which gave rise to the field in the first place. First,
the rapid dissemination of computer power—CPU performance, graphics processing, etc.—associ
Chapter 1 : Introduction.
continued and shows no signs of stopping; and at the same time, these powerful PCs and worksta
tions are increasingly connected together over local and wide-area networks. Meantime, business
trends mean that organisations are increasingly distributed. Not only is a single organisation more
likely to be distributed across multiple sites, or perhaps employ individuals working electronically
away from a principal site, but also increasing moves towards “outsourcing” and inter-organisation
collaboration makes it more likely that work is being performed through the collaborative activity
of remotely located individuals. Even within single or co-located organisations, the trend towards
automation of tasks around explicit models of business processes places an emphasis within com
putational technology on collaboration and coordination.
This is the area to which CSCW has addressed itself since the outset—the use of computer-based
tools to enhance and facilitate the performance of collaborative work, potentially distributed in
space or time. Its scope, then, is very broad, and this is reflected in the wide range of systems which
have been designed, built and studied. For example, these have included: shared whiteboard/meet
ing room systems such as CoLab (Stefik et al., 1987a) and Dolphin (Streitz et al., 1994); workflow/
process-based systems such as The Coordinator (Winograd, 1986) and the Milan Conversation
System (De Michaelis and Grasso, 1994); authoring systems such as PREP (Neuwirth et al., 1990)
and Quilt (Fish et al., 1988); drawing systems such as Commune (Ely and Minneman, 1990) and
The Conversation Board (Brink and Gomez, 1992); as well as collaborative Virtual Reality sys
tems, databases, software design environments, and others.
More significantly, perhaps, CSCW, as a field, has also drawn on a similarly wide range of disci
plinary perspectives on its own subject matter. Arising as it did partly out of the field of Human-
Computer Interaction (HCI), it is unsurprising that, like HCI, it should draw on cognitive and exper
imental psychology in addition to computer science and software engineering. However, much of
its development and perspective has been driven by the early influence of anthropology and
sociology.
1.3 Ethnomethodology and CSCW
A highly significant factor in the development of CSCW was the very early involvement of
researchers from anthropology and sociology. Just as cognitive psychology provided the underpin
nings of much HCI research in the late 1970s and early 1980s, so sociology has motivated and
Chapter 1; Introduction.
For a variety of reasons, the area of sociology most prominent in CSCW has been ethnomethodol
ogy. Ethnomethodology arose in the 1960s, through the work of Harold Garfinkel and associates.
Its roots lie in a respecification of the objectives of sociology. In particular, it reacts against a view
of human behaviour that places social action within the frame of social groupings and relationships
which is the domain of traditional sociological theory and discourse—categories and their attendant
social functions. Ethnomethodology’s primary claim is that individuals do not, in their day to day
behaviour, act according to the rules and relationships which sociological theorising lays down.
Quite the opposite. The structures, regularities and patterns of action and behaviour which sociol
ogy identifies emerge out o f the ordinary, everyday action of individuals, working according to their
own common-sense understandings of the way the social world works. These common-sense
understandings are every bit as valid as those of learned professors of traditional sociology.
From this basic observation, a new picture of social action has arisen. The ethnomethodological
view emphasises the way in which social action is not achieved through the execution of pre-con-
ceived plans or models of behaviour, but instead is improvised moment-to-moment, according to
the particulars of the situation. The sequential structure of behaviour is locally organised, and is sit
uated in the context of particular settings and times.
Ethnomethodology’s concern, since its beginning, has been the organisation of human action and
interaction. In 1987, Lucy Suchman published "Plans and Situated Actions”, which applied the
same techniques and perspectives to the organisation of interaction between humans and technol
ogy. In doing so, she opened up significant new areas of investigation both for HCI researchers and
ethnomethodologists. In both this and other work (e.g. Suchman, 1983; 1993), Suchman also helped
establish the relationship between ethnomethodology and CSCW, and the same approach has been
used by a range of researchers studying work in collaborative settings such as stock trading rooms
(Heath et al., 1995), print shops (Bowers et al., 1995), and air traffic control rooms (Harper and
Hughes, 1993). The ethnomethodological perspective on CSCW systems and design has continu
ally emphasised the flexible and open ways in which working activities are organised, and the
distinctions between the formal processes and procedures which are often encoded in CSCW sys
tems and the informal, flexible and opportunistic practices by which work and interaction actually
take place. The flexibility required of systems to support the development of these working prac
Chapter 1 : Introduction.
1.4 The Development of CSCW Toolkits
Against the backdrop of these investigations of collaborative activity, technological development
has proceeded apace.
The earliest CSCW systems were built by hand, extending techniques originally developed for
single-user interfaces and standard distributed systems to the needs of collaboration. Often, they
were designed as extensions of existing systems such as databases (Grief and Sarin, 1988) or hyper
text systems (Rein and Ellis, 1991). As both application and implementation experience grew,
specifically multi-user aspects of implementation support began to migrate into reusable bodies of
code. For explanatory purposes, we can draw an approximate distinction between execution envi
ronments and application toolkits.
Execution environments provide run-time support for multi-user applications. Often, their aim is to
allow otherwise single-user applications to function in multi-user arrangements, although they
might also support specifically multi-user features. Examples of application environments include
commercial systems such as Timbuktu and Shared-X, and research systems such as ABC (Jeffay,
1992). Many early attempts to encapsulate and reuse multi-user functionality from earlier mono
lithic CSCW systems were based on (or at least, would include) multi-user execution environments.
A number of execution environments were paired with application toolkits. Toolkits provide librar
ies of functionality for the development of specifically collaborative applications. Multi-user
interface widgets, persistent shared data stores and group-replicated objects are examples of
abstractions which might be presented in a collaborative application toolkit. As will be discussed
in Chapter 2, the design of these various toolkits reflects the needs of the particular application areas
which they were destined to support. The generality or flexibility of the toolkit, then, is reflected in
the range of applications which can be derived from it.
1.5 Flexibility and Tailorability in HCI
As CSCW development was progressing, questions of openness and customisation of system
behaviour had already become an important research issue in HCI generally (see, for example,
Trigg et al., 1987; Fischer and Girgensohn, 1990; Mackay, 1990; MacLean et al., 1990). By and
large, the focus of these investigations was on tailorability—that is, the ways in which applications
could be customised to accommodate individual differences between members of a user commu
nity. Since this work tends to make customisation available through named, accessible features of
Chapter 1 : Introduction.
high level, providing controls which either affect largely “surface” features of the interface or con
trol system behaviour at a fairly gross level. More recently, however, these investigations have
begun to move into the area of end-user programming, providing greater control over semantic fea
tures of the application, which are generally not directly expressed in the interface (Bentley and
Dourish, 1995). Notable examples include the work of Nardi (1993) in a variety of domains. Cypher
and Smith (1995) with KidSim and Eisenberg (1995) with SchemePaint.
1.6 Flexibility and Taiiorabiiity in CSCW Systems and Tooikits
A number of researchers have investigated similar issues of flexibility and tailorability in the
domain of multi-user, rather than single-user, interfaces. Greenberg (1991) follows most closely in
the tradition of customisation to accommodate individual differences (Chapter 2 will discuss other
work in more detail). Arguably, the problem of tailorability per se is considerably more pressing in
multi-user applications than in single-user ones. The problem of accommodating individual prefer
ences in single-user systems is akin to the problem of accommodating the preferences of different
groups in the multi-user case;.however, multi-user systems also face the problem of accommodat
ing the different preferences of the individual members of each group. However, there is a second,
more fundamental, problem which arises when looking at tailorability in multi-user systems; and it
arises from the traditional separation between the disciplinary perspectives (loosely, social and
computational sciences) which make up the field.
1.6.1 Flexibility from Social and Technical Perspectives
The traditional relationship between these disciplines involves sociological analyses of collabora
tive work reaching “down” from the day-to-day organisation of work to the collaborative
applications which are used to support it, while the systems perspective reaches “up” from the
requirements and constraints of the underlying systems towards the applications level, determining
the range of functionality which can be provided by those applications. In this arrangement, the per
spectives “meet” at the level of applications.
More recent work, though, has come to question the separation this implies—that is, the view that
system design requirements and constraints do not have consequences above the level of the appli
cation, and that sociological insights do not apply below. As will be discussed in Chapter 3, this
notion of the separation of levels of concern is not even entirely appropriate purely from within the
systems design perspective. Critically, though, for what is to follow, it is clear that the relationship
Chapter 1; Introduction.
eral, the detail o f collaborative activity, as explored by the ethnomethodological perspective, is
rooted in the detail o f the technology available, whether that technology is comprised of everyday
physical artifacts (such as those discussed in Heath et al.’s (1995) study of broker dealing rooms)
or computational ones (such as those discussed in Grinter’s (1995) study of software engineers).
For instance, consider the issue of conflict management over shared data. Some data object exists
in a shared workspace, and is available to a number of users for viewing and editing. A wide range
of techniques might be used to achieve this end in any particular implementation. Actions might be
serialised over a single copy of the data item; the item might have to be “locked”, or “checked out”;
or conflicts over actions applied to multiple copies might be subject to prioritisation or rollback.
The particular strategy used is not at issue here. Rather, the critical observation is that the choice of
implementation strategy lies below the application level; it is invisible—or inexpressible— above
it. In terms of the traditional relationship between the perspectives, then, this would imply that the
choice of implementation strategy is irrelevant as long as the application functionality is
maintained.
However, the details of the specific implementation strategies carry with them important implica
tions for the nature of the tasks which can be carried out. In an experimental study, Dourish and
Bellotti (1992) explored the ways in which groups of collaborating authors organised their activity
(both individual and collective) around detailed features of the collaborative interface and the
shared workspace control mechanisms, as enabled by specific implementation mechanisms. Simi
larly, Greenberg and Marwood (1994) examined the relationship between the mechanisms of
distributed data management and the functionality of the user interface. As these studies demon
strate, far from being completely independent concerns, the issues of infrastructure flexibility and
usage flexibility are closely related.
1.6.2 A Cross-Cutting View of Flexibility
The primary topic of this thesis, then, is the provision of flexibility in CSCW toolkits. Flexibility is
investigated from both perspectives. From the systems perspective, the goal is to build toolkits
which are more flexible than traditional systems, so that a wider range of applications can be sup
ported. From the usage perspective, the goal is to be able to provide flexibility in forms which
support the emergent work practices which social investigations highlight. Running through both
of these concerns, though, is the realisation that they are not independent issues. Rather, the rela
tionship between the systems and social perspectives highlights a set of concerns which cut across
Chapter 1; Introduction.
approach to both the form and function of those barriers. At the same time as unifying these two
views, this approach supports the development of a toolkit which is much more flexible than tradi
tional techniques allow—that is, it extends the “reach” of the toolkit.
The technique that I will draw upon is called Open Implementation (Kiczales, 1996). Open Imple
mentation (01) has its roots in a re-evaluation of the notion of abstraction in software engineering.
The sorts of problems which are encountered in CSCW systems are endemic to systems design, and
occur in widely diverse fields. Open Implementations reframe the flexibility problem in terms of
the role and use of “abstraction” in current software practice. OI itself has developed from compu
tational reflection. Reflection is a mechanism, based on computational self-reference, originally
employed in programming language design. By providing systems with an explicit and manipulable
model of their own behaviour, reflection introduces opportunities for the system to introspect (rea
son about its own behaviour by examining the model) and intercede (control aspects of its
behaviour by modifying the model). The OI approach applies this principle more generally to the
problems of abstraction, by beginning to “open up” system components and make them amenable
to a certain amount of control from above.
1.7 What Is To Come
This, then, is the line of argument which this dissertation will lay out and demonstrate:
1. That the evidence of empirical and naturalistic studies of cooperative work demonstrates that
usage issues and system issues are fundamentally linked.
2. That the re-evaluation of abstraction in software engineering, set out by research in Open
Implementation, applies to these issues as encountered in CSCW.
3. That Ol/reflective principles can be used to design a novel CSCW toolkit.
4. That a toolkit built along these lines yields significant improvements in design (and hence,
usage) flexibility.
Following on from the discussion here of the social and technical dimensions of CSCW, Chapter 2
will discuss the approaches taken by a range of CSCW toolkits and systems, looking in particular
at their support for flexibility in application design and use. With a clearer view of the problems,
then. Chapter 3 will introduce the Open Implementations approach, and its analysis of these prob
Chapter 1; Introduction.
This approach leads us towards a solution to the problems of flexibility in CSCW systems. Most
importantly, it does this in a way which opens up some of the barriers between traditionally “high”
and “low” level concerns— the separation between the disciplines described earlier. Chapter 4 will
introduce the use of OI in a CSCW toolkit, Prospero, which attempts to address the problem of flex
ibility and separation. Dealing especially with the areas of (1) distributed data management and (2)
consistency and conflict control, Prospero uses 01 techniques to allow applications to become
involved in the mechanisms within the toolkit which support them. Application programmers can
“reach in” to the toolkit, tailoring and specialising toolkit structures to the particular needs of their
applications. Chapters 5 and 6 will discuss, in turn, these two principal areas of attention, and the
novel techniques which Prospero introduces to provide application programmers with toolkit con
trol; and finally. Chapter 7 will present some more extended examples to give a clearer overall
Chapter 2: Flexibility in CSCW Toolkits.
Chapter 2:
Flexibility in CSCW Toolkits
2.1 Introduction
The previous chapter emphasised the importance of flexibility in collaboration. CSCW applications
are characterised by a diversity of usage patterns, group working styles, interactional requirements
and technologies. At the same time, observational and sociological studies of collaborative work
highlight the variable, locally-organised nature of the sequential organisation of activity. Flexibility
in working styles implies flexibility in CSCW tools, and in turn, in the technological bases for their
development.
In this chapter, I will be concerned with issues of flexibility in existing CSCW toolkits. Flexible and
adaptable operation is at the heart of toolkit design, since it provides for reuse, I will begin by exam
ining this relationship between flexibility and reuse, from both the system design and HCI
perspectives, and then discuss various ways in which flexibility might be embodied in these sys
tems. Following this, in section 2 .4 ,1 will present a number of existing CSCW toolkits, discussing
their main features and facilities, with particular emphasis on their support for flexibility and on the
range of applications which they support. Taking these systems as examples, I will step back in sec
tion 2.5 to consider styles and elements of flexibility more generally. In particular, I will draw a
distinction between flexible operation through genericity and through extensibility’, and then, on the
basis of this analysis, I will highlight problems common to all the toolkits discussed.
2.2 Flexibility and Reuse
As in any other area of software design, early CSCW systems were constructed as monolithic enti
ties, specially crafted to needs of particular applications, user communities and software
Chapter 2: Flexibility in CSCW Toolkits.
fied, and as understandings of system requirements, application characteristics and usage patterns
increased, it became both possible and desirable to embody common design elements in toolkits ^
2.2.1 Software Issues
From a software perspective, one of the primary goals of toolkit design is reuse. When embodied
in a toolkit, components, algorithms and implementations can be recombined and reused in differ
ent applications. Much of the value of the toolkit resides in the range of applications it can be used
to create. The design of abstractions for the toolkit, then, focuses on the balance between two com
peting requirements. On the one hand, toolkit design strives to maximise the generality or
commonality of the toolkit’s component structures, so that they can be used in multiple applica
tions. On the other, it emphasises the flexibility in the ways they can be instantiated and
manipulated (so that a wide range of applications can be derived from these components). The flex
ibility which allows common components to be used in different ways and to different purposes has
to be balanced against other criteria such as interoperability, consistency and integration.
These issues, of course, are common to software concerns in the design of toolkits for any domain.
Patterson (1991) discusses some of the particular issues which CSCW systems raise in comparison
with single-user interactive systems, focussing in particular on a set of issues addressed in the Ren
dezvous toolkit, which will be examined shortly.
2.2.2 HCI Issues
Flexibility is an important issue in HCI research generally, and a number of researchers have stud
ied issues of customisation, tailorability and adaptation (see, for example Trigg et al., 1987;
Maclean et al., 1990; Mackay, 1989, 1990,1991; Nardi, 1993). HCI’s concern with flexibility has
been motivated by a desire to match the features and behaviour of interactive tools to the range of
working styles and tasks to which they might be applied. The focus of such research, however, has
largely been on flexibility within the context of particular applications or particular instances of
software systems. In these cases, variability operates across a population of users, employing an
application in different circumstances. While some of this work (e.g. Mackay, 1990; Nardi and
Miller, 1991) has emphasised the importance of tailoring as a group activity, this tailoring is still
largely performed in support of individual needs.
Chapter 2: Flexibility in CSCW Toolkits.
In CSCW applications, the problems of flexibility (or rather, of inflexibility) can become more
readily apparent—and that much greater—since the “user” of a CSCW system is a group of indi
viduals. As a result, variability can occur within a single group, as well as between different groups.
This has led to a number of attempts to incorporate intra-group flexibility, variable interface cou
pling patterns, etc. (e.g. Greenberg, 1991). As in traditional HCI, however, this type of investigation
takes a user focus, and concentrates largely on single applications or application areas.
2.3 A Framework for Flexibility
In their discussion of tailorability facilities in the Notecards hypertext system, Trigg et al. (1987)
set out four levels of flexibility:
1. a. flexible system provides generic objects and behaviours which can be combined and used dif
ferently by different users of the system;
2. a parameterised system provides objects with a range of alternative behaviours;
3. an integrable system can be connected to other system components;
4. a tailorable system allows users to change the system itself, add functionality or specialise
behaviours.
Drawing on the HCI perspective outlined above, this separation focuses on flexibility and adapt
ability in applications. The concerns in programmable toolkits differ, although we can fruitfully
make use of these distinctions.
Toolkits are designed to be used to create some range of applications. They are all flexible in Trigg
et al.’s terms. The concern which is addressed here is not their being flexible, but the extent o f their
flexibility—that is, the range of applications which they can be used to create. This captures not only
the range of application domains to which they can be applied, but also the range of interactional
styles which can be supported using toolkit components and mechanisms. So, for my purposes here,
flexibility is a relative term, rather than an absolute one. In support of this, the critical aspect which
will be addressed here is the fourth level of Trigg et al.’s analysis, tailorability, the extent to which
toolkit facilities themselves can be adapted and extended. (At the same time, I will also continue to
use the term “flexible” as a general one, rather than in the specific sense which Trigg et al.
introduce.)
In the analysis which will follow (section 2.5), I will discuss these issues in terms of two particular
Chapter 2: Flexibility in CSCW Toolkits.
behaviours, and the use of this property to support flexible action. Extensibility, the extent to which
they can be extended and revised to support new behaviours, and the similar way in which this is
used.
An orthogonal concern is the “locus of flexibility”—that is, the point within the system where flex
ibility is handled and exploited. I will distinguish between three points at which flexibility issues
come to the fore:
1. Programmer/toolkit—flexibility within the toolkit, offered to the programmer so that toolkit
structures can be used variably, adapted or augmented (for example, controlling floor control
criteria);
2. Programmer/application—flexibility exploited in the application under programmer control.
This might include, for instance, the use of adaptive algorithms to organise internal behaviours
around the patterns of use at a particular time (for example, dynamic data control which adapts
to network bandwidth and topology);
3. User/application—flexibility in the application under user control. This includes parametric
control over application behaviour (for example, control over levels of user interface coupling),
as well as the extension of applications with new user-supplied structures or behaviours.
There is a clear relationship between these three forms of flexibility. Flexibility at any one point is
helpful in providing further flexibility down-stream. Here, however, I am concerned with the first
level, flexibility within the toolkits themselves; the flexibility required to support a diverse range of
applications. My focus is on the mechanisms by which such flexibility is realised, how these are
specified and used, and with the ways in which they affect the properties (and the range) of appli
cations which can be developed.
Even a brief examination of existing CSCW applications reveals a host of systems and interface
issues addressed in different ways, which may each be the locus of particular flexibility concerns.
Apart from the obvious differences in application domains, these include the techniques by which
data is distributed and managed; mechanisms for joining and leaving collaborative sessions; mech
anisms for mediating between individual and group work; means by which individuals become
aware of the activity of others; levels of interface coupling; temporal aspects of interpersonal inter
action; and so forth. Toolkits, similarly, vary in the extent to which programmers can gain control
over these sorts of issues, and can potentially adapt toolkit mechanisms to the need of particular
applications. These are the ways in which flexibility is manifest in toolkits themselves, and in which
Chapter 2: Flexibility in CSCW Toolkits.
2.3.1 Collaboration Transparency and Collaboration Awareness
One approach to collaboration support, particularly represented in early systems, is organised
around the need for collaboration transparency—that is, the collaborative operation of existing
single-user applications, without any modification for explicit collaboration support (Lauwers et
al., 1990). A number of CSCW systems provide run-time environments which allow single-user
applications to be shared; examples include Rapport (Ahuja et al., 1990) and Shared X (Gust, 1988;
Garfinkel et al., 1989). Others, such as MMConf (Crowley et al., 1990) or ABC (Jeffay, 1992), sup
port collaboration transparency as one possible mode of operation.
Typically, such systems interrupt the event flow between application and interface at some point,
and insert a multiplexor. This replicates the application’s actions, making them available at a
number of points on a network, and can potentially accept user input from multiple streams and
channel it to the application. Since the underlying applications contain no native understanding of
the multiple streams which might now be used to interact with them, application sharing environ
ments might also introduce “floor control” mechanisms to manage input streams explicitly. These
regulate users’ access to the application input stream, using various policies to determine how
access to the application’s input stream is to be distributed between the various users.
In a wide range of situations, support for collaboration transparency is critical. Users typically
deploy a range of applications in support of a task, and so any of these might need to be made avail
able to a group (at least in some “display” mode, where one user remains in control). However, this
approach to application sharing has a number of drawbacks. The first is that the forms of collabo
rative activity which they can support are typically quite limited, since the interface is not designed
to reflect the activity of multiple users. Floor control mechanisms restrict access, or provide a con
trolled sharing model, to support the single-user approach of the application, at the cost of
restricting the group to one-at-a-time action. The second major drawback is that the centralisation
implied by collaboration transparency can impose a heavy performance burden. Typically, the col
laboration run-time mechanism is sharing access to a single application, running at one point on a
network; the cost of replicating display updates to all the participating hosts can be high, especially
over long distances or low-bandwidth connections.
In general, though, the collaboration-transparent approach is not of direct concern here; the require
ments imposed by collaboration transparency limit the options for incorporating variable or flexible
mechanisms within the infrastructure itself. Instead, I will focus primarily on systems supporting
Chapter 2: Flexibility in CSCW Toolkits.
In the next section, a number of existing CSCW toolkits are presented and briefly described and
compared. In the subsequent section, I will step back to consider the issues of flexibility more gen
erally, and consider the ways in which current strategies for incorporating toolkit flexibility are
problematic,
2.4 CSCW Toolkits and Approaches
This section presents six CSCW toolkits of various sorts—Rendezvous, GroupKit, MEAD, Suite,
Oval and COLA. The systems vary widely in both form and focus. After presenting aspects of the
structure and design of each toolkit, I will focus in particular on how they address flexibility issues.
2.4.1 Rendezvous
Rendezvous (Patterson et al., 1990; Hill et al., 1994) is a CSCW toolkit created at Bellcore. Ren
dezvous is primarily designed for building synchronous, graphical groupware applications. Written
in Conunon Lisp, and mnning over the X Window System, it has been used to create a number of
applications, from drawing tools such as the Conversation Board (Brink and Gomez, 1992) to dis
tributed user interface prototyping environments (Miller et al., 1992).
The mechanism at the heart of Rendezvous is the Abstraction-Link-View (ALV) structure (Hill,
1992). Abstractions capture shared aspects of application representations. Views present individual
users with interface representations and interaction mechanisms. Different users may see different
representations, or be presented with different interaction modalities to the same abstraction by
their different views. Systems of constraints (Links) relate Abstractions to Views. Links are respon
sible for transforming user interface actions in the Views into appropriate modifications to the
Abstraction, and similarly for ensuring that Views are appropriately updated when any changes are
introduced to the common Abstraction. Rendezvous uses this constraint-based mechanism to
manage all communication between Views and the Abstraction; all messages to the Abstraction
must be implemented in terms of constrained state-changes.
2.4.1.1 Flexibility in Rendezvous
Rendezvous is, very much, a programmatic toolkit. In other words, the flexibility which it embodies
is achieved through the ways in which its mechanisms are built into the base language (Common
Lisp) and can be manipulated and combined using the facilities that the programming language
offers. This approach works particularly well on top of Lisp as a base language—Lisp has been
Chapter 2: Flexibility in CSCW Toolkits.
focus, however, there are also some flexibility issues addressed by aspects of the system’s design
itself.
2 A . 1.1.1 Replication an d Centralisation
Rendezvous concentrates on support for real-time (synchronous), graphical, direct-manipulation
interfaces, using the constraint mechanism to provide dynamic feedback between an abstraction and
multiple views. This structure is reflected in most derived applications described in the research lit
erature (Brink and Gomez, 1992; Brink and Hill, 1993; Hill et al., 1994).
Although the ALV approach presents the abstraction as the central point of coordination. Rendez
vous’ model is not inherently restricted to centralised designs. For example, one could certainly
imagine using the same constraint system which relates Views to Abstractions as a means to syn
chronise multiple copies of an Abstraction. However, the current Rendezvous implementation uses
a centralised model; in fact, the Abstraction object and all View objects exist within a single address
space on one machine, using remote X displays to distribute interfaces. The designers comment that
they have found a single 64kbps channel sufficient for any of their existing implementations (Hill
et al., 1994), although they do not discuss issues of latency over long distances, which are surely
problematic. They do, however, discuss the desirability of a distributed implementation which
would separate the Views from the Abstraction.
2 .4 .1 .1 .2 Declarative E vent M odel
Rendezvous’ strongly object-oriented architecture supports a powerful programming model. In par
ticular, it allows interfaces to be constructed in a declarative style, in both their appearance and
behaviour. Graphic object classes handle the specifics of particular forms of graphical object; and
a powerful event model allows behaviours to be associated with objects declaratively, freeing the
programmer from the complex spaghetti of callbacks and event-handing code.
This declarative model lends itself to the encapsulation of interface behaviours not unlike Myers’
(1990) “interactor” approach. As will be discussed in more detail later, this encapsulation of behav
iour in an object-oriented structure is particularly interesting when looking at flexibility issues,
since it allows behavioural mechanisms to be specialised and modified independently of graphical
and other interface features. It allows application developers to think in terms of extending the tool
Chapter 2: Flexibility in CSCW Toolkits.
2.4.2 GroupKit
Group Kit (Roseman and Greenberg, 1992; Roseman and Greenberg, 1996) is a flexible toolkit for
building real-time collaborative applications. Like Rendezvous, it is a programmatic toolkit. The
first implementation was in the C++ UI toolkit Interviews, and was informed by both programmer-
level and user-level requirements from earlier experiments with monolithic groupware applica
tions, as well as the collaborative window system Share (Greenberg, 1991 ; Greenberg et al., 1992).
The current implementation is written in Tcl/Tk (Ousterhout, 1994).
Unlike Rendezvous, the run-time system is based on a replicated object model. Object replication
provides the responsiveness which the system needs to support synchronous graphical applications.
GroupKit has three major components. First, a run-time system manages distribution issues and pro
vides transparent support for sharing application objects. Second, an interface system (based on
transparent overlays) provides multi-user widgets and components for creating user interfaces with
collaborative properties (such as support for telepointers). Third, a programming model based on
open protocols accommodates differences for policy issues such as floor control.
2.4.2.1 Flexibility in GroupKit: Open Protocols
The use of open protocols (Roseman and Greenberg, 1993) is of most relevance to flexibility con
cerns. Open protocols are designed as a technological mechanism to support personalisable
groupware, through which different groups and different users can tailor the appearance and behav
iour of collaborative systems.
The open protocols approach begins with the understanding that system behaviour can be controlled
and configured through manipulation of state. From this, Roseman and Greenberg separate out the
three constituent components of an open protocol system—a controlled object, a controller, and a
protocol between them. The controlled object is an abstraction, residing in the (conceptual) server,
which makes the protocol available as a mechanism for accessing and changing state; the controller
resides in clients of the controlled object server (which are, potentially, also user interface clients
of the groupware system). The server imposes no policy on the sequential organisation of state
changes, and so clients can embody different policies for manipulation of the information. For
instance, floor control can be managed by establishing the “current floor holder” as shared state
information in a floor control server, which provides mechanisms for altering that state within the
protocol; and the floor control policy (round-robin, request/grant, etc.) can be implemented by cli
Chapter 2; Flexibility in CSCW Toolkits.
unaware of the mechanism being used, which may have been developed after the server itself was
written.
So in general, this mechanism can support not only inter-group differences, but also intra-group
policies. Clearly, however, there is a requirement for coordination between the controller objects,
so that they operate coherently together. Coordination mechanisms like these are defined outside
the open protocol approach. Open protocols simply make the tailoring facilities available; the pro
grammer is then responsible for ensuring that applications function coherently.
2.4.3 MEAD
A long-term project at the University of Lancaster focussed on cooperative interface development
in the domain of air traffic control, integrating ethnographic investigations with the system design
process (Hughes et al., 1993). MEAD (Bentley et al., 1992; Bentley, 1994) is a multi-user interface
prototyping environment developed in this project. The need for tailorability was driven by three
concerns:
1. the need for different views and interaction mechanisms over the shared data for the various
participants’ purposes;
2. the variety of working practices surrounding air traffic control technologies and artifacts;
3. the need to support collaborative development with users through real-time incremental adjust
ments to running prototypes.
The first two concerns were raised by the domain requirements, particularly as uncovered by the
ethnographic material; the third reflects a concern with iterative, collaborative prototyping.
2.4.3.1 Flexibility in MEAD: Taiiorabie User Display Agents
MEAD supports interface tailoring by introducing User Display Agents which sit between the cen
tral information space and individual user interfaces. The User Display Agent is responsible for the
management and representation of shared information in each user’s display. Each user might have
multiple User Display Agents acting collaboratively to manage information across disparate inter
face components. Communication between the central information store and the display agents is
handled via an event mechanism; display agents register interests in particular update events, and a
pattern-matching mechanism dynamically relates update events to display agents which should be
notified. Communication between display agents and the information store, then, takes place at a
high level, defined in terms of domain semantics; the specifics of interface representation are the
Chapter 2: Flexibility in CSCW Toolkits.
The primary flexibility concern in the User Display Agent model is supporting rapid prototyping
and interface construction. This is managed through the manipulation of three classes of User Dis
play properties— selection (objects to be displayed), presentation (forms of graphical
representation), and composition (combining the objects into a single display). These attributes are
available locally at each User Display site, so that they can be manipulated dynamically, providing
a mechanism for user tailorability (albeit, again, largely designed in support of rapid interface pro
totyping rather than user tailoring). Any changes to the User Display criteria are immediately
reflected in the appearance and behaviour of the display. One simplifying factor here is that User
Displays are largely independent of each other, operating as separate dynamic visualisations of a
shared space; and so, changing aspects of one display will have minimal impact on other Displays
(although a single Display might be included in more than one user’s “working set”).
2.4.4 Suite
Suite is multi-user application toolkit derived from an earlier, single-user application toolkit of the
same name (Dewan, 1990; Dewan and Choudhary, 1992). Suite focuses on editor-based interfaces
implemented over a shared data model.
Sharing and coordination in Suite is achieved through the linkage between shared active variables
and interaction variables. Essentially, this is the point where multi-user fan-out takes place. Shared
active variables represent the shared abstraction whose value is reflected in some aspect of the inter
face— shared because they are common to all users of an application, and active because, from the
point of view of any particular interface, their values may change asynchronously. For each shared
active variable, there are a number of interaction variables, which are the sites of local activity for
each interface. Interfaces (dialogue managers, in Suite terminology) operate on interaction vari
ables; the toolkit manages the relationship between the interaction variables and their
corresponding shared active variables according to a defined set of rules. Rules can be overridden
in particular applications to customise sharing behaviour.
2.4.4.1 Flexibility in Suite: Coupling Control
Suite provides a rich model for describing the degrees of interface and value coupling between
interfaces (Dewan and Choudhary, 1995). Interaction variables are organised into coupling sets,
each associated with a set of coupling attributes. Coupling attributes control different aspects of
interface coupling—whether the value is shared, whether forms of presentation are shared, whether
scrolling is shared, and so on. The values of coupling attributes determine the extent of the coupling.
Chapter 2; Flexibility in CSCW Toolkits.
made available to other parts of the system: immediately, incrementally, on commit, after some
time interval, etc.
Since attributes are associated with coupling sets, rather than the interface as a whole, different cou
pling modes can be present within the same system; similarly, different coupling modes may be
available between different users. Each user can set coupling attributes privately; a conservative
matching algorithm is used to determine the specific coupling parameters which will be used
between any two interaction variables. The fan-out between shared active variables and interaction
variables is the point at which Suite offers the programmer control over styles of interaction in col
laborative applications.
2.4.5 Oval
Oval (Objects, Views, Agents and Links) (Malone et al., 1995) is the latest in a long line of related
systems development by Tom Malone and colleagues at MIT. Beginning with Lens (subsequently
Information Lens), a rule-based email processing system, Malone and others developed a model of
“semi-structured” information processing, with a particular emphasis on end-user customisation
and tailoring (Malone et al., 1987; Mackay, 1989). Semi-structured objects and autonomous agents
then became the basis of Object Lens, a more general system for supporting collaborative applica
tions; and Object Lens has subsequently developed into Oval.
Oval provides four basic components for which it is named—Objects, Views, Agents and Links.
Objects are “semi-structured”; that is, an object definition provides an untyped, non-exclusive list
of fields which an object of that type will contain. Views are visualisations of objects and object
collections, allowing sets of objects to be clustered and presented in various ways depending on
their contents, for instance as tables or graphs. Agents are production rules associated with objects
which trigger when their conditions—typically, particular values of object fields—are met. Links
relate objects, allowing the creation of networks, hierarchies, etc.
What Oval provides is essentially a visual programming language, expressed in terms of these
objects and derivatives of them created by users. So, an application can be constructed by defining
a set of objects, creating agents to trigger behaviours on input or computation, and providing an
appropriate set of visualisations.
2.4.5.1 Flexibility in Ovai: Supporting Radicai Taiiorabiiity
A major goal of Oval is the provision of “radical tailorability”, a form of end-user programming.
Chapter 2: Flexibility in CSCW Toolkits.
tions, creating new systems out of old, and doing this without programming. By “radical”, they
mean that this tailorability can encompass wide changes; much wider than are traditionally associ
ated with tailoring or customising behaviour.
As an investigation of the scope which Oval provides for variability, it was used in the experimental
(re-)implementation of four pre-existing systems. The systems chosen were: The Coordinator, an
early workflow system based on a structured conversation model; gIBIS, a graphical hypertext
system supporting design argumentation; Lotus Notes, a collaborative database system for infor
mation sharing applications; and Information Lens, an email filtering system. The core Oval
components were used to re-implement the functionality of these systems, requiring only minimal
descent to the systems level, and so demonstrating the value of Oval’s “building block” design.
There are some important issues which should be borne in mind when evaluating this claim. While
the four systems vary in their domain detail, they’re based on the same model of collaboration—
asynchronous interaction over messaging systems. This is particularly interesting in the case of the
Oval implementation of Notes, since tme Notes employs a shared database model, which the Oval
implementation does not attempt to replicate. Instead, the Oval model captures the behaviour of an
application which might be implemented over Lotus Notes (Notes itself is an infrastructure for the
creation of collaborative applications). Similarly, the developers explicitly point to “a shared ‘live’
database” as one feature of gIBIS which they have not attempted to reproduce. At the same time,
given its intellectual history, it is not surprising to find that the functionality of Information Lens is
easily recaptured in Oval^.
So, while the reimplementation exercise impressively demonstrates that Oval subsumes the func
tionality of these disparate systems— and, even more critically, that it makes sufficient variability
available to the user that they can be implemented without recourse to system modification— we
must distinguish the variability of collaborative applications from the variability of patterns o f col
laboration. The facilities which Oval provides to users as the means to create and modify
applications are largely single-user in nature; sharing and collaboration remain largely outside its
immediate domain.
Chapter 2: Flexibility in CSCW Toolkits.
2.4.6 COLA
COLA (Cooperating Objects in Lightweight Activities) (Trevor et al,, 1995) is a platform for sup
porting cooperative work which is derived more from a distributed systems perspective than an HCI
perspective. That is, Trevor’s primary concern is to extend distributed system understandings and
techniques in light of experiences with distributed interfaces, rather than to extend the understand
ings and techniques of HCI with input from distributed systems. The principal component of the
resultant system is a lightweight activity model which provides a context within which objects—
perhaps those provided by a separate distributed object platform—can be shared.
The “lightweight” aspect of the system arises from the fact that the system carries with it only min
imal semantic implications for the development of applications. So, for instance, the activity model
does not introduce any requirements for the temporal ordering of tasks (as would a traditional work
flow system, for example). Similarly, issues of context are separated from the basic objects
themselves through the use of context-particular object adapters (Trevor et al., 1994).
2.4.6.1 Flexibility in COLA: The Poiicy/Mechanism Split
COLA is designed to mn in combination with a variety of distributed system infrastructures, as well
as in support of a range of applications. In fact, one of its principal motivations is also one of mine—
that traditional toolkit approaches embody semantics which restrict the application programmer’s
freedom. (The implications of this observation will be developed in more detail in Chapter 3.)
COLA’S approach, however, differs from that which will be subsequently developed here. COLA’s
approach is to make a rigorous distinction between mechanism and policy. This is a common
approach across a range of system designs. Mechanism refers to the support for particular actions
or system behaviours, while policy refers to the set of decisions about how and when these behav
iours will take effect. The X Toolkit, for example, claims to provide the mechanisms required to
build a scroll bar (objects which track the mouse, constrained action, etc.) but does not provide a
scroll bar because that would involve making policy decisions (such as which side of the window
it should be on, and which mouse keys should operate it). Similarly, in COLA, policy is seen as an
application issue— concerning how people are to work together—while the toolkit provides “pol
icy-free mechanisms” which can be employed in a range of ways in support of different applications
or application policies.
One aspect of this separation as an approach to toolkit design is that it is typically characterised by
a decomposition of toolkit components. As a result, the components which are offered by the toolkit
