Appears as Introductory Paper in
K. Schmidt (ed.) Report of COST14 "CoTech" Working Group 4 (1991-1992), pp. 9-36 Feb 1993 ISBN 87-550-1924-2
The Context of CSCW
Liam J. Bannon
Dept. of Computer Science & Information Systems
University of Limerick, Ireland
Email: bannonl@ul.ie
John A. Hughes
Dept. of Sociology and Centre for CSCW Research
Lancaster University
Email: J.Hughes@lancs.ac.uk
1. Introduction
CSCW is yet another attempt to define a research area concerning the design of machines which, at some point and to some degree, involve a human input. At its most general, design is about effecting a practical link between ideas and their instantiation in some artefact, procedure, or organisation that performs some intended function. In this respect, design is an ‘engineering activity’, though not always thought of as such, in which various elements - principles, procedures, human skills and competences, materials, machines, etc - are synthesized into some functioning whole. Although typically thought of as an activity mainly concerned with building artefacts, it is important to remember that it is also irreducibly concerned with the human users of such artefacts, even in cases where this fact is not made explicit. This focus on human use and users is particularly prominent in the concerns of CSCW.
In the early days of machine design attention was mainly devoted to getting the machine to perform at some level of functionality, with the human operator requires to act as another component, another ‘cog’ - often a dispensable one - in the human machine relationship (Bannon, 1991:7). The classic, and notorious, example of this was the Scientific Management School, following Taylorist principles, which began at the end of the nineteenth and the beginning of the twentieth century and which realised its apogee with the vehicle assembly line. In many respects, Scientific Management was a set of design principles which were as much to do with controlling the workforce by, for example, making production less dependent on workers’ skills and reducing tasks to their simplest components, as they were to do with improving the efficiency of production. Although discredited largely because of attacks from the Human Relations tradition, among others, it has survived as a practice in many industries (Trist et al, 1963).
The beginnings of ergonomics, also at the start of this century, was motivated by a more explicit need to improve the efficiency of human-machine systems and attention was given to fitting the machine to the skills, and the limitations, both physical and cognitive, of the human operator. Physiology, behavioural science, industrial engineering, medicine, and more, all made contributions to the broader understanding of human capabilities in working with machines. Today, such ‘design disciplines’ are well-established and have made major contributions to computing system design. As far as the latter is concerned, a more theoretical approach to design arose with the advent of HCI with its objective of trying to better understand the ‘cognitive coupling’ between the human and the computer (ibid., 8).
In the initial phase of computing, software development had much of the character of a ‘cottage industry’ (Buxton, 1978). To the extent to which programmers and system developers became part of corporate enterprises they tended to be managed much like academics or researchers by a kind of "responsible autonomy" strategy which may be identified as ‘management by neglect’ (Friedman, 1992). High priced, low capacity and low reliability hardware dominated, and what management’s required were systems which were fast and efficient. Programmers developed their own tricks and techniques for taking short cuts to improve performance. Creativity was encouraged and, for many, it was programming’s ‘golden age’. The approach was to take a small group of highly qualified people who wrote largely undocumented code and who maintained the system once built (Bergland, 1981). At the time this arrangement worked reasonably well but as the hardware constraints fell away and the cost/performance ratio of CPUs and memory increased, it became less and less appropriate.
Around the late 1960s and early 1970s the key issue was the software productivity gap (Brooks, 1975). The automation of software production failed as a realistic option as more complex and large-scale system development came on stream. The best known strategy was to attempt to increase productivity by "creating finer divisions of labour by separating analysis from programming and dividing programmers and programs further so that most ended up concentrating on coding small modules using structured programming methods" (Friedman, 1992). The point is that the production of software had to face a situation where it was no longer satisfactory to rely upon the local guru - the one person who really knew what was going on - but had to be provided by an explicit organisational structure and process where there was little or none required before. It is this trend which stimulated the rise of requirements engineering and development methods to organise and manage the systems development process.
From the point of view of users, the most significant shift was the extension of computer use to people for whom ease of use was a paramount consideration. With this came the rapid development of HCI which directed attention, as noted earlier, toward developing knowledge of putative users in order to produce computer designs which could be more effectively used by those without specialist computer knowledge. More recently, and to use Grudin’s (1990) way of expressing it, the interface has begun to move further and further away from the individual user into the domain of work and organisation which has meant that traditional HCI approaches to informing system design are proving less and less adequate; hence the turn toward CSCW.
2. Plan of the report
This Section of the Report is designed to provide an overview of the CSCW field, briefly recounting its origins and development, thus setting the scene for the rest of the report, where particular issues within the area of CSCW are subjected to more extensive investigation and analysis. The Section is organised as follows. Part 3 gives a brief historical account of the development of the field. Part 4 then provides further detail on the numerous attempts to delineate the core concerns of this new field. Developments in several areas that have provided a suitable context for work in CSCW are mentioned in Part 5. Next, some CSCW systems and the experiences gleaned from use of such systems are discussed. Finally, in Part 7 we outline some of the key issues in CSCW design from our perspective.
3. CSCW: A short history
The term CSCW was coined by the computer scientists Irene Greif of MIT (now at Lotus) and Paul Cashman of Digital in the early eighties. They organised a workshop concerning the development of computer systems that would support people in their work activities. It was in trying to describe what the focus of the workshop was that Cashman and Greif came up with the term Computer-Supported Cooperative Work to describe their object of interest. The birth of the "movement" can thus be dated to this small Invited Workshop (34 people) at Endicott House, Massachusetts, in August, 1984. It brought together a number of people from somewhat disparate areas, e.g., office information systems, hypertext, and computer-mediated communication to name a few. In terms of names, it included people like Doug Engelbart, who had in the 1960’s pioneered interactive computing and team support in his NLS/AUGMENT system, Clarence "Skip" Ellis, then at Xerox PARC, well-known in the office automation area, Tom Malone, at MIT, who was developing his ideas on organisational interfaces, Randy Trigg, author of one of the first Ph.D. theses on hypertext (TEXTNET), Carl Hewitt, working on conceptions of office information systems as open systems, Murray Turoff, developer of the New Jersey Institute of Technology’s EIES computer conferencing system, and others. Although most of these individuals were already well known within specific research areas, they had not been brought together before to discuss common concerns of developing software to support distributed ensembles of people in their work.
The first open conference with the title Computer-Supported Cooperative Work was organised in December 1986 in Austin, Texas. It brought together around 300 people from a variety of backgrounds, artificial intelligence, human-computer interaction, office information systems, computer science, psychologists and anthropologists, and was by all accounts a great success. Participants heard about 30 papers on such diverse topics as: experiences in introducing computer conferencing systems; experiences with computerised meeting rooms; design and use of electronic mail filtering tools; design and use of shared calendar systems; problems of collaborative hypertext and many other topics. Interest in the field has continued to grow, with an even larger conference held in 1988 in Portland, Oregon. There were about 485 participants, mainly from US industry. The first European conference on CSCW was held soon afterwards in September 1989 in Gatwick, England. (A selection of the papers presented appears in J. Bowers and S. Benford (Eds.), 1991). Although the conference did serve a purpose in bringing together people of different backgrounds, the quite different "world views" of the participants was apparent, with a separation between those groups focused on modelling and design of office communication systems and those interested in developing a richer understanding of cooperative work practices. Not only were the goals different, but the language and methods used were also quite distinct, leaving some neophytes quite confused as to the "core issues" of the CSCW field.
Despite these worries, overall interest in the area continued to grow sharply. The 3rd North American CSCW Conference was held in 1990 in Los Angeles, attracting around 560 delegates, with over 40 from Japan, a massive increase on the previous Portland Conference. The Second European CSCW Conference was held in Amsterdam in Sept. 1991, with a full attendance of 200 people, and was received positively. Some rapprochement between the technical and social perspectives could be discerned in a number of the papers. The last North American conference was in November, 1992 in Toronto, and in 1993 the European CSCW Conference will be held in Milano, Italy.
Besides the major CSCW conferences mentioned here, there have been a number of CSCW-related conferences and workshops on collaboration technology, group decision support systems and multi-user systems both in Europe and North America in recent years. Several journals in the HCI, OIS and GDSS areas now include CSCW in their list of topics, and a new journal published by Kluwer is solely devoted to the topic -- CSCW - Computer Supported Cooperative Work. Another journal, Collaborative Computing, is also about to appear. Thus, CSCW certainly has become a recognised area of interest, with a growing number of interested researchers and the support of many software manufacturers and developers, despite continuing concerns about how to circumscribe the new field, which we take up in the next Part of this report.
4. Setting the scene - Characterising CSCW
Interest in the area of workgroup computing, collaborative computing, groupware, cooperative work support, and similar sounding terms has thus increased significantly over the last several years. Despite this evident interest in the new field, understanding what CSCW is all about turns out to be a somewhat difficult task. There is still no commonly accepted definition of CSCW (Wilson, 1991). Indeed, whether CSCW can be viewed as a new field of research in its own right has been questioned by some. Bannon et al. (1988) noted how CSCW might be viewed as simply an "umbrella term" that allowed people from a variety of different disciplines, with partially overlapping concerns, to come together and discuss issues, without any common ground as to the concept of CSCW, other than the very loose idea that it was somehow about the use of computers to support activities of people working together. In a somewhat similar vein, Rob Kling has spoken of CSCW as an "arena" where different groups vie for the attention of participants, rather than a coherent focused field. Arguing against the claim that CSCW is a new field, Hughes et al. (1991) view CSCW rather as a paradigm shift in the way we think of designing computer support systems. This position has similarities to the views of Suchman (1989), who describes CSCW as "…the design of computer-based technologies with explicit concern for the socially organised practices of their intended users."
Another conception of what the field is about can be discerned among those who focus on the computer support of "groups" as the hallmark of the field. This has given rise to the term "groupware" to distinguish the computer products marketed in this area. Irene Greif, one of the originators of the term CSCW, has provided a more restrictive description of the new field, defining it as "an identifiable research field focused on the role of the computer in group work" (Greif, 1988). This focus on the support of groups per se has been critiqued by others. Greenberg (1991) attempts to evade definitional problems by using both terms in the title of a recent edited collection in the area, stating that groupware describes the development of software for groups, and CSCW is the research area concerned with the nature of work practices etc., on which groupware builds.
Bannon & Schmidt (1989) define CSCW as "an endeavour to understand the nature and characteristics of cooperative work with the objective of designing adequate computer-based technologies". Here the emphasis is on understanding cooperative work as a distinctive form of work, and on supporting these cooperative work forms with appropriate technology. This broadens the scope of the field considerably beyond that of computer support for groups. The rationale for this approach, and case studies, is presented by Schmidt in Section NN of this report. This definition is echoed in that of Lyytinen (cited in Robinson,1990), who argues: "CSCW is neither solely a tool or technology business, not just a new way to study computer impact on the work place. Instead, in CSCW, equal emphasis is put on the distinctive qualities of co-operative work processes, and on questions of design: how to mould computer technology to fit into and support these work processes."
While cognisant of the arguments made by those who view CSCW as "merely" a paradigm shift, the position taken in this paper is that CSCW can be seen as a new research field involved in exploring a wide range of issues concerning cooperative work arrangements and its support via information technology. A focus on cooperative work arrangements and their computer support is what makes the area "new". While earlier work in the "office automation" field has at times concerned itself with such issues, the new field should not be seen as simply an extension to office information systems (OIS), as CSCW entails both a wider remit as regards the different settings in which it is appropriate to study cooperative work arrangements, as well as a more explicit focus on the support requirements of cooperative work than is seen in the OIS field. Thus studies in areas such as computer-aided design (CAD), computer-integrated manufacturing (CIM), computer-aided software engineering (CASE), etc., are all relevant to the CSCW field to the extent that they study the use of computers to support cooperative work in different domains (See e.g., Schmidt, Section 2). Such a view of the field opens it up to a wider mix of disciplines than simply computing and software engineers, encompassing cognitive and social psychologists, work sociologists and anthropologists, and many others.
Understanding what CSCW is about through examining the composition of the community is another illuminating approach. Within the field of CSCW, loosely construed, a number of different groupings have been discerned by commentators. Howard (1988) coined the term "strict constructionists" to describe those in the field focused on the development of computer systems to support group work, who tend to use themselves as objects of analysis in the provision of support tools. These people, mainly implementers, are interested in building tools - widgets, and they see the area of CSCW as a possible leverage point for creating novel applications. Most of these people equate the CSCW field with Groupware, as they focus on new software applications. Howard (1988) has labelled those who make up the remainder of the CSCW field, the larger part, as "loose constructionists," a heterogeneous collection of people, some of whom are drawn to the area by their dissatisfaction with current uses of technology to support work processes, others because they see in this area a chance for communities who traditionally have not had a voice in the design of computer systems to have one. Some wish to make the design of computing systems more democratic, so that the resulting systems will actually support cooperative form of working, rather than hinder it - where the word ‘cooperative’ has a positive value associated with it, connected with workplace democracy. Part of the rationale here is that for work to be truly ‘cooperative,’ in their sense, one should design systems in a cooperative manner, and ways of achieving this therefore need to be investigated, and developed. The focus is on alternatives to traditional systems and systems design, alternative ways of doing design, of involving users, etc.(see, e.g., Greenbaum & Kyng, 1991).
It is the involvement of what has come to be called the Scandinavian school of systems developers in CSCW - for example, in the 1988 CSCW Conference - that has lead some people to equate the CSCW area with participative design (PD) practices. While certainly various forms of user involvement are important to the development of successful CSCW systems, use of such techniques or ideas does not automatically signify any focus on CSCW as defined here. Certainly, the software development process itself can be seen as a form of cooperative work which is supported by computers, and thus is an interesting domain for CSCW studies, but labelling papers on participatory design techniques in general as CSCW studies does not add insight to either field of endeavour. Indeed, many participative design practices e.g., Future Workshops, Wall Charting, etc., are noticeable by the complete absence of computers in supporting the ongoing work of the group. The issues of CSCW and Participative Design are thus seen as quite separable, if not orthogonal.
That the nature of the CSCW field has been, and continues to be, the subject of debate as we have shown here is not necessarily problematic. In any area of science, the definition of the field - its core concerns and its boundaries - is best viewed as "contested terrain", even more so as the field struggles to find a unique identity, so it can set itself apart from its progenitors. The simple fact that there is dispute is symptomatic of a healthy debate about the underlying issues of computer support, the nature of work, the role of groups in organisations, etc., which should be clarified over time. We now examine some of the explanations offered as to why the emerging field of CSCW has attracted such a variety of disciplinary groups and commercial interests.
5. The attraction of CSCW
Explanations abound as to why the field has come into focus at this stage in the development of information systems. These accounts come from a variety of different organisational and disciplinary perspectives. Examining these accounts in and of themselves provides us with an interesting insight into some of the different perspectives and players in the CSCW field. The following just touches on a few of these viewpoints and arguments.
In a recent paper, Grudin (1991) argues that the CSCW area can be seen as an arena where two different development traditions, that of Information Systems (IS) and Human-Computer Interaction (HCI) converge. He sees the CSCW focus on groups as intermediate between the traditional focus of HCI on individuals and of IS on the whole organisation. Similarly, he views the development process for Groupware as requiring a melding of the dominant forms of development work in the other two fields - the contract tradition of IS and the product development tradition of the HCI field.
There are a number of changes occurring, e.g. in the field of information systems practice, in the environment of organisations, in technology itself, and in people’s expectations concerning computer systems, which have, arguably, contributed to the emergence of, and interest in, CSCW. While this list is not exhaustive, it does identify some of the main shifts which have informed the rise of CSCW.
Information Systems Practice
The earlier IS goal of "automating the office" has been discarded on both practical and theoretical grounds. Information-flow diagrams of office activities do not, in any literal sense, specify how work actually is accomplished - handling "routine" discrepancies, bending the "fixed" rules, contextualizing aspects of the work, etc. This does not mean that they are without any merit, but it does mean that they cannot be assumed to "capture" office work, and serve as an adequate base for automating office activities. The idea of an office being a place where people perform a set of well-structured tasks according to prescribed procedures has given way to a view of the office as a social community where work is accomplished through the locally situated activities and interactions of office members. Ethnographic studies of office environments have carefully documented aspects of this rich interactive world, constructed by the participants (Gerson and Star, 1986, Suchman, 1983, Wynn, 1979).
Recently, IS researchers have accepted the need to understand more fully the practices of people at work, in order to build more appropriate supportive technology. The shift in emphasis can be seen in the change in terminology from "automating" the office to "supporting" office workers with "office information systems" where computer systems are seen as support systems for the human workers, rather than as replacements for them (see, for example, Fikes and Henderson, 1981, Woo and Lochovsky, 1986, Hewitt, 1986). CSCW, through its emphasis on the support aspects of the technology, and with its interdisciplinary community, including ethnographers and others who focus on work practices, has attracted interest from many researchers in IS who see the need for further understanding of workplace practices as a key aspect of improving the quality of IS designs.
The Search for New Software Application Markets
CSCW has attracted interest from commercial software developers as it is seen as a possible growth area for new software applications - groupware, in terms of supporting group activities rather than individual activities. While some early groupware products e.g. shared calendaring systems ( see below) have enjoyed mixed success, developers are still optimistic. Interestingly, it has been noted by Greif among others, that in the long run, the differentiation of a segment of the software product market in terms of "groupware" may not make much sense, as all software will be groupware, i.e. to the extent that any particular software application will have the required features to support group use when appropriate. For the moment however, there is a massive increase in the marketing hype for software specifically focused on group support.
The Organisational Environment
The increasingly turbulent environment in which business operates has lead to the need for better ways of organising and co-ordinating work activities, with more ad hoc task groups and the need for flexible communication structures, in the search for increasing responsiveness, competitiveness, etc. In the area of production systems we see an emphasis on computer-integrated manufacturing (CIM) and just-in-time(JiT) methods, and various other techniques to reduce stock inventory. Computers are being connected both intra and inter- organisationally to assist in this co-ordination process. Many organisation strategists believe that successful corporations of the future will be those that manage to make the "networked" organisation a reality, and see CSCW activities as addressing aspects of this crucial issue, in emphasising collaboration and co-ordination activities and their support via flexible information systems.
Technology
Tied in with market forces requiring greater co-ordination and general "connectivity" of computer systems there have been significant developments within the technological arena allowing for infrastructural computer networking. The idea of the isolated PC in the office is becoming an image of the past, with the advent of various forms of local area networking (LAN) that allow for shared resources. Networks support greater connectivity between people, locally and with more wide-area networks (WANs), globally. Other technical developments in the areas of inter-operability, security, transparency, and distributed systems will support the needs of organisations for greater responsiveness and flexibility. Again, a number of these problems are being tackled in innovative ways within the CSCW arena, through the linking of work requirements with technological development in specific areas.
People’s Expectations
There is an increasing demand from computer users themselves for more flexible and tailorable user interfaces and additional functionality that would allow people to accomplish their work more efficiently and effectively. While the HCI area has contributed to the design of better interfaces to computer systems, problems remain, particularly concerning incompatibilities between systems, and the inability of many applications to support multiple users effectively. Given that more and more work is being mediated by computer systems, the gaps and inabilities of these systems to support people in their working practices, e.g., where workers in a team need to share and jointly manipulate information, becomes a source of frustration. Again, this has resulted in pressure being put on software and hardware houses to support greater inter-connection between PCs and available applications that would allow for sharing of applications, multi-user access to facilities, and greater integration of applications at the use level. There is a need for augmenting possibilities for interaction by using the computer to help co-ordinate activities and support joint problem-solving, for example by providing shared workspaces where people can dynamically create objects and modify them, and shared tools for annotating and writing documents. These concerns are explicitly addressed in the CSCW community, thus making user representatives very interested in the area, as it may provide more useful and usable tools for the workforce.
At another level, people are becoming more knowledgeable about technology and wish to have a say in how their work practices are going to be changed by new technology. They wish to proactively affect the design, and take part in prototype evaluations. In a complementary development, a number of system developers also wish to support this process of user involvement and are searching for ways in which to support it. They see CSCW as a possible avenue for greater co-operation with workers in the design of future systems (Bødker et al., 1988), through the development of better computer-based tools in this cooperative design and work process. While issues of user involvement and cooperative design should not be seen as the cornerstone of CSCW, as noted earlier, it is the case that many practitioners of these techniques are visible in the CSCW community, which has lead to an increased interest in the area from a number of sectors anxious to improve design methods and results - representing both developers and users.
The requirement of ecological validity in HCI
The relevance of much laboratory HCI work to actual work practice has been questioned (Thomas & Kellogg, 1988). CSCW has attracted interest from a number of academic research groups who are concerned with the use of more qualitative methods and field study techniques in order to make HCI work more ecologically valid. Given the focus in CSCW on the requirements of the work, and thus the need to study the work domain closely, field studies become of central importance. This shift in emphasis has also allowed for the participation of groups heretofore more on the fringe of HCI, for example, sociologists and anthropologists, who have been able to find a supportive atmosphere for their empirical studies of work settings in CSCW (see Bannon, 1992).
This brief outline of issues is simply indicative of some of the contributory factors that have exerted pressure for change in the design, development and use process concerning information systems in organisations. The argument is not that any such set of factors "caused" CSCW to emerge, but rather, that concerns such as these ( and a host of others besides) made people open to new ways of discussing and conceptualising issues concerning the design and use of information systems in organisations. Once the area was named and a number of people with interdisciplinary interests wrote papers and became "members" , the area was launched. Subsequently, the debate about exactly what is "new" about the field could get underway (as we saw above). For of course, in some sense, CSCW is not "new". Computers have always supported, or perhaps disrupted, collaborative work activities, from the earliest days of mainframe computer system applications, but one could argue that the above changes have heightened the awareness of system developers to the need to support the increasing variety of cooperative work arrangements that can be found in modern organisations. Taken loosely, this simply means that it is being recognised that in most work situations the accomplishment of work involves multiple individuals, together with their computer-based tools, and that many inefficiencies in work practice stem from inadequate computer-based support for the smooth interleaving and co-ordination of tasks across people and machines.
Thus far the paper has been concerned with giving some background to the emergence of the CSCW field. In the following section, we turn to briefly discuss some CSCW applications and evaluations.
6. Early experiences with CSCW systems
One can make a rough distinction between those systems developed in research environments - primarily as learning tools, from those systems that were conceived and developed as commercial groupware products, although some systems do cross this divide. The useful collection of papers in Greif (1988) includes several CSCW systems. These systems are primarily developed within the research domain. From the research side we mention briefly here DEC’s XCP, a very early prototype work management co-ordination system, the MIT Information Lens Project, an electronic mail filtering mechanism (which has since spawned several commercial applications), and the Xerox PARC CoLab Project, a computerised meeting room environment. We also discuss, on a generic level, shared calendaring and general-purpose electronic mail systems, as they raise interesting issues regarding CSCW. On the commercial side, we briefly describe The Coordinator, and ForComment. New research systems and commercial products are being announced continually (e.g. Timbuktu, Aspects, BeyondMail,..), but our purpose here is simply to give some examples of systems which have been developed and which have had some form, however minimal, of evaluation. The aim is to learn some lessons from the successes and failures of aspects of these systems, for future use.
Electronic Mail
To some people, electronic mail is seen as the clearest example of a groupware application that has made a significant impact in the work place. Having the ability to send messages electronically to people connected either via a local area network or a widearea network around the world has undoubtedly given new opportunities for forms of remote collaboration undreamed of in the past. Even within a particular department, where people can communicate face-to-face, electronic mail can offer additional possibilities for communication and collaboration (see Bannon, 1986 for some discussion). Some argue that e-mail is actually the only CSCW application that has been accepted and clearly been a success in the marketplace (see discussion in Grudin, 1991).
I will not go through the large literature about the use of email, since we should note that effects of technology are always mediated by a social process, so it is difficult to discuss more generic "effects" of any technology, without an understanding of the particular context of use (Orlikowski, forthcoming). However, given its rapid dissemination and use in business settings, there is no doubt that it has been accepted within the business community. The potential of the technology for creating informal and possibly anarchistic groupings of people in organisations has been noted, and occasionally documented, but overall there seems to be an acceptance of the medium across the board, as any disadvantages are currently perceived as being outweighed by the advantages. Bullen & Bennett (1990) in their large interview study of a variety of groupware tools in organisations, found that the basic electronic messaging capability available on all these systems was seen as far and away the most valuable feature. Indeed , they go further and note; "..given the choices existing in information technology tools today, the people we studied used what we are calling "message functions" almost exclusively" (Bullen & Bennett, 1990).
The MIT Information Lens Project
The Information Lens system (Malone et al., 1987) has been the subject of a number of research reports and the ideas behind it have now been incorporated into several commercial products. The system is designed to support people in managing their electronic mail. It has at times been referred to as an "intelligent" information sharing system. The filtering available in Information Lens is designed to screen users from "junk" mail and "filter in" other messages of interest, even if not directly addressed to specific users, thus extending the information sources available to individuals. It provides capabilities for organising mail based on various aspects of the incoming message. It allows users to make message templates of various forms and have rules (of an IF-THEN-ELSE variety) that act selectively on these "semi-structured" messages. If the sender has selected a colloquium form for the mail message, and a message form of type: colloquium has been defined by the group, then the sender can be provided with support for composing the message through a partially filled ("semi-structured") message template, and the receivers can make rules that utilise the information that a message is a colloquium announcement to file it appropriately. One can see how this could be quite useful to help put some structure on the myriad of different forms of email communication which at present are insufficiently disambiguated. It helps the sender to structure messages appropriately, and can serve a reminder function for what information is necessary for certain announcements (e.g. to remember to specify the location of a meeting) as well as helping the receiver to sort incoming mail appropriately, rather than, as at present, have all kinds of messages mixed together in the incoming mail file.
The other concept discussed in the Information Lens work is that of the "anyone server" where users can send out a message to an undefined body of users, the subset of users being those who have defined rules that match the properties of the message sent out. The idea is that this would allow people to encounter others with similar interests within an organisation, say, without necessarily knowing the other person directly. This facility has not been implemented in some versions of the system.
In an empirical investigation of the use of the Information Lens system, Mackay et al (1989) summarised their findings as follows: People without significant computer experience can create and use rules; Useful rules can be created based on the fields present in all messages without special message templates; People use rules both to prioritise messages before reading them and to sort messages into folders after reading; and people use delete rules primarily to filter out messages from low-priority distribution lists and not to delete personal messages to themselves. Mackay (1990) also shows the wide variability in patterns of use of the system, though overall there seems little doubt that prototype systems (after some iteration) are being used effectively in work situations.
Undoubtedly some of the ideas embodied (over time, evolving through use) in Information Lens have proved useful in practice. So it seems that people can makeup rules that are useful, but it this does not imply that they can be encapsulated into an "agent" and allowed to be triggered automatically. For instance, one key point noted by Mackay (1990) was how people tended to make up rule sets but then run them manually, i.e. the people themselves determined when to run the rule set, in particular occasions of use, rather than have it done automatically, according to some pre-specified formula. This supports the notion that it is very difficult for people ahead of time to specify clearly the conditions under which certain rules should be run. Luckily, the technology allowed for the user to manually "trigger" the rule sets, although this was not part of the initial idea of how the system would be used. The extent to which the results of the case study support the wider visions of some of the supporters of Information Lens is thus still open to debate.
More recent work at MIT extended some of these ideas well beyond simply message handling - the Object Lens system ( Lai, Malone & Yu, 1988) - and this has evolved into a what they term a radically tailorable system for developing a large set of cooperative work applications - OVAL (Objects, Views, Agents, and Links). Evaluations of this system are just beginning (Malone, Lai and Fry, 1992).
The Coordinator System
This commercially available system is one of the most talked about CSCW applications due to its articulation of a well-developed theory of "language as action" that has exerted considerable influence in the research community (Winograd, 1986). It also has strong advocates in the commercial world who find that use of the system has increased their productivity enormously. The actual system can be simply described as a fancy electronic-mail-cum-project-management system. The system is built on the belief that human action is based on conversations, primarily conversations of a particular form, for action. Thus people using the system do not simply send mail, but make requests, or promises, or offer or decline to perform certain activities. (The system does allow for "free-form" responses, but this choice indicates abdication of the underlying framework on which it is built). Within this framework, the system then keeps track of the commitments made by individuals. Bullen & Bennett (1990) note how the ability to link messages in some electronic messaging systems (e.g. in Higgins, The Coordinator, All-in-One..) was found in practice to be a very useful facility. Through its concept of a "conversation", The Coordinator supports this linking quite explicitly.
At the same time, there is quite bitter dispute between different groups as to its explicit design goal, which is to change the way people in organisations think and act. Whether speech act theory is an adequate theoretical framework on which to erect a computer-mediated communication system is open to question (Bowers and Churcher, 1988) but, as Robinson, (1990), notes, the main complaint against the system in use has been that it seems to exclude negotiation. Great care is required in the construction of group tools in order to ensure that the system does not embody untenable assumptions about the nature of group communication and group activity. The conflicting case study reports of its use (Johnson et al, 1986, Bikson et al., 1988, Grantham and Carasik, 1988, Bullen & Bennett, 1990) can be reconciled, at least partially, if one notes that it seems to work well in organisations with a rather rigid, traditional hierarchical management style, and be unacceptable in more fluid, loosely coupled organisations. But there is a lot more at issue here. What is required now, however, is closer analysis of actual uses of the system, as the extant case studies are limited in a number of ways, which makes it difficult to interpret their findings unambiguously.
Shared Calendaring & Meeting Scheduling Systems
There are a number of research-oriented and product-oriented CSCW systems that incorporate an electronic calendar system which can be utilised by meeting scheduling software to provide an automatic meeting scheduling capability. At present meeting scheduling is a difficult and very time-consuming process, and the rationale was that software to handle it automatically could make significant improvements in office productivity.
While the idea appears very simple, the practice has shown otherwise, as noted in the case study work of Ehrlich, 1987, and in Bullen & Bennett, 1990, and discussed extensively in Grudin, 1989. To summarise his arguments, for one thing, electronic diaries cannot replace paper diaries, as they are not portable, nor do they give the same flexibility and utility possible through use of post-it notes, signs from different coloured pens, clippings, etc., often found in physical diaries. Another problem is that basically all of the people on the system must commit to using the system, i.e. to updating their diaries, before the system can really be used. If only half the group do it, nobody can rely on the system. Yet it is not at all clear what the benefits are to some members in keeping their electronic diaries updated, as the main benefits accrue to senior managers who call meetings (and/or their secretaries). The trade-off between the work required and the benefits accrued are not equitable. Even if every one commits to do this, there are still problems about giving up control of one’s "free" time. As Grudin cogently argues, free time is not really free. Managers may be willing to have their time scheduled for a meeting with their superior automatically, but not the reverse. It all depends on what the situation is, if somebody is willing to schedule a meeting with certain people. Just as we saw with the Information Lens, people wish to have control of the situation, and thus will often wish to change priorities depending on the situation and their personal context. What would appear to be a relatively trivial affair, meeting scheduling, in practice can involve quite complex, and rapidly changing decision rules that cannot be clearly defined in advance of the actual situation. Ehrlich notes that in cases where electronic calendars are used heavily, the role of secretaries in screening meetings is often crucial to making the system work, so that the meeting scheduling involves negotiation between people and is not automatic. These experiences should make us aware, if we are not already, of how apparent technological fixes to what are primarily social and organisational problems can come unstuck.
Lotus Notes
This commercial product has generated an enormous amount of interest since it was first announced (Marshak, 1990). While difficult to describe succinctly, it can be seen as providing a platform for developing a number of applications to support communication and information sharing in an organisation. One interesting feature of this system is how it was targeted initially at senior information systems managers in companies, with a view to having them install Notes on a wide scale within their organisation. Licences were bundled so that a minimum of over 250 licences had to be bought at once. While this marketing decision has now been rescinded, it does point to the attempt by Lotus to garner upper-level management support for their product, as well as the need for some infrastructural investment company-wide in support services for the product. A number of companies have taken the strategic decision to purchase such systems corporate-wide, and even globally. Whether such a technology push will lead to successful adoption of such systems is open to question.
Studies are just beginning to document what happens in specific settings when this technology is introduced (Orlikowski, 1992). Her research has pointed out a number of problems in the implementation strategy adopted by this particular firm, which was a "brute force approach", with little education of users about the utility of Notes for their daily work. She also notes the discrepancy between the organisational culture evident in the firm - a competitive, individualistic environment, and the purported intent of Notes to foster "sharing" of information among people in the organisation. Rather than revolutionising the work environment Orlikowski describes how the system was being used to build applications supporting individual, not group productivity, and mechanising existing work flows, rather than developing new work arrangements. It should be noted here that this field study took place during the initial 6 months of implementation of the Notes system in the organisation, so it is possible that over time changes will take place, and new work practices will evolve.
What the account does tell us, however, is that we need to be careful in assuming that simply installing the technology will produce far-reaching changes in the organisation. We also need to be aware that, because Notes is such a general purpose environment, it will be difficult to discuss general aspects concerning the success or failure of Notes, as much will depend on the quality of the local programming applications built on top of the Notes substrate.
Ventana Group Systems
This commercial product is a spin-off from the work of Jay Nunamaker and colleagues of the University of Arizona. IBM’s TeamFocus product is a related spin-off. The system consists of a number of different tools that are intended to assist in aspects of the group decision-making process. There is support for brainstorming activity, for ranking alternative choices and voting on them, for preserving anonymity, etc. Focus has been on the support of co-located real-time teams, but the technology can be adapted for use in remote situations or for non-real-time use. Versions of the system have been the subject of a large number of articles (see Nunamaker, Dennis, Valacich, Vogel, & George, 1991).
There have been numerous studies conducted on the system, both in lab and, more recently, field settings. There have been reports of massive increases in productivity based on much shorter lead times for getting decisions made in large groups through use of the system. It can be difficult to assess the validity of these claims, as often the comparison is made between "time taken to reach a decision with the system" versus "people’s estimate of how long it would take to take the decision without the specific technology". Such figures are difficult to verify. More generally, there is the question of what kinds of meeting are such systems appropriate for? In situations where the group agrees on the general framework of important factors in the decision-making process, then the system may speed up the process, but in situations where the major topic of the meeting is arguing about the very grounds for making the decision, it does not seem that the rather simple model of decision-making embodied in the system would be appropriate. As the commercialisation of the product continues, it will be of interest to observe further evaluations of the system in different contexts of use.
DOMINO Office Procedure System
This prototype procedure system is interesting as it has been extensively described in the literature and more recently evaluated informally by some of the design team (Kreifelts, T. et al., 1991). The system makes a number of assumptions about the nature of office work, and provides "support" for a number of work activities. A working prototype has been developed and in use in a research organisation, where initial studies of its use have been performed. The initial system model had been the subject of some criticism concerning its view on work activities, but what is interesting is to see what actually happens when in use. The small internal study of Kreifelts and colleagues shows that, indeed, the system was seen as problematic on the grounds of not allowing for sufficient flexibility, for example allowing necessary informal communication, for lack of integration with other tools - for example electronic mail and spreadsheets, etc. The point is not that such systems have no future, but that we must take seriously the findings that people do not simply "follow procedures" in an office, and thus office support must be very tailorable and flexible if it is to be of practical use to the people doing the work.
Having now discussed the origins of the field, and early debates about the nature of the field, together with a brief look at some CSCW-related systems and their uses, we turn our attention back to the fundamental questions of what this field has to contribute to the design of effective tools and techniques to support the cooperative work process.
7. Issues in CSCW design
We have already noted that, as far as CSCW is concerned, the traditional approaches used in HCI are less than adequate. Among the more prominent weaknesses that have been identified are (Bannon, 1991):
• its focus on the individual user
• its lack of contact with the ‘real world’ situations of use,
• its tendency to confine itself to the small experiment,
• its use of novices rather than ‘real world’ users and
• its neglect of the way in which users can acquire expertise through experience
Such complaints have been widely aired and often amount to diagnoses of why ‘large scale’ systems fail despite the apparent care which has gone into their design (Grudin, 1988).
Although criticisms such as these have their point, CSCW is not simply about remedying the weaknesses of traditional HCI. It is also about, and in some respects this may be considered to be a discovery of HCI itself, proposing a new approach to system design and evaluation consonant with the new territories into which systems are beginning to move. In particular, the advent of distributed systems, interactive systems, new means of harnessing the computer to communication media, and the possibility in all of these cases of enhancing the scale and scope of human-computer activities. Thus, for CSCW, the issue is not, to put it simply, to see what work activities can be done by machines, but to think about the work first in order to see how machines can be brought in to support it. The shift can be seen in the OIS field where the terminology has changed from ‘automating’ the office to ‘supporting’ office workers with appropriately designed information systems (Woo and Lochovsky, 1986; Hewitt, 1986; Hughes and King, 1992).
Irrespective of whether or not this new approach represents a paradigm shift in system design (Hughes et al, 1991), the task of realising these possibilities effectively means that design attention has to be paid to work and its activities not as the activities of a single user but of multiple users co-ordinating their activities. It is this attention which is the purview of CSCW. Thus, although computers have been part and parcel of the infrastructure of many organisational settings for some years, for example in payroll and personnel systems, command and control systems, records of all kinds, and so on, few were explicitly designed with cooperative and distributed activities in mind or with sufficient regard to being designed for use by co-operating persons who were not experts in the system itself.
So, as a design endeavour CSCW offers, first, at least a complement and enhancement of orthodox approaches to system design and, second, an innovative approach to the design of systems which do not so much attempt to replace human activities but provide more effective support for those activities. In this latter respect what is especially important is the movement from an individual user centred approach in design to one which acknowledges, and intends to harness, the cooperative and collaborative features of human activity: a movement which is often summarised as a shift from the individual to the ensemble. The possibilities here are, of course, enormous. It is not simply that new ways of co-operation become possible, such as working synchronously at a distance, but that, in addition, new ways of organising cooperative work activities by means of computer support become realistic. What this leaves CSCW with are a number of design challenges which can be summarised as follows:
• securing a ‘real world’ reference for understanding the nature of cooperative activities
• relating the analysis of cooperative activities to system design
• allowing users to inform the design process.
These are, of course, closely related, and highly general, questions and issues which constitute the research agenda of CSCW. For, as yet, much of the main activity within CSCW is research, but research which is becoming more closely attuned to the needs of commercial CSCW design. We begin with that of securing a ‘real world’ reference for CSCW system design.
Securing a real world reference for CSCW
As noted earlier, one of the strongest criticisms of traditional HCI has been its lack of effective focus on the context into which a system would have to fit. This is, of course, a collection of complaints, substantive and methodological, and points to the need for system design methods to acknowledge the social character of work and its activities. This is, of course, to propose a need not to offer a solution. A need, moreover, which is not clearly perceived let alone clearly articulated. However, it does constitute the invitation for additions to the extant interdisciplinary contributions to system design, namely, the social sciences, particularly sociology, anthropology and organisational studies.
One of the problems of securing a ‘real world’ reference for CSCW is, as we have also commented earlier, the variation in conceptions about what is constitutive of CSCW. The lack of a commonly accepted definition, not itself as serious a problem as it can be made to sound, makes the field a more ‘contested terrain’ than it is a quietly settled community of practice. It is this which makes this issue one of the more important areas of CSCW research.
Broadly speaking there are two conceptions of what ‘cooperative work’ or ‘cooperative activities’ might mean:
• Activities which involve a small number of persons who are directly and co-presently involved in some task. Examples of this would be jointly moving furniture, manning a control room, a meeting, a tutorial. Here the emphasis is on the small group actively engaged in concurrent co-operation to perform some task. Sørgaard (1987), for example, argues that cooperative work is non-hierarchical, non-specialist and relatively autonomous.
• Activities embedded in a division of labour. Examples here would include almost any work activity insofar as it involves an interdependence with the work activities of others, co-present or not, occurring synchronously or not, hierarchically organised or not, specialist or not. This would, as Bowers (1991) points out, embrace almost any work and its activities.
These are not, of course, antithetical nor are they necessarily discrete entities since many of the activities embraced by the second conception can, and often do, involve intermittent or permanent groups working together as in the first conception identifies. What they do, however, is draw attention to the range and scope involved in CSCW design. The former conception, for example, stimulates efforts to produce a simulacrum of co-presence even when the parties are spatially distributed. In the latter, and broader, conception, co-presence need not be a distinctive focus, although it is by no means excluded, but rather attention is directed to supporting the ingrained interdependence of work activities.
It is the broader-scoped conception of the focus of CSCW which most explicitly brings to the fore the analysis of the socially organised character of work and brings it into HCI, so loosening it from its narrower cognitive implications, - disciplines such as sociology, anthropology, organisational studies, among others. The effect of this is to not only make HCI a broader endeavour in terms of the disciplinary resources in which it can draw, but also raises the important question of the relationship between the respective disciplines. If CSCW is interdisciplinary, and it is hard to think of it in any other way, then this union would need to achieve some integration. The diagram below sketches one such model of this relationship.
[FIRST DIAGRAM HERE]
In this model the presumption is that CSCW is an additive combination of the disciplines that have informed HCI with the addition of social science to bring the social into system design. What the model does not specify, of course, is how the additive process might work. It requires, at the very least, some presumption akin to the reductionist account of the relationship of the sciences to one another or, alternatively, some phenomenal distinctiveness for the domain of each discipline such that, when combined, a fuller, more rounded, more exact picture is obtained.
However, such a model ignores the very different auspices under which disciplines ‘ply their trade’. By ‘auspices’ is meant the way in which disciplines select and constitute their phenomena of interest and the means by which this interest is instantiated in studies and investigations (Hughes and King, 1992). Thus, and by way of illustration, the putative failure of HCI referred to earlier with its focus on more or less controlled experiments and the use of novices is not some happenstance but rooted in the very conception of psychology and, more widely, cognitive science and its method. It is a way of approaching the study of human competencies by attempting to isolate the factors that constitute that competence and evaluating their relative weight through experimental procedures. To the extent to which such auspices are disputed by other disciplines, and they are, then it makes little sense to speak of ‘adding’ disciplines in order to produce a more rounded approach to design in CSCW. More likely, is the imperial model as set out in Fig. 2; a model which emphasises the conflicting and contested character of disciplinary relationships using sociology as an example.
[FIGURE 2 HERE]
Thus, the issue is not so much how to aggregate the different ways of specifying and studying a problems, but a matter of who occupies the relevant terrain. Thus the argument sociological approaches would have with, say, ergonomics is a fundamental one about the specification and descriptions of work activities as phenomena, how and in what ways they can be described and measured, and more. Similarly, the argument sociology might have with psychology is not always one about the borderlines between the two disciplines but, in sociology’s case, about the nature of ‘mental’ phenomena as to whether they are ‘mental’ in the way that psychology might treat them or whether they are social (Coulter, 1983). Disciplines in the human sciences, in other words, do not always see eye-to-eye about what is the right way to proceed, what is the phenomena they are investigating, etc. Procter and Williams (1992) raise this as the question of ‘problem ownership’. HCI is, they claim, and we would add CSCW, ‘disputed territory’ between, for example, ergonomics, psychology, cognitive science and, now, the new upstarts of the more social of the human sciences, all vying for ownership of the problem.
Clearly, and in light of the broad distinction between the ‘narrow’ and the ‘wider’ conception of cooperative activities, how these are seen is a matter which has a great deal to do with the discipline that is brought to bear and how, ultimately, analyses are mapped onto system design itself. As indicated earlier, one of the major rationales for the invitation to the social sciences to become part of the ‘design discipline’ of CSCW is to provide the necessary analysis of work as a social activity. By now it is a commonplace to acknowledge that work is a social activity and that computer use is within a socially organised world which has tremendous relevance for the reception and the use of the system. This has already been acknowledged in a number of studies, for example and noted earlier in the report, attempts to design and produce an ‘automated office’ which, by and large, failed to capture the locally situated activities and interactions that constitute the ‘real world’ of the office (Gerson and Star, 1986; Suchman, 1983). Moreover, it is also clear from a number of studies that many systems fail, or fail to realise their design potential, because their designers understood little about the situations of use (see, for example, Ackroyd et al, 1992; Greenbaum and Kyng, 1991). Equally, it is also the case that many systems are saved from their worst excesses because of the skill, adaptability and flexibility of the human operators. However, this, once again, merely states a need for analyses of work as situated action rather than offering a solution. The problem for the social sciences, and let us take sociology as an example, is that it has no theories of cooperative activities to ‘plug into’ system design or, more precisely, the nature of co-operation is, within the discipline, a ‘contested terrain’. Sociology has plenty of theories but these are best described as ways of 'thinking sociologically' rather than theories which might do any work in system design. Certainly, it does require some not inconsiderable revision of the kind of attention sociology might give to its analyses in order to contribute in some effective way to CSCW (Hughes and King, 1992; Hughes et al, 1993).
Some guidelines on how this reorientation of the sociological attention might be achieved are already emerging and already alluded to. What this amounts to, in brief, is drawing upon ethnomethodological presumptions to treat, from the outset, the ‘real world’ as a socially organised phenomenon which is seen and treated as such by parties to social occasions, including work and its activities. The orderliness, the sense, the intelligibility of work is a function of the commonsense understandings that parties bring to the occasions and the features of work (Hughes and King, 1992; Hughes et al, 1993; Button, 1992). There are some potentially useful approaches here. For example, the kind of detailed ethnographic studies that are now being brought into system design by CSCW are producing the rich analysis of work settings and their socially organised character which offer a more secure ‘real world’ reference for design (Suchman, 1987; Hughes et al, forthcoming). Working in collaboration with computer scientists ethnographers have begun to inform system design in ways that begin to challenge many of the orthodox presumptions of system engineering (Sommerville et al, 1993). One effect of such a stance is to put in jeopardy many of the traditional methods of requirements capture which have hitherto dominated systems design, though not consistently or with conspicuous success (Cartensen and Schmidt, 1993).However, ethnographic analyses, useful though they are and more useful though they may become, do need a more effective analytic framework to inform design (Hughes and King, 1992; Button, 1993). This is especially true of large scale systems in industrial design contexts.
Another issue that surfaces here is the scope and scale of systems and how these may be related to the analysis of work activities. The ethnographic mode of inquiry tends to be restricted to the small scale whereas most work takes place within larger organisations, some of a national and international scale. Effective co-operation within such organisations is a major challenge for CSCW and one which is generating some effort. However, what this also raises are conceptual and theoretical problems about the nature of organisations themselves.
The issue of securing a ‘real world’ reference for informing CSCW systems about the nature of the work settings which such systems are intended to support, is an active field in CSCW research. Currently the methodological strategy is to develop a case-by-case approach rather than presuming that all work settings, all organisations, and all collaborative activities are the same.
Relating the analysis of work to design
The kind of disputes noted in the previous section are exactly what one would expect of a field, such as CSCW, which is, despite its applied character, still in the process of doing basic research and, as mentioned above, the human sciences on which it has to draw have no agreed on fundamentals. However, despite this, any attempt to restrict the disciplinary resources on which CSCW can draw is bound to be premature. However, though this may be an expected state of affairs for a field still in its early stages and full of Howard’s (1988) ‘loose constructionists’, for CSCW as a practical design discipline this is not entirely satisfactory. System designers want precise and unambiguous models rather than disputes about the nature of the ‘real world’. Against this, of course, is the obvious point that design is always incomplete and, accordingly, CSCW design itself needs to acknowledge this by producing systems which are open, adaptable and flexible (Shapiro, 1993). However, this does not make the designers problems go away.
Most existing CSCW, or proto-typical CSCW systems have been designed and developed in an informal manner often relying on the close co-operation across small research teams, often within research laboratories. However, as systems become more complex, larger and more subtle in the operations they are intended to perform, the task of developing such systems itself becomes more and more complex. In many areas of system development production methods have already reached industrial proportions so making the integration of software with other elements more and more of a managerial problem as it involves more varieties of skills and numbers of people. However, if traditional requirements capture methods, which are very ‘technically oriented’ in any case, are less than satisfactory for the purposes of CSCW design, then what is to take their place? The nascent state of sociological research into work analysis provides no ready answer and is itself the subject of basic research work.
One line of investigation is to develop conceptual schemes and notations which more adequately reflect the cooperative nature of work and its settings; schemes and notations which lend themselves more readily to system designers without destroying the richness of the social world which they are meant to portray (Schmidt and Bannon,1992; Schmidt, 1991). An important feature of such an endeavour, and an aspect of the necessary reorientation of design attention referred to earlier, is that CSCW design cannot simply be about the design of a machine but has to explicitly involve redesigning the organisation of work itself. The objective of CSCW design is no more and no less than the design of a socio-technical system in such a way that co-operation, however this may be construed, is enhanced in terms of efficiency, flexibility, responsiveness, safety, or human dignity (Schmidt, 1993). In other words, CSCW design, as design has always been, is as much a normative activity as it is a technical one.
Involving the user
In system design it has long been accepted that design needs to be informed by models of the user. In traditional HCI such models tended to be of the single user and built along cognitive principles which took little or no heed of the social dimensions of system use. Within CSCW, however, such an approach is deficient for two main reasons: first, CSCW is about collaborative activities among a number of persons and, second, the social dimension can only adequately be described by the study of cooperative activities within ‘real world’ settings. Added to these is the demand from users for more flexibility and a greater ease of use of interfaces and systems.
Grønbœk et al (1993) make the point that as computer systems have spread into work environments, the gulf between the developer and users has widened and needs to be remedied by a greater involvement of the user in the design process from the earliest stage. The diagrams below set out the differences between traditional system development and that proposed by CSCW design.
Fig. 1: the workplace and the development process
In fig. 1 systems are developed in a laboratory or software house to be applied within a ‘real world’ context and work setting. Developers typically have only a partial knowledge of this setting provided by a set of requirements extracted by relatively formal methods at the start of the design and development process. This tends to produce a mismatch between the designed system and the ‘real world’ needs for support adequate to the socially situated features of user activities.
Fig. 2: bridging the gap
An alternative approach is provided in fig. 2 which relies on observational studies mentioned earlier and/or user participation throughout the design process to minimise the mismatch. How and in what ways these can be effectively developed is a major research area within CSCW for although observational studies and user participative design do have similar objectives to the extent of involving the user more, the latter has a much more explicit focus on what users want and is closely involved in issues to do with the democratisation of the workplace. Observational studies, on the other hand, do not embrace the political issues quite so formally, and would argue that although there is a strong sense in which putative users of a system are immensely knowledgeable about the work, this tends to be partial and egocentric rather than having a grasp of the social interdependencies of work activities. As noted, this remains an important research area in CSCW.
Nonetheless, it remains an important aim of CSCW that users conceived as participants within ‘real world’ settings and not as the homunculi of some ‘technically oriented’ requirements method, must become central to cooperative system design. The immediate effect of this is to broaden the conception of the user to include not only the individual but to include those who may not be direct users of the system but who can be massively affected by its operations (Ackroyd et al, 1992). However, this does not remove the kind of problems noted in above about relating the analyses of work to design.
What it does emphasise, however, is giving a much more salient and explicit role to system evaluation (Bannon, 1993). CSCW, it can be argued, needs to embrace a design practice that incorporates a much fuller understanding of the situation of use, of the needs and concerns of the actors involved and a continuing evaluation of the system in use. Although the proposal that design, use and evaluation should be seen as interleaved and interpenetrating activities and not as distinct steps in a linear process has more than some merit, there can be little doubt that it goes against many of the extant practices of system design and development within industrial contexts. Bannon (1993) goes on to identify the relevance of a ‘wheel of design’ (Henderson, 1991) - encompassing use to observation to analysis to design to implementation to (re-)use - for designingCSCW applications. This view is important because it addresses some of the problems found currently, viz.
• the intuition of software designers about user groups is often poor (Grudin, 1988) and so understanding the context in which the system will be placed becomes even more important - thus arguing for the need for early prototyping and feedback from users;
• existing models of group communications and activities are open to question and largely irrelevant to effective CSCW design;
• refinement of initial models tend to be based on abstractions rather than empirical validation.
• models are abandoned or taken up without any clear rationale for this process.
In other words, to avoid these pitfalls CSCW design needs to be extremely receptive and explicit about the need for effective observation and evaluation throughout the design process itself. This will inevitably involve a closer sensitivity to the way the system is used than has been typical in HCI hitherto. Methods for observing and analysing use are once again under scrutiny and development, and their uptake into standard design practice is also under consideration.
References
Bergland, G.D. (1981), ‘A Guided Tour of Program Design Methodologies’, Computer, October, pp. 13-37
Bowers, J. & Benford, S. (Eds.) (1991) Studies in Computer Supported Cooperative Work: Theory, Practice and Design. Elsevier North-Holland: Amsterdam.
Button, G. (ed) (1993), Technology in Working Order, London, Routledge.
Coulter, J. (1983), Rethinking Cognitive Theory, London, Macmillan.
Henderson, A. (1991), ‘A development perspective on interface, design and theory’,
Hewitt, C. (1986) Offices are open systems. ACM Transactions on Office Information Systems, 4,3, 271-287.
Marshak, D. (1990) Lotus Notes: A platform for developing workgroup applications. Patricia Seybold’s Office Computing Report, 13, 7, July 1990, 1-14.
Rose, M. (1988), Industrial Behaviour: Research and Control, Harmondsworth, Penguin.
Shapiro, D. (1993), ‘The Boundaries of Design for CSCW’, COMIC Working Paper, Lancaster University.
Suchman, L. (1987), Plans and Situated Actions, Cambridge, Cambridge University Press.
Wilson, P. (1991) Computer Supported Cooperative Work: An Introduction. Oxford, Intellect Books.