CSCW: History and Focus

Jonathan Grudin
Information and Computer Science Department
University of California, Irvine
Irvine, CA 92697-3425
(714) 824-8674 fax: (714) 824-4056
email: grudin@ics.uci.edu

Abstract

This article describes the participation in CSCW research and groupware development. It ties the emergence of CSCW in the 1980s to the growing interest of product developers in supporting networked groups and the discovery of common interests with those working management information systems, as well as with researchers in the social sciences and other disciplines. Differences in emphasis in Europe and Japan are discussed. The picture that emerges is of CSCW as a forum bringing together researchers and developers who share some but not all interests and must overcome the difficulties of multidisciplinary interaction.

Keywords: computer-supported cooperative work, groupware, group interfaces, organization interfaces, group support systems, computer-mediated communication, workflow

Introduction

Ten years ago, Paul Cashman and Irene Grief organized a workshop of people from various disciplines who shared an interest in how people work, with an eye to understanding how technology could support them. They coined the term "computer-supported cooperative work" to describe this common interest. Over the past decade thousands of researchers and developers have been drawn to it. The first conferences were held in the United States, but the topic was picked up immediately in Europe and Asia, where related work and serious interest already existed. This article describes the people and the work found under the CSCW umbrella.

Why in 1984? An earlier approach to group support, "Office Automation," had run out of steam. The problems were not primarily technical, although technical challenges certainly existed. The key problem was understanding system requirements. In the mid-1960's, tasks such as filling seats on airplane flights or printing payroll checks had been translated into requirements that resulted (with some trial and error) in successful mainframe systems. In the mid-1970s, minicomputers promised to support groups and organizations in more sophisticated, interactive ways: Office Automation was born. Single-user applications such as word processors and spreadsheets succeeded; office automation tried to integrate and extend these successes to support groups and departments. But what were the precise requirements for such systems?

Building technology was not enough. We needed to learn more about how people work in groups and organizations and how technology affects that. Some engineers, notably Douglas Engelbart, had made this point all along. In addition, some in the Management Information Systems field had promoted this as a way to improve success rates in large system development. But it had been largely absent from discourse among designers and developers in the vendor company settings engaged in early efforts to develop group support applications. CSCW started as an effort by technologists to learn from economists, social psychologists, anthropologists, organizational theorists, educators, and anyone else who can shed light on group activity.
It is also a place for system-builders to share experiences and inform others of technical possibilities and constraints. Applications include desktop conferencing and videoconferencing systems, collaborative authorship applications, electronic mail and its refinements and extensions, and electronic meeting rooms or group support systems. Other application domains that are related but not strongly represented include Computer-Assisted Design/Computer-Assisted Manufacturing (CAD/CAM), Computer-Assisted Software Engineering (CASE), concurrent engineering, workflow management, distance learning, telemedicine, and the real-time network conferences called MUDs (after "multi-user dungeons," although they are now used for more than game-playing).

The acronym CSCW has survived a decade of use. It has been criticized for violating the maxim that four words are too many (some use "computer-supported collaboration" or CSC). It has been criticized because "cooperative" work is often more a goal than a reality. "Workgroup computing" shifts the focus from the work being supported to the technology and restricts it to small organizational units. So does "groupware," used by Peter and Trudy Johnson-Lenz prior to 1984 and adopted by the CSCW community. We now have annual conferences both in groupware, focusing on commercial technologies, and in CSCW, addressing research into experimental systems and into the nature of workplaces and organizations. I will rely on the terms CSCW and groupware to describe the research and the technology respectively.

This article identifies historical shifts, demographic patterns, and geographic distinctions that underlie contributions to CSCW. Different academic and industrial contexts participate in CSCW research and development. The fields of human-computer interaction and information systems play major roles. Research in systems and software engineering that is potentially germane has been slow to appear in CSCW conferences and journals. European and North American perspectives differ; Japanese research and development is becoming more visible.

Research and development contexts: history and contributions

