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.