Same topic in earlier issue
Previous article
SIGCHI Bulletin
Vol.29 No.2, April 1997
Next article
Same topic in later issue

Students: The Evolution of CSCW -- Past, Present and Future Developments

David Crow, Sara Parsowith and G. Bowden Wise

It has been just over ten years since the first conference on Computer Supported Cooperative Work (CSCW) in Austin, TX. The conference has addressed the technical, sociological, anthropological and policy issues for the development and deployment of workplace technologies. These include electronic mail, workflow, videoconferencing, decision support systems and collaboration over the Web. The student editors have set out to examine how CSCW has developed to where it is today and where it might be going in the future. To help answer these questions, we asked a number of prominent CSCW figures: Dr. Paul Dourish (of Apple Computer's Research Labs), Dr. Saul Greenberg (of the Department of Computer Science, University of Calgary), Dr. Jonathan Grudin (of the Department of Information and Computer Science, University of California, Irvine) and Dr. Yvonne Rogers (of the School of Cognitive and Computing Sciences, University of Sussex).

How has CSCW changed in the past 10 years?

Dourish: That's a pretty broad question it's changed in just about every way possible! I think the most important thing that's happened, though, is that it has begun to develop an identity as a discipline.

The people who came together when CSCW started did so with a fairly broad and loosely-articulated set of concerns. Ten years on, I think we have not only a better-articulated set of shared concerns and motivations, but also, more importantly, a set of understandings of how to go about the work, a body of established research which can be seen as being widely applicable and central to the concerns of CSCW, and a much better understanding of each other's perspectives. We've developed enough context to be able to talk to each other and to others. To say "I'm a CSCW researcher" actually means something today, to people both inside and outside the discipline, which it didn't ten years ago. In that regard, I'm glad that the CSCW conference has adopted the Doctoral Consortium program which CHI introduced a few years ago; perhaps more than anywhere else, the coherence of the discipline will emerge from the grad students.

Greenberg: To answer this, we should go back further than ten years. Many of the early pioneers in human computer interaction considered groupware capabilities as a fundamental part of their system visions. In the '40s, for example, Vannevar Bush foreshadowed both organizational memory and the World Wide Web in Memex [Bush45]. He saw hypertext as a way for people to share not only information, but the paths through the information that they considered valuable. In the '60s, Douglas Engelbart demonstrated NLS [Engelbart68], which contained a working version of what we now consider to be standard groupware applications: electronic mail, shared annotations, shared screens, telepointers, and audio/video conferencing. The '70s saw the wide-spread deployment of asynchronous groupware, such as email over the Arpanet, and threaded text conversations through conferencing systems and bulletin boards.

In spite of these visions and technical breakthroughs, there was no unifying field to bring these ideas together until 1986, the year of the first CSCW workshop in Austin, Texas. Just as HCI became a discipline in 1981 through the Gaithersburg HCI conference, so did CSCW create itself in that 1986 meeting. The workshop brought together people with shared interests from many areas, including computer science, sociology, psychology, anthropology and industry. I attended my first CSCW conference in 1988, and I still remember our excitement in discovering ourselves as a community, and our delight in seeing the sometimes quite different perspectives held by other attendees. That, I think, was the year when many people started calling themselves `CSCW researchers'.

CSCW has changed since then. It is a maturing discipline, with recognized experts, schools of thought, focused problem domains, a literature, and so on. We now have a solid base of knowledge to reflect on. Beginning with Irene Greif's collection of CSCW readings [Greif88], we have many books on both general and specialized topics in CSCW, proceedings of both the ACM and European CSCW conferences, as well as journals dedicated to the topic. Graduate students, the new generation of CSCW researchers, are pursuing theses in this area. They take for granted the existence of a field that didn't even have a name 10 years ago!

Grudin: For one thing it has coalesced into European and North American branches that have somewhat different, but overlapping, focuses. Participation from the MIS/IT discipline has shrunk. There is a greater recognition of the value of ethnographic studies. I think the most important change was seen at CSCW '96 [Ackerman96], where our research community demonstrated conclusively that it could make valuable contributions to extremely volatile but important areas including the Web, the Internet, workflow systems, and virtual worlds.

Rogers: I first came across the emerging field of CSCW 8 years ago when I was attending the first European conference on Information Technology for Organisational Systems (EURINFO '88) [Bullinger88]. I had just finished my PhD thesis and was on the look-out for new interests. In a packed room a workshop on CSCW was being held, where a large group of assorted people were discussing in earnest the very notions of collaboration and cooperation. There was a sense of excitement and togetherness: a feeling that a new paradigm for supporting people working together was being developed there and then. Since then, we have seen the field of CSCW develop from strength to strength. Now it is an established area of research and development, cumulating with over 600 attendees at the CSCW '96 conference [Ackerman96] in Boston this year, with an ever increasing diversity of areas of interest. For example, this year I was struck by the amount of interest and research in developing environments to support virtual communities for work and pleasure. In conjunction, the concept of awareness seemed to be the buzzword. A couple of years ago these were largely minority subjects. At that time everyone was talking Business Process Engineering and heralding Lotus Notes as the great groupware success story. Before that, other salient landmarks in the making of CSCW that come to mind include group decision support systems (GDSS), `the Coordinator', models of communication, collaborative writing, collaborative drawing, collaborative designing, videoconferencing and ethnographic studies especially of the London Underground and Air Traffic Control. Some may wonder whether this diversification of the subject area over such a short period of time is a good thing. In particular, lots of interesting topics and projects can fall by the wayside without having had time to mature. But given the rapid technological developments we have witnessed in the 90s it is inevitable. So long as there is enough research going on in conjunction with emerging technologies it can only be a good thing.

In your opinion, what work behaviors can CSCW support, and what work behaviors will probably not be supported by CSCW systems?

Dourish: "Work behaviour" is a moving target. I don't think you can talk about work behaviour outside of specific contexts, and the availability, functionality and reach of the technology is an important part of the context.

Take electronic mail, for example. It seems like a fairly simple idea to extend the file transfer facilities on a network to give a messaging service. The majority of the email which lands in my mailbox every day, though, is from mailing lists; an unanticipated use which completely changes the nature of what's going on. And just to add to the confusion, the work behaviours supported by those mailing lists are completely different, from information sharing, discussion, community building and so forth. Aside from the fact that they all come in by email and get handled by the same application, I think there's very little commonality between my workgroup's discussion list, the Babylon 5 fan list and the list for strange and interesting WWW sites. There simply isn't a direct relationship between systems and use patterns in that way. So, whatever work behaviours are supported by CSCW technologies in future, you can be fairly sure that they probably won't be the ones that the designers had in mind!

Greenberg: I'll take an extreme stance and say that CSCW should support everything that people can do through computers. However, I don't think this is a controversial view. With very few exceptions, all work (and play) is social. Most of the time, people's work is a fluid dance of individual and collaborative activity, flowing between individual efforts, coordination tasks, discussions, and full-on collaborations.

When you think about it, it would be ludicrous to give someone a job description that says "you will only work by yourself... you cannot talk to others or share your work with others". Yet somehow the technical constraints of computers have made this acceptable, where we think that groupware can be provided as an add-on feature and as a luxury. What is really going on is that it is still too hard for people to work together through their computers, because of the artificial constraints of technology, inadequate interface designs, and the poor integration of conventional software with groupware. We have to make the computer an affordance for working together. Most of today's groupware are heavyweight beasts that deter people from working together through the computer unless they absolutely have to.

Grudin: I think that computer technology can potentially support most activity, just as electric power can support most activities in some direct or indirect fashion. But of course the degree varies. In general, activities carried out with high frequency and relative uniformity are better candidates. For example, insurance claims processing is a better candidate than supporting software engineering processes, because the latter tend to be more idiosyncratic.

Rogers: Work behaviors sounds an odd term. I guess the concept of work practice is more widely used to describe what people do when they work. In this sense it all depends on the work context as to which `work behaviours' can be effectively supported by CSCW systems. Of course, there are certain technologies that have become ubiquitous in the majority of work settings, i.e. email and the WWW, and have become instrumental in supporting collaboration and dissemination of information. But for other kinds of work practices it is difficult to predict what CSCW systems will and will not support them. For example, studies of how people write together in different contexts show how their needs are quite different. Two academic researchers writing a paper together over a couple of months where one is in the States and the other is in Russia have a different set of needs to, say, an editor and reporter working to deadline to get a newsbreaking story out for the next issue of a newspaper. As such, the kinds of collaborative writing tools that have been developed with respect to the former may prove totally ineffective for the kinds of collaborations that go on in the latter setting.

There are many design methodologies used to help developers design user interfaces (user-centered design, cooperative design, participatory design, contextual design, are just some examples). Which methodology works well for designing CSCW systems? What do future design methodologies need to take into account in order to make the design of CSCW systems easier?

Dourish: I think methods are only a very partial solution to the problems we face. I always feel uncomfortable when it looks like the pursuit of one method or another seems to be getting in the way of actually getting the job done. Furthermore, there's a problem that specific methods or analytical orientations tend to focus very narrowly on small parts of the situation. For instance, I've been working with ethnomethodologists for a number of years, and I've found the orientation of that approach very useful and enlightening. But for me, the concern is not simply with how ethnomethodology (or any other approach) can reveal aspects of working practice, or generate requirements for the development of new CSCW systems. I'm much more concerned with how the model of social activity which ethnomethodology embodies carries significant consequences for the basic tools of computational design-for abstraction, identity, grouping or whatever.

I don't think that "CSCW applications" is a category on the same level as "work processors" or "presentation tools"; rather, support for collaboration constitutes a new way of thinking about and working with computer technology. That's the real challenge for design methods, if you want to think about it that way how to be wide enough in scope to encompass the range of elements in a computer-supported collaborative system, but still have something important, relevant and useful to say about all of them.

Greenberg: Now this is a question that can stimulate many PhD theses! In HCI, we not only have good methodologies for discovering system requirements and for evaluating interfaces, but we also have methodologies for doing them on the cheap. We don't have that yet in CSCW. Traditional ethnography, for example, is too expensive and hard to do for most CSCW designers, and only recently are we seeing ethnographic practices customized to fit the pragmatics of CSCW.

One problem is that understanding a group's work practice is inherently more difficult than understanding a single person's individual work. While we can get a good handle on stereotypical individual behaviors and requirements for conventional software design, these same people will relate to others in a groupware context in quite different ways, depending on their personalities, the dynamics of their group, the organizational structures, their politics. Consequently, current CSCW design methods are only good for two cases: generic shrink-wrapped groupware that are designed as simple communication channels (e.g., email, audio/video conferencing, shared displays), or for highly specialized settings where a team can design for very particular work practices and work cultures.

Testing groupware is also extremely difficult. In our own lab, we've been adapting usability observations to see how people converse through our groupware prototypes. The work involved is far more than traditional usability studies. Because we need at least two or more people for each observation scenario, we spend more time scheduling subjects and setting up equipment; we need more evaluators to observe each subject; and we spend more time analyzing the data. Rigorous experimentation is more costly. Judy and Gary Olson, who consistently perform some of the best quantifiable studies in CSCW, say it takes them about two years to test a single comparison. Extensive field studies on groupware deployment is even more difficult. For example, the UARC project is taking five years for their longitudinal study. To further confound the problem there are no agreed upon measurement metrics for deciding upon the success or failure of groupware. Researchers in video conferencing, for example, have been trying to discover a metric that somehow shows the value of these systems. Measuring the end work product often shows little difference, because people are incredibly resilient at working together through even the most limited groupware.

In the future, we need to develop low cost ways to uncover the design requirements of existing collaborative situations, as well as low cost methods for evaluating the groupware prototypes and systems we build. We also need good metrics and test situations that we can use to quantify performance changes when CSCW systems are introduced.

Grudin: Design methodologies have to match the circumstances. For example, commercial product development is different from a contract for a unique system. If the intent is to design several products in one application domain, an ethnographic study of the domain may be invaluable. For in-house development, participatory or cooperative design are especially useful. For commercial products, people with specific training in design has become more important. I am enthusiastic about Holtzblatt and Beyer's contextual design [Holtzblatt93a, Holtzblatt93b]. Of course, design is moving onto the Internet along with much else, with the huge emphasis on freely downloadable "beta versions" that customers try and respond to.

Rogers: All design methodologies have their merits and drawbacks. For example, user-centered design is good at focusing on users' needs but not necessarily on the contexts of use whilst participatory design is good at getting workers involved in the design process but is difficult to sustain throughout the whole development cycle. It is not a question of selecting one in favor of another. When deciding on how to proceed with developing a CSCW system, therefore, it is more useful to consider how to combine different methods to get maximum usefulness. For example, it can be really important to carry out a field (ethnographic) study in the first instance to understand the way current work practices work. From this understanding it can then be useful to carry out some preliminary brainstorming sessions involving participants using various `lo-fi' materials. Having evolved certain prototypes it can then be really valuable to go back out in the field and get the targeted people to try them out in the context of their work. And so on and so forth. The important question, therefore, is not whether contextual design works better than say, participatory design but to find ways of designing a CSCW system, that is appropriate for that given context. In my mind, the best way to learn how to do `good' design is through reading about case studies (i.e. how real design gets done) rather than trying to follow prescriptive cookbooks. Terry Winograd's new book, Bringing Design to Software [Winograd96], is an excellent example of this approach. A range of designers have been invited to write earnestly and informally about how they go about designing systems. Highly recommended.

With respect to the second question what should future design methodologies take into account to make the design of CSCW systems easier my response is: design was never easy and never will be. What they should always take into account are the contexts of use. This requires considerable time understanding the various settings/markets/niches be they home, school, work or entertainment for which the systems are being developed for. I am a great believer in really getting to grips with what, who and why you are designing a new system for. Maybe in the short term this is an expensive approach, but in the long term it may have better pay-offs.

Computers have not eliminated the need for paper in many offices. By making computing social with collaborative technologies have we eliminated the need for paper?

Dourish: Definitely not, and I don't think it's even a sensible goal. I think what we've learned is to be sensitive to the variety of means by which people accomplish their work, and the interplay of multiple interaction modalities (telephone, electronic mail, physical environments, video, face-to-face interaction, etc.) is a critical factor. The question isn't how computers can displace other forms of interaction; it's how computer systems can be designed which mesh into the fluid and disparate environments of work.

I'm sitting writing this at home today, on my computer, and this interaction has all been handled electronically. On the other hand, I've just finished installing and setting up a critical collaborative technology a new printer. I don't see any contradiction in that.

This same feature was true of the work we did on media spaces. People used to visit and ask, "So, do you find you don't go to each other's offices so much any more?" The answer was that of course we did; the media space provided a new and different channel for other sorts of interactions, increasing both the opportunities and the range of interactive possibilities. The electronic document which I'm writing just now and will send you over the Internet will reach most people in a paper form; the computer has changed the nature and increased the range of things we can do with paper.

Greenberg: The paperless office is not only a myth, but is an unrealistic and inappropriate goal. With conventional computers, for example, paper use has gone up, not down. What has changed is how paper is used. While paper was traditionally the way archival material was stored, paper in computer-based offices is now used for throw-away printouts that can be read and referenced on the spot. With collaborative technologies, such as coordination and workflow systems, we will see the computer take a greater responsibility in maintaining the flow structures and archives normally done by paper. This will not stop people from printing out their own local copies for quick reference, for their own paper records, or just because it is easier to read.

The real challenge is not in eliminating paper, but in removing the seam between our paper and computer world. This is already happening. On the technically mundane level, we should see the fax machine as the success story in groupware simply because it is based on preserving paper, with its digital communication aspects seamlessly hidden from view. There are some lovely technical breakthroughs that are eliminating the seam between digital and paper documents. Hiroshi Ishii, for example, merges paper and computer display in his ClearBoard conferencing system [Ishii92], where hand gestures, computer artifacts, and tabletop are overlaid to create one shared work surface. Pierre Wellner's digital desk [Newman92] takes this a step further by allowing people to interact with paper documents in ways normally reserved for digital documents. Xerox is also working on making paper computer-aware, in order to bring the best properties of both paper and computer together.

Grudin: We've eliminated some uses of paper and created new ones.

Rogers: No way. The very idea of a paperless office has always been absurd. Most kinds of collaborative work involve pushing bits of paper around from one person to another. There are good reasons for this and rather than try to eliminate it we should be seeking better ways of supporting it. For example, in a recent field study [Bellotti97], Victoria Bellotti and myself carried out of the changing face of the publishing industry, we noticed in a number of high tech web-based publishing sites how there was increasing evidence of these organisations `turning technology inside out'. By this we mean the physical re-representation of online material, such as electronic schedules, shared calendars and files, because the online material is simply not getting through. For example, every morning a project coordinator would write up on a physical whiteboard the main projects, schedules and deadlines relevant for that day which she had extracted from the online project management software package. When asked why she laboriously wrote up by hand information that could be readily accessed by everyone on the network, she replied that owing to the multiplication of projects and people working on them it had become very difficult to keep track of everything that was going on. Moreover people had become desensitized to the many email reminders that such software applications provide, so they often forgot the significance immediately after having acknowledged them. Having the information available on a whiteboard in a prominent public space provided a much more effective way of reminding what was urgent and needed doing that day.

These kinds of observations, therefore, suggest that we should be focusing on not how to eliminate paper but how better to support the integration of different kinds of physical and electronic representations, using a variety of interconnected collaborative technologies.

How can the WWW be adapted to successfully support real-time collaborative work?

Dourish: The value of the Web isn't access (we already had that), or rich text (we had that too); the value is that it's an integrative technology. The design of the WWW protocols and functionality say nothing about supporting streaming audio, or video segments, but I have those when I browse the Web because WWW technologies provide the framework which can integrate RealAudio or QuickTime. It's very frustrating to see the media confuse the Web with the Internet. The point of the Internet is the diversity of applications which can be supported there; not just telnet, ftp and email, but then http and nntp (neither of which existed when I started using the Internet), and shared drawing tools, Portholes or all sorts of other things. We don't look for one of these things to solve all our problems; the value lies in bringing them all together.

So I think that we already have the elements in place for supporting real-time collaboration. We have the tools a brief perusal of any set of CSCW proceedings will produce all sorts of real-time collaborative tools which are useful in one circumstance or other and what we have in the Web is an integrative framework which can help us bring them all together. I think it would be a real mistake to start thinking in terms of changes to WWW to support real-time collaboration. Instead, we need to think about what range of tools we can bring together in that framework to enrich the experience of using the Web.

Greenberg: Computers contain many obstacles to collaboration, and the WWW is no exception. But first, let's look at the ways computers have evolved to understand why the Web is just a stepping stone to collaborative work. In the '60s, time-sharing systems allowed many people to work on a single computer. Yet these systems went to great lengths to give each user the illusion that he or she was the only person working on the shared computer. Collaboration was possible only through add-on software. The World Wide Web has removed one of the obstacles to collaboration on computers by giving users the means to contribute and to share information across what looks like a single large filing system. This is still a way from true collaborative systems. For example, standard Web browsers are still single user tools that partition one person from another. They offer no direct support for a group of people to contact each other and to engage in conversation over that information. The last year has seen some changes, with both research and commercial conferencing products being supplied as browser add-ons. The novelty and hype behind these Web products have made the public excited about having poor quality audio conversations over impoverished shared visual work surfaces. In practice, these systems have many problems. There is no real standard for connectivity and communication (or perhaps there are too many standards!); making contact with others is heavy-weight; security issues have not yet been solved; bandwidth and latency limitations are a real consideration for the majority of potential users; and performance is pathetic. I'm certain that these and other difficulties will be solved, but it's still not clear how it will happen. I suspect, at a minimum, that we will need commercial web browsers with built in groupware capabilities, and some kind of HTML or Java standard that will make groupware connections easy to create and useful groupware applets easy to build and maintain. We will also need unifying metaphors to make all these systems accessible to the public.

Grudin: Getting a higher bandwidth infrastructure would be a start... Although there will be a need to support real-time collaboration in many circumstances, the Internet may reduce the need for real-time interaction in many areas.

Rogers: It seems as if people have already been adapting the WWW to support a variety of real-time collaborations. For example, we have seen over the last few years the successful emergence of a range of virtual communities, intranets and other real-time environments supported by the infrastructure of the Internet. Innovative research done at the Knowledge Media Institute at the Open University (UK) [KMI] has also shown how it is possible to develop forums to reach out to hundreds of thousands of people in real time.

What might the future hold for CSCW? Where do you see CSCW in seven years?

Dourish: I'm very bad at predicting the future; the most interesting things I've found in research have always been the unexpected ones. What we have right now is the convergence of two very important threads. First, we have a developing set of understandings about the role of technology in everyday experience (not just collaborative work, but all sorts of other realms of social experience). Second, technical developments (especially the Internet explosion) mean that the power of our computers and the reach of our networks extend far beyond what any of us might have imagined ten years ago. What's strikingly clear is that we've not been very good at putting these together, and that has to be an important goal. That's not simply intellectual work, but also a question of getting out there and just doing it.

There's one very good sign, though. Pick up an Internet magazine, or turn on your radio or television what do people say about the Internet? Why are people joining it? People are most definitely not doing the things which the Internet was originally designed to do moving large volumes of data around, getting remote access to supercomputer facilities, or whatever. Instead, they're talking to each other on newsgroups and in chat rooms, and setting up network places for joint activity. They're not connecting to other computers, but to other people. For us, that's both the challenge and the opportunity.

Greenberg: I would like to see the term "groupware" disappear from use, simply because every system will be groupware. Single user systems will just be groupware with only one person present. Our major operating systems (Unix, Mac, Windows) should have groupware primitives built into them at their lowest levels, so groupware comes for free. Shrink-wrap software should be delivered as groupware there is no reason why I should use one word processor for my own work, and a different one if I want to show what I am doing to a colleague. At the same time, CSCW as a discipline should gain in prominence and importance. As with HCI, the next decade in CSCW will herald more knowledge about how people work together both with and without technology, and will introduce practical methods for evaluating systems as they are being developed. Perhaps CSCW and HCI will merge together, but it will be because CSCW will become a part of interface and cannot be considered as a separate thing.

In terms of societal impact of CSCW, I would like to think that groupware and CSCW will create a more open and democratic society. At the same time, I am worried about the dark side of technology. The best design intentions and systems can be subverted to make groupware a method by which those in power can keep tabs over those without the power. Democratization of technology, as we are now seeing on the Web, also means easy deployment of things that we as a society don't like. Because technology can mask identity and use, I can see people subverting it to send hate mail, to spy on others, to probe and even alter private information, to harass, to take advantage. Commercial leveraging of collaborative technology may mean that our lives become even more inundated with advertisements and other info-junk, as also seen on the Web. Ironically, groupware can also reduce real world social contact by letting people hide behind their computers, as Sherry Turkle saw in some people's excessive dependencies on MUDs [Turkle96].

In the next seven years, I would like to see more CSCW research on understanding societal impacts of technology, and how its adverse effects can be mitigated. I want to see groupware systems being deployed as something that will bring out our best, rather than our worse, cultural features. The potential for good is enormous, but so are the risks. The only certainty is that collaborative technology will happen.

Grudin: Well, if I had tried answering this question in 1990 I would look silly now. But I think we will be coming to grips with the fact that many of us really will be in a global village. I grew up in a village, and villages have their good points and their bad points.

Rogers: That will be the year 2004. It is difficult to say, given the rapid evolution of enabling technologies and the diversity of topics that are being researched under the umbrella of CSCW. Instead I can only say what I would like to happen. Firstly, in terms of the community, it would be nice to see the field becoming better integrated; in particular, it would be good if the so-called `techie' vs `social' divide became less of a thorny issue, such that social scientists were able to get to grips better with the capabilities of technology and system developers could develop a better understanding of the social and cognitive issues. Such a trend is already happening but I think there could be some exciting developments if there was more of it. Secondly, I would like to see more theoretical developments in the field. Talking to a couple of the student volunteers at the CSCW conference this year made me realize how instrumental it is to have a seminal theoretical grounding when learning about the field. For us who were students back in the 80s, the two books that got us thinking about the key conceptual concerns for the field, were by Lucy Suchman [Suchman87] and Terry Winograd and Fernando Flores [Winograd86]. For the students of the 90s, Ed Hutchins book Cognition in the Wild [Hutchins95] seems to be the talking point. It would be great to see another seminal, insightful theoretical text to come out at the beginning of the next century. Thirdly, it would be great to see people putting to good use some of the technologies that are currently being developed today. In particular, I look forward to seeing how mobile, personal and ubiquitous computing technologies will be realized in a variety of settings.

Summary and Conclusion

CSCW is a continually evolving subject area which has developed substantially in the last ten years as a discipline in its own right. Current `trends' appear to be concerned with virtual communities and awareness issues. It has been proposed that CSCW should attempt to support all activities that people can carry out using computers due to the social nature of work and play. The development of adequate CSCW methodologies is problematic; they need to be less expensive than at present while still encompassing all the elements of a social system. The notion that we should strive for a paper-free office has been dismissed. By understanding how people work alone and in groups we can develop new technologies for integration within the natural work environment. The WWW provides a framework that brings together many existing and new technologies to support real-time collaboration. Today there exist bandwidth and latency shortcomings but this is likely to improve with time; the WWW is a step towards a large distributed file system that can support collaborative work. It is hoped that CSCW research will become even more integrated in the future by further reducing divisions between the social and the technical aspects of the subject.

The responses have provoked the desire for further discussion we invite interested readers to post their comments to the mailing list for continued debate on the subject!

The Authors wish to thank all participants for their time and effort in answering these questions.


[Ackerman96] Ackerman, M.S. (Ed.). Proceedings of ACM CSCW '96 Conference on Computer-Supported Cooperative Work. ACM Press/Addison-Wesley, New York City, NY, 1996.

[Bellotti97] Bellotti, V. and Rogers, Y. "From Web Press to Web Pressure: Multimedia Representations and Multimedia Publishing". To appear in Proceedings of ACM CHI 97 Conference on Human Factors in Computing Systems, Atlanta, Georgia, USA, March 2227, 1997.

[Bullinger88] Bullinger, H. J., Protonotarios, C. N., Bouwhuis, D.,and Reim, F. In Proceedings of EUROINFO'88 First European Conference on Information Technology for Organisational Systems, North-Holland, Amsterdam, 1988.

[Bush45] Bush, V. "As We May Think". Atlantic Monthly, 176(1), pp. 101108, June, 1945. Reprinted in [Greif88].

[Engelbart68] Engelbart, D. and English, W. "A Research Center for Augmenting Human Intellect". In Proceedings of the Fall Joint Computing Conference, Volume 33, pp. 395410, Montvale, NY, AFIPS Press, 1968. Reprinted in [Greif88].

[Greif88] Greif, I. Computer-Supported Cooperative Work: A Book of Readings, Morgan Kaufmann Publishers Inc., San Mateo, California, 1988.

[Holtzblatt93a] Holtzblatt, K. and Beyer, H. "Making customer-centered design work for teams". Communications of the ACM, 36(10), 92103, 1993.

[Holtzblatt93b] Holtzblatt, K. and Jones, S. "Contextual inquiry: A participatory technique for system design". In D. Schuler and A. Namioka (Eds.), Participatory design: Principles and practices. Hillsdale, NJ: Lawrence Erlbaum Associates, 1993.

[Hutchins95] Hutchins, E. Cognition in the Wild. MIT Press, Cambridge, MA, 1995.

[Ishii92] Ishii, H. and Kobayashi, M. "ClearBoard: A Seamless Medium for Shared Drawing and Conversation with Eye Contact". In ACMCHI '92 Conference on Human Factors in Computing Systems, pp. 525532, Monterey, California, May 3-7, ACM Press, 1992.

[KMI] Knowledge Media Institute. For more information about KMi Stadium please visit

[Newman92] Newman, W. and Wellner, P. "A Desk Supporting Computer-Based Interaction with Paper Documents". In Proceedings of ACM CHI '92 Conference on Human Factors in Computing Systems, 587592, ACM Press, 1992.

[Suchman87] Suchman, L. Plans and Situated Actions: The Problem of Human-Computer Communication. Cambridge University Press, New York, 1987.

[Turkle96] Turkle, S. Life on the Screen: Identity in the Age of the Internet. Simon & Schuster, 1996.

[Winograd86] Winograd, T. and Flores, F. Understanding Computers and Cognition. Ablex, Norwood, 1986.

[Winograd96] Winograd, T. Bringing Design to Software. ACM Press/Addison-Wesley, New York, 1996.

About the Participants

Paul Dourish is a senior research scientist at Apple Research Labs in Cupertino, California. Before arriving at Apple in 1996, he spent seven years at the Rank Xerox Research Centre (formerly EuroPARC) in Cambridge, England, latterly dividing time between there, Xerox PARC and University College, London. His work in CSCW began while at EuroPARC, where he worked on developing and studying systems such as the RAVE media space, the Portholes distributed awareness service and the Prospero CSCW toolkit. Before that, he worked on parallel programming language design (he's been a member of SIGPLAN for much longer than SIGCHI). At Apple, his work concerns how studies of work practice and interaction affect not just the way in which we go about designing new technology, but the basic nature of interactive technology itself. He can be reached at:

Saul Greenberg is an Associate Professor of Computer Science at the University of Calgary, Canada. He first became interested in CSCW in 1988, when it became the focus of his post-doctoral work at the Alberta Research Council. Since then, he and his GroupLab team have published many papers in HCI and CSCW. Their novel software includes GroupKit (a groupware toolkit), the soon to be renamed TeamRooms (a groupware delivery platform designed around a room-based metaphor), and prototype systems that illustrate how awareness of other's activities can be supported over distance. He is also the author and editor of four books, two concentrating on CSCW: Computer Supported Cooperative Work and Groupware (Academic Press, 1992), and Groupware for Real Time Drawing (McGraw Hill Europe, 1995). He can be reached at:

Jonathan Grudin is an Associate Professor at the University of California, Irvine. He received a BA in Mathematics-Physics from Reed College and an MS in Mathematics from Purdue University, then worked as a programmer before earning a Ph.D. in Cognitive Psychology at UCSD with Don Norman. He has worked as a postdoc at the MRC Applied Psychology Unit, collaborating with Phil Barnard and Allen MacLean. Dr. Grudin has worked as a Software Engineer at Wang Laboratories primarily in the User Interface group and as a researcher in the Human Interface Laboratory at MCC. Most recently he taught at Aarhus University in Denmark before taking his current position in the Computers, Organizations, Policy and Society (CORPS) group of the Information and Computer Science Department at the University of California, Irvine. He can be reached at:

Yvonne Rogers is an Associate Professor in the School of Cognitive and Computing Sciences at Sussex University in the UK, where she teaches CSCW, HCI and Cognitive Science. Her research in CSCW began after completing her PhD, when she became frustrated with the single user information processing paradigm that had dominated HCI research. In 1991 she spent 6 months at UCSD as a visiting scholar and worked with Ed Hutchins in the Distributed Cognition Lab. Since then she has carried out a number of field studies, trying to understand and explain a variety of collaborative work practices. This year she was a visiting professor at Stanford University and Apple Research Labs where she was involved in designing future collaborative technologies. She may be reached at:

About the Authors

David Crow is a masters student in the Human Computer Interaction Institute at Carnegie Mellon University, Pittsburgh, PA. He is interested in user centered design as a business practice and designing for special populations. He can be reached at:

Sara Parsowith is a doctoral student at the Cognitive & Computing Sciences Graduate Research Centre, University of Sussex, Brighton, England. Her research is concerned with the WWW as an enabling technology for synchronous collaborative work. She can be reached at:

G. Bowden Wise is a doctoral student in the Department of Computer Science at Rensselaer Polytechnic Institute, in Troy, NY, USA, where he is doing research on multimodal interfaces. He can be reached at:

Same topic in earlier issue
Previous article
SIGCHI Bulletin
Vol.29 No.2, April 1997
Next article
Same topic in later issue