Each ring in Figure 1 represents one focus of computer systems development and the principal "customer" or "user" of the resulting technology. It is a rough framework for work in the United States-European differences are discussed later. Until recently almost all activity was in the outer and inner rings. The outer ring represents major systems and applications, primarily mainframe and large minicomputer systems designed to serve organizational goals: transaction processing, order and inventory control, computer integrated manufacturing, and so on. The inner ring represents applications designed primarily for individual users of PCs and workstations: word processors, debuggers, spreadsheets, games, and so forth. The two rings between these represent large projects and small groups. Large project support includes electronic meeting rooms and workflow automation systems, which are most useful for groups of 6 or more. In contrast, a major focus of small group support-computer-mediated communication (CMC)-includes desktop conferencing and collaborative writing applications, which may not work well with more than 3 or 4 users. Development in each of the middle rings is called "groupware," but for reasons explored below, CSCW gatherings, especially in the United States, have focused primarily on small-group support, the second ring from the center. The trade-oriented groupware conferences have focused more on project-level support and "workflow management."



Figure 1. U.S. research and development contexts for CSCW and groupware

 

On the left of Figure 1 are software development contexts that dominate development of systems and applications of different scope. Software systems that support entire organizations (the outer ring) are not bought at a local computer store or even at a local mainframe sales office. Some components might be acquired that way, but most development is unique to the organization. Internal or in-house development has produced an extensive body of software, with other development contracted out. In contrast, in the innermost ring, single-user applications are the province of commercial off-the-shelf product developers, who rely on the large potential market for shrink-wrapped software to provide sufficient sales and who do little or no customization for individual customers. The two central rings represent groupware development: i) Government contracts have stimulated project-level software support. ii) Small-group support has been a new focus for commercial product developers and telecommunications companies are strongly interested in technologies such as video that create demand for high bandwidth communication. We will see that the emergence of CSCW in the 1980s includes both of these but is most strongly tied to the second, the shift of attention to small networked groups.

On the right of Figure 1 are major research areas associated with the development and use of systems linked to each development context, and a date by which each was firmly established. Starting with the outer ring, a literature associated with systems in organizations arrived in the mid-1960s with integrated circuits and "third generation" computer systems. It has been called data processing (DP), management information systems (MIS), information systems (IS), and information technology (IT). Friedman [4] summarizes, "There is very little on the subject up to the mid-1960s. Then the volume of literature on (computers and) the organization of work explodes. Issues of personnel selection, division of labour, monitoring, control and productivity all subsequently receive considerable attention."

The IS field has primarily focused on organizational support, but the management of large projects has also been a concern (the next ring). In the early and mid-70s, the fields of Software Engineering (SE) and Office Automation (OA) emerged, focusing on computer support for large groups and projects. Computer support for software engineering is a specific kind of large project support, but it is a natural setting given the high concentration of technology in development environments. The complexity of managing large government software contracts provided further incentive to apply technology in this area. As noted above, OA did not survive as a field, but many of the issues underlying distributed project management systems are again being addressed as "workflow."

The inner ring emerged next: The Human Factors Society and starting in 1983 ACM SIGCHI presented research into single-user applications and interfaces. The most recent is CSCW, with the 1984 workshop followed by the CSCW'86 Conference in Austin, Texas.

CSCW: Research that spans the boundaries. Figure 1 only represents central tendencies. For example, large companies contract out software development and increasingly acquire commercial software as well. For our purposes, the most important caveat is that CSCW is not wholly restricted to one "ring"-CSCW draws developers and researchers from each pre-existing culture. It represents a merging of issues, approaches and languages. Spanning boundaries, CSCW and groupware are difficult to define; no definition satisfies everyone involved. This creates an exciting potential for cross-fertilization and for doing work with broad implications. Indirect effects can be studied: The use, in group and organizational settings, of applications that were developed for individual users; the ways in which software, developed to support groups, affects individuals and is adapted to different organizational contexts; systems developed to support organizational goals as they act through individuals, groups, and projects. Individual, group, project and organizational activity are fundamentally intertwined. Figure 1 is one partitioning of the system development world; it obscures other perspectives, notably our ability to examine issues that transcend the divisions.

Project-level support: the ring less heard from. The most comprehensive collection of readings in Groupware and Computer-Supported Cooperative Work [2], with over 70 papers, contains nothing on workflow management or project-level software engineering support. Project-level support is represented only in the coverage of electronic meeting rooms. CSCW conferences in the U.S. also focus on small-group support, with some organization-level analysis.

Other potentially relevant work, such as computer-mediated education, is also underrepresented in the CSCW literature. Why? These fields have their own conferences and journals, which keep them busy enough. In addition, their concerns are of less interest to product developers eyeing huge potential markets of small groups and to the information systems field focused on internal and contracted systems development.

The challenge of being multidisciplinary. Whether we view the shared and the disparate interests as a melting pot or a mixed salad, making sense of them is a lively process. Opportunities to learn and to inform generate enthusiasm-which is needed to overcome inevitable obstacles. It is not always apparent why another person's perspective and priorities differ. It takes patience to understand conflicts in priorities and to find mutually advantageous modes of operation. In later sections, some of these differences are identified.

Another problem is that although it can be exciting to find a new source of information and a new potential audience, it can be frustrating when the other group is ignorant of work that you assume to be basic shared knowledge. The groups participating in CSCW are not always aware of the extent to which they have relied on different conferences, journals, and books.

Consider the "Tower of Babel" problem-participants from different areas use the same terms in subtly different ways. What do the words "user" and "implementation" mean to you? In the field of human-computer interaction, "user" refers to a person sitting at a display, entering information and commands and using the output. In the information systems field, "user" refers to a user of the output, a person who might not touch a keyboard. To deal with the ambiguity, the latter field coined the term "end user" to describe a person at a terminal or keyboard. Thus, the term "user" has different connotations that two conversants are unlikely to recognize. Nor is that the end of it-in software engineering, the term "user" can mean the users of particular tools, who are themselves developers.

Similarly, "implementation" is synonymous with development or coding in HCI, but to the MIS world it describes the introduction of a new system into an organization. Many, perhaps most, terms are used differently by different research and development communities. In conclusion, one must attend carefully to meaning when navigating the CSCW literature, including the articles in this issue of Computer.



   CHI'90
(program)
 CSCW
'86-'90
 ECSCW'89
Crete'90
 ICIS'90

Academic (%)

 40  30  70 *  85
Product
development
 30  40  10**  1
Telecom-
munications
 10  7  5  0
Other  20  23  15  14

*Includes government research laboratories
**2/3 from U.S. computer companies
From Japan (over 30 CSCW'90 participants, 2 of 30 papers): Product development: 55% Telecommunications: 25%

Table 1. Conference demographics

The composition of CSCW participation

Table 1 lists the attendance at seven conferences by the type of organization employing the participants. The second column averages the first three U.S. CSCW conferences; the third column averages the first two held in Europe. Government research laboratories in Europe are merged with academic positions due to the prevalence of joint appointments and the similar nature of the research. By way of comparison, the first column shows participation in CHI'90, a large ACM conference on HCI (the presenters; figures for participants are unavailable). In the rightmost column is the participation in the International Conference for Information Systems, the premier IS research conference.

The similarity in composition of the CHI and the U.S. CSCW conferences indicates that CSCW in the U.S. grew from the human-computer interaction field, fueled by computer companies moving beyond single-user applications to products supporting small-group activity. (In fact, the CHI organization co-sponsored CSCW conferences after 1986). However, leading IS figures also participate in CSCW. ICIS'90, liked CHI'90, had a CSCW paper session. However, the vendor company dominance in the U.S. has implications, particularly for those whose backgrounds and priorities differ.

In Europe, as the third column suggests, the focus is not on small-group applications or potential products. European research labs often focus on organizational and large project issues.

Over 30 CSCW'90 participants came from Japan. Like the American participants, they were primarily from product development and telecommunications companies. English-language journal articles by Japanese contributors focus on small-group applications.

The next two sections contrast a) the perspective originating in single-user applications versus the perspective originating in organizational systems; b) the U.S. perspective versus the European, with further comments on work in Japan.

Small-group applications and organizational systems

To summarize the preceding analysis, a major impetus for CSCW conferences is the growing interest in small-group applications. As PCs and workstations are networked, myriad small groups become potential new markets for vendor companies. Mature single-user applications can be enhanced with groupware features. New applications to support communication and coordination are conceived. Simultaneously, telecommunications companies seek to increase the demand for bandwidth through applications that draw on multimedia technologies.

As off-the-shelf single-user product developers extended their view to computer support for groups, many confronted issues in group dynamics for the first time. The design of applications such as word processors stressed perceptual and cognitive factors. Developers often succeeded with minimal attention to the actual workplaces in which single-user applications were used. With groupware, social, motivational, and political aspects of workplaces suddenly become crucial [6].

Organizational systems-mainframes and large minicomputers-had been in use for decades. Issues of social dynamics were familiar to IS researchers and developers. They did not establish the CSCW agenda, but they can share their knowledge with product developers and have other incentives to participate: Networked PCs, workstations, and software products are increasingly important components of organizational information systems. Also, as large systems decline in cost, they can be used by smaller organizational units. An example explored below is "group decision support systems," once expensive and marketed for use in high-level decision-making, which have evolved into "group support systems," less expensive and flexible enough to support a variety of meeting types.

The small-group application and IS communities share some interests but have striking differences. For example, most small-group support emphasizes communication. Small groups are generally formed to bring together people who have a need to communicate. Communication is also the priority for the telecommunications industry. In contrast, organizational systems focus more on coordination, because coordinating the efforts of disparate groups is a major problem at the organizational level [12].

Similarly, members of small groups usually share key goals. As a result, product developers anticipate relatively little friction or discord among users and assume a "cooperative" approach to technology use. This is directly reflected in the second "C" of CSCW. In contrast, researchers and developers focusing on organizational systems must attend to the conflicting goals that are generally present in organizations [e.g., 10, 11]. For that reason, some in the Information System community argue for changing the second "C" to mean "collaborative" or even for dropping it altogether.

Another contrast is that product developers are more concerned with the human-computer interface, whereas the developers of organizational systems and their customers are more fixated on functionality. Product developers compete in discretionary markets where useful functionality is quickly adopted by others, at which point the human-computer interface can provide an important edge. In contrast, internal developers of information systems often face unresolved design questions based on the functionality needed in the workplace and cannot justify the cost of fine-tuning the interface.

When the reasons for differences in priorities are not understood, confusion results. A speaker from the IS field berates small-group application developers for focusing on "cooperation" and ignoring conflict, and criticizes research that focuses on the thin surface layer of the human-computer interface. On the other side, those working to resolve technical problems question the value of research into organizational politics that is distant from their concerns.

It has been suggested that CSCW pits social scientists against technologists, but this may not be the real source of conflict. In large information system environments, decades of experience have surfaced non-technological problems, whereas in small-systems environments, technological hurdles still predominate. For example, Scandinavian researchers and developers working on tools and techniques for collaborative design are often tied to the "social science" perspective, but they are actually computer scientists who do not practice social science. They came to realize the importance of social effects in the course of developing large systems. Conversely, many behavioral and social scientists are hired into industry research labs and then evolve to be "technologists." Unless we understand the origins of our differences we will not succeed in addressing them.

The United States and Europe

American and European approaches to CSCW overlap, but also contain marked differences. These partially reflect the small-system/product development and large-system/internal development distinction.

In the United States, major computer and software product companies have much more influence than their counterparts in Europe. Research and development are more intertwined in the U.S., where computer industry research labs and industry support for universities are very influential. In Europe, more research is government-sponsored, academics are relatively innocent of corporate support, and the focus of activity is on large-scale systems development, often in user organizations.

Many U.S. researchers and developers focus on experimental, observational, and sociological data; others exhibit a technology-driven eagerness to build systems and then look for ways to use them. These U.S. approaches can be described as empirical: experiments by social psychologists looking at group activity among teams of students, anthropological descriptions of activity in schools and businesses, descriptions of groupware that present interesting technical problems whether or not the technology is used.

European contributions to CSCW are often driven by philosophy or social, economic or political theory. Some European contributions to CSCW are explicitly grounded in the writings of Wittgenstein, Heidegger, Elias, Marx, Vygotsky or others. (This does not characterize all European computer science or informatics, much of which is more formal.) The result may be a broad formulation of system requirements or an implementation of a platform to support a range of applications that in concert are to provide organizational support.

The distinct European CSCW also reflects cultural norms in European countries, such as greater national homogeneity, co-determination laws, stronger trade unions, and more extensive social welfare. At the risk of oversimplifying, greater cultural homogeneity can lead to the acceptance of a welfare state, which in turn can lead to a systems development focus on skill augmentation (in contrast to automation) that is justified on humanitarian but also economic grounds: Workers losing automated jobs must be indirectly supported anyway. The Scandinavian participatory or collaborative design approach reflects these priorities [11].

The differences are partly bridged by work in England. Due to shared language and culture, perhaps, several U.S. technology companies have active research labs in England. The most notable fusion of U.S. and European approaches is Rank Xerox's prolific Cambridge EuroPARC research center. Examples of work carried out with closely associated academic researchers in the U.K. are experimental studies of collaborative writing, sociological analysis of group activity in settings ranging from development laboratories to the London Underground control room, and the construction and use of video communication systems.

CSCW in Europe is supported by an enormous variety of grants. Major European Community projects funded by the European Strategic Programme for Research and Development in Information Technology (ESPRIT) and Research and Development in Advance Communications Technology in Europe (RACE) explicitly bring together researchers and developers from different countries. These also require both academic and industry partners. Some projects involve tightly coupled work, others consist of more independent efforts at each site. These projects are exercises in cooperative work whose content is CSCW research and development.

Another effort to build cooperation among researchers and developers in the European Community countries is the CO-TECH project, carried out under the Cooperation in Science and Technology (COST) framework. This provides funding for organizing and attending meetings, not for research itself, and has succeeded in building a sense of community.

In addition, many European governments directly fund research in this area through government research laboratories and specific government projects. One example is a major German effort to develop an infrastructure to support the division of the country's capital between Bonn and Berlin.

NSF is an important supporter of U.S. CSCW projects, but it is less influential than European funding agencies in shaping the research agenda.

The CSCW'92 Conference illustrated these differences. European presentations included two based on multi-national ESPRIT projects and none from computer companies. The ESPRIT presentations described a working "model for automatic distributed implementation of multi-user applications" and a description of the requirements for supporting the Great Belt bridge/tunnel project in Denmark. In contrast, several U.S. companies were represented, along with five U.S. and two Japanese contributions from telecommunications companies. These reflect and focus U.S. interest in small-group applications and European emphasis on organizational systems.

Will the different priorities of the active researchers and organizations in Europe and the U.S. persevere? Should they? Can the groups interact despite the differences? Conferences have had limited success in drawing from both simultaneously. Philosophically-oriented European submissions often strike empirically-oriented American reviewers as lacking content; American contributions strike European reviewers as unmotivated or shallow. Differences in terminology block mutual understanding. For example, I listened to a European CSCW researcher criticize an American group's understanding of "task analysis." The Americans used the term to describe a cognitive task analysis based on experimental interface testing, a standard practice in HCI. To the European, "task analysis" meant an organizational task analysis based on mapping the flow of information from person to person. To him it was nonsensical to apply the term in an experimental setting.

Cultural differences in the role of research meetings exacerbate the split. In Europe, conferences are often gatherings of professionals to interact and share current results; most of those who attend also present. In the U.S., a conference is more often organized for a larger audience, with greater emphasis on polished results. The difference leads to misunderstandings over submission requirements.

CSCW in Japan and Asia

Thus far, the principal Asian impact on CSCW and groupware research in the West has come from a growing number of Japanese contributions. In Japan, government and industry cooperation in technology development includes support for CSCW.

Japanese CSCW research has only recently been published in English, but there is widespread interest in technological support for group process. The "software factory" concept and interest in process programming (formal workflow management systems) are examples. Contributions to CSCW have come primarily from computer and software companies, including NEC and Toshiba, and telecommunications companies, including NTT and ATR. In this respect Japanese participation matches the non-academic profile of U.S. participation.

Discussions of CSCW in Japan risk oversimplifying. We may miss important distinctions and qualifications, or overgeneralize differences that are identified. For example, it is often suggested that Japanese enthusiasm for collaboration and consensus will increase groupware acceptance. Closer examination reveals a more complicated reality. Ishii [8] notes that in Japan, the importance of showing consensus in meetings often leads to real decision-making occurring in private discussions, eliminating a role for meeting support software. More generally, the preference in Japan for personal contact and direct interaction could actually increase the resistance to technological mediation (Hiroshi Ishii and Gen Suzuki, personal communications). Thus, one should avoid predicting the success of a groupware technology in a different culture too quickly. Cultural issues are very important, but also complex.

Defining groupware

We can now reexamine a recurring question: What should be included under the rubric of "groupware" or "CSCW applications"? Figure 2 outlines the controversy. Everything above each arrow is labeled "groupware" by the author or authors to the right. Starting at the bottom, Crowley [4] argued that the single greatest impediment to computer support for workgroup collaboration was the lack of software that permits interaction across networked PCs. For that reason he felt that network file servers and related software was of central importance and should be considered groupware. Grudin and Poltrock [7] considered multi-user software such as large databases and version control systems because they provide informative success cases. Kraut [4] argued that electronic mail was the only successful CSCW application, eliminating from consideration successful software below that line. The argument for excluding multi-user databases is that they support groups by providing the illusion that every user has independent access; apart from password control, these databases are not aware of different roles or communications needs in a group. They are not "group-aware." By this definition, a database with triggers to alert specific people to specific changes would qualify as groupware. Finally, Allen [1] is among those who have argued that electronic mail is itself a substrate for groupware applications but should not be called groupware due to its insensitivity to organizational or group qualities.

Researchers and developers with a small-system orientation lie at the bottom of this sequence and those with an organizational perspective are at the top.




Figure 2. Different demarcations of groupware and its substrate

This can be resolved by observing that a blanket categorization of an application is less helpful than considering how it is used in a particular setting. Thus, email used only to broadcast organization-wide messages is not supporting groups, whereas an email system with users who create aliases, distribution lists, and complex patterns of use that differ across projects does qualify as group support technology. This position is intellectually defensible, but the reality is that researchers, developers, and marketers want general, site-independent labels. Thus, no formulation will satisfy everyone engaged in CSCW research and development.

We are now in a better position to understand the pattern of participation in CSCW and groupware conferences. CASE and computer-mediated education have not been significant to the HCI-product development community or to the IS community and are thus underrepresented. These technologies are explored in other settings. Application areas such as voice that logically belong to CSCW or groupware may reflect an exclusion of old technologies from the new labels.

Groupware typologies

A "multi-disciplinary" perspective enables us to elaborate a familiar groupware typology. Figure 3 presents a variant of the widely used space and time categorization of DeSanctis and Gallupe [3]. Representative applications illustrate the different cells. Activity can be carried out in a single place (top row), in several places that are known to the participants, as in electronic mail exchanges, for example (middle row), or in numerous places not all of which are known to participants, as in a message posted to a netnews group (bottom row). Activity can be carried out "in real time"; that is, in one unbroken interval, as in a meeting (left column). Alternatively it can be carried out at different times that are highly predictable or constrained, as when you send mail to a colleague expecting it to be read within a day or so (middle column). Or it can be carried out at different times that are unpredictable, as in an open-ended collaborative writing projects (right column). Activities may not always match Figure 3 precisely-for example, one collaborative writing project could take place in a single session, but another could involve an unpredictable, large set of people assembling a major piece of documentation. Some cells have enjoyed more computer support than others; for example, interactive multicast seminars are only starting to appear as "same time, unpredictable place" activity.




Figure 3. A 3x3 map of groupware options

This typology is easy to learn. It facilitates communication. It is widely used, especially by groupware developers, but not without risk: Figure 3 obscures an organizational perspective. Most real work activity does not fall into one or another of these categories. As we go about our work, we generally engage in some face-to-face meetings and some distributed and asynchronous communication. Most work involves both communication and coordination. Narrow tasks interact with broader work activities and even the broadest concerns overlap and impact one another. Technology designed to support activity in one cell can fail by negatively impacting activity in another. For example, a stand-alone meeting support system that provides no access to existing databases or other on-line materials may be useless in some situations. Noting the interdependencies among activities, Robert Johansen calls for "any time, any place" support. A typology hobbles groupware developers if it focuses our attention too narrowly. At the same time, it serves legitimate purposes; for example, it helps identify applications that pose common technical challenges, such as those dealing with concurrent activity.

An Example: The History of Group Support Systems

The history of a "same time, same place" technology, meeting support systems, illustrates several points made in this article.

These systems were originally a central component of GDSS (Group Decision Support Systems). Unlike most groupware applications, meeting support did not emerge from product development environments, nor did papers on GDSS appear in human-computer interaction conferences. Until recently, there were no electronic meeting room products. GDSS research and development began over 20 years ago in the Information Systems field, in U.S. business schools. To understand its history, consider the "D" in GDSS. Decision-making was emphasized because until recently, management-as-decision-making was the dominant perspective in schools of business and management [9]. In addition, expensive early systems could be justified in organizations and in a management school curriculum by narrowly focusing on high-level decision-making.

In the mid-1980s, the first CSCW conferences drew GDSS researchers from the IS field. Conflicting use of terminology went unrecognized. The IS community construed GDSS broadly to include all technology that contributes to decision-making, including electronic mail and other common applications. In fact, some in the IS field considered GDSS to be a synonym for CSCW. Encountering the term GDSS for the first time, many from the HCI field assumed it referred only to electronic meeting support, the one technology feature unfamiliar to them. (They also thought in terms of applications, not systems.)

As the cost of the technology fell, GDSS use was no longer restricted to high-level "decision-makers." It could be used to support meetings of various kinds. In addition, the trend toward corporate "downsizing" has lessened the emphasis on high-level decision-making in organizations. As rungs are removed from an organizational ladder, responsibility for decisions often shifts to the groups that implement them. As a result, the "D" was dropped to form GSS, Group Support Systems. The reduced cost, together with improved technology and a better understanding of the process of effective use [6], led to electronic meeting rooms becoming commercial products around 1990.

GSS is support for projects or large groups-meeting support is not as useful with fewer than 5 or 6 participants. The small-group application developers who play a central role in CSCW have different priorities than the system developers working on GSSs, and few GSS papers have been accepted for CSCW conferences. In addition, GSS researchers observed that small-systems researchers were unfamiliar with their literature. Over time, the GSS community has become less involved in CSCW. They have participated in conferences with an Information System orientation, initiated a newsletter that rarely mentions CSCW, and spawned their own journals. They have, however, adopted the "groupware" label, as has the workflow management community-another group focused on large group support.

At the moment, the term "groupware" is found in both GSS and CSCW literatures, used to describe overlapping but different technologies. The divide is only partial and may be temporary. Information Systems research is still presented at CSCW meetings. Both groups can benefit from interaction. But the fragile nature of participation in CSCW is apparent.

Conclusion: Discourse in a CSCW forum

Some writers describe CSCW as an emerging field or discipline, but what we see today more resembles a forum, an undisciplined marketplace of ideas, observations, issues, and technologies. We expect to find shared or overlapping interests and we should also anticipate differences in interests and priorities. Everyone comes to a forum from someplace and returns there. In fact, people come from different places, and it is useful to know where each is from and why they have come. Each visitor can see what the others have to offer and can decide what is worth taking home. No one expects everything to be personally useful or all possibilities to be represented. There is no assumption that everyone speaks the same language, only that they will try to work out some means of communicating.

If we think of CSCW as an emerging field or common enterprise, we may be frustrated by this mosaic of different pieces, the frequent misunderstandings, and the lack of intellectual coherence. But when understood and respected, the differences form the core of richer, shared understandings.

Acknowledgment

Steven Poltrock has helped in shaping these ideas. I also benefited from discussions with Clarence Ellis, Gerhard Fischer and Brad Hartfield. Mark Ackerman, Jeffrey Blevins, Alan Dennis, Gerardine DeSanctis, Rebecca Grinter, Suzanne Iacono, Peter and Trudy Johnson-Lenz, Stefanie Lindstaedt, Jeanne Pickering, Dianne Murray, Mike Robinson, Richard Taylor and Doug Vogel provided useful comments or information.

References

[1] Allen, C., 1990. Definitions of groupware. Applied Groupware, 1, 1-2.

[2] Baecker, R., 1993. Readings in groupware and computer-supported cooperative work. San Mateo: Morgan Kaufmann.

[3] DeSanctis, G., and Gallupe, B., 1987. A foundation for the study of group decision support systems. Management Science, 33, 5, 589-609.

[4] Ensor, R., 1990 (Moderator). How can we make groupware practical? Proc. CHI'90. NY: ACM.

[5] Friedman, A.L., 1989. Computer systems development: History, organization and implementation. Chichester, UK: Wiley.

[6] Grudin, J., 1994. Groupware and social dynamics: Eight challenges for developers. Communications of the ACM, 37, 1, 92-105.

[7] Grudin, J. and Poltrock, S. (1991). Computer-supported cooperative work. CHI'91 Tutorial notes.

[8] Ishii, H., 1990. Cross-cultural communication and computer-supported cooperative work. Whole Earth Review, Winter, 1990.

[9] King, J., Ruhleder, K. & George, J. (1992). ODSS and the twilight of the decision support movement: Social segmentation and the legacy of infrastructure. Proc. 25th Hawaii International Conference on Systems Sciences, Vol. IV, pp. 472-481.

[10] Kling, R., 1991. Cooperation, coordination and control in computer-supported work. Communications of the ACM, 34, 12, 83-88.

[11] Kyng, M., 1991. Designing for cooperation: Cooperating in design. Communications of the ACM, 34, 12, 64-73.

[12] Malone, T. W. & Crowston, K. (in press). The interdisciplinary study of coordination. ACM Computing Surveys.