MOTIVATION: WHY COLLABORATION AND
COMMUNICATION?

Two trends related to collaboration and communication are fostering useful new conceptions of human-computer interfaces. First, evolving theories of interpersonal collaboration and communication are beginning to be applied to human-machine interactions, demonstrating that thinking about human-machine interactions as communication and dialogue—rather than, for example, a series of isolated commands and responses—can make systems easier to use. Second, the increasing use of computer systems in support of communication and collaboration among groups of people (whether for work, education, or entertainment) highlights the need for understanding interfaces as links among many people and machines, not just one person and one machine. In both of these arenas, better understanding and development of richer theories of collaboration and communication will lead to improvements in the ways people use the national information infrastructure (NII), whether to interact with the NII itself (e.g., to obtain information and services) or to interact via the NII with other people in order to communicate, collaborate, and form communities.

For an individual using a computer system, as Candace Sidner says in her paper in this volume, "interfaces are 'communication engines' to the functionality of software applications; interfaces are how we get our work done." Yet the word "interfaces" suggests a thin veneer (according to the dictionary, "a surface forming a common boundary"), too thin to provide the capabilities for communication and support that people should be getting from computer systems. Most members of the human-computer interface community take the "I" to refer instead to "interaction," but the ability to collaborate ("work with") and not just interact ("act on one another") is becoming increasingly important as people use the NII not just to get individual tasks done, but also to communicate and work with others.

As explained in Chapter 2, the NII's growth is extending civic life and community to include geographically dispersed individuals. It is thus important to expand the conventional conceptualization of interfaces by recognizing that they may involve more than one person and machine and that collaborative systems can either alleviate or exacerbate problems in interactions among individuals with different abilities. As explained by Terry Winograd in his position paper in this volume, the traditional idea of "interface" implies a focus on the person and the machine. In designing interfaces it is important to focus as well on the "interspace" that is inhabited by multiple people and machines in a complex web of interactions. The expanded view this interspace implies adds to—but does not replace—the conventional requirements of interfaces for facilitating communication between person and machine.

With anticipated enhancements in capabilities and reach, the NII may also foster new kinds of collaborations. Recent work on "collaboratories" (Olson et al., 1992) and distance learning over the Web and in multiuser domains (MUDs; Bobrow, 1996) as well as the extensive use that the astronomy and high-energy physics communities make of the Web for large-scale scientific experiments involving widely dispersed people, instruments, and data provide examples of collaborations made possible by networked systems. Graphical interfaces enabling easy access to hyper-linked Web-based documents, for example, have made it much easier for dispersed researchers to share new results, articles, and references within their community than when they had to mail, fax, e-mail, or personally deliver articles to one another. The NII has the similar potential to provide new ways of conducting a range of activities important to every citizen. In health care, for example, there is an increasing emphasis on the construction of large patient care systems that coordinate multiple providers from multiple disciplines and care sites. Network information systems offer the opportunity for new kinds of communication and collaboration and the potential for integrating practices and providers across communities. With the proper support for collaboration and communication, electronic information systems could play a key role in meeting the associated challenges of integrating health care practices, providers, and settings from individuals and families across communities (and individuals with different sensory and cognitive abilities).

The ever-increasing modes of communication and media in which to present information provided by current technology also complicate and enrich the interface challenge. Going beyond a shallow view of interfaces to consider communication and collaboration becomes even more important when we consider combining video, voice, and graphics. Computer systems have become more than machines used to perform isolated tasks. They are now widely used as machines for communicating different kinds of information using a range of media, and they provide possibilities for structuring and interacting that were unavailable previously (traditional print, graphic, and broadcast media). Decisions about what form to use to communicate different kinds of information and techniques for combining different media will require this larger view. There is a wide range of difficult technical problems in making such decisions (Feiner and McKeown, 1991; Roth et al., 1994; Moore et al., 1995; Marks, 1991).

In the resulting complex web of interactions, people's needs for systems to support collaborative activities and to act collaboratively will vary by individual, activity, and situation of use. Thus, it is important to emphasize that this chapter argues not that collaboration is the only type of interaction, but rather that it is an essential element of any system for communication (whether that communication is itself in service of cooperation or, alternatively, competition) and that it is important for the NII to provide support for collaborative activities.

Thus, communication and collaboration affect the design of every-citizen interfaces (ECIs) in two arenas: (1) person-computer interactions (e.g., ECIs may be designed to collaborate with a person) and (2) person-person interactions (e.g., ECIs can provide new ways for people to communicate with one another and support collaboration among groups of people). The former type of support is reflected in software (including interfaces) that applies our theoretical understanding of some aspects of human communication and collaboration to improve people's experiences in working with computer applications. The latter involves software (including interfaces) that facilitates communication among people and collaboration among groups. However, it is important to recognize that for many uses of the NII people may utilize both these types of collaborative support (person-computer and person-person) as several examples in Loren Terveen's position paper (in this volume) illustrate. Identifying optimal ways to integrate the two types of support in ECIs is a major research challenge.

The roles of theories of collaboration and communication differ across these arenas, but the value of a better understanding of what constitutes collaboration and what is needed for effective communication is essential to both of them. For example, the need to have certain capabilities to be able to collaborate on a task or the requirement that particular kinds of information be shared among participants in a collaborative activity affects the design of support tools for group collaborations (e.g., systems like Lotus Notes) as well as the development of interfaces that enable a person and application to work together more collaboratively than most current interfaces. This chapter investigates each of these arenas separately to understand the challenges and opportunities each presents. The recommendations encompass research that will contribute to both arenas as well as research focused on arena-specific needs.




THE NATURE OF COLLABORATION: CRITICAL
FEATURES AND CAPABILITIES

Collaboration entails working together toward a common purpose, although the reasons for the collaboration and the ways in which it fits into some larger activity may vary among the participants (Bratman, 1992; Grosz and Kraus, 1996; Searle, 1990). For instance, some authors of a multiauthored report may contribute because the report offers a vehicle for wide dissemination of their ideas, others because they believe the report may help meet a societal need of great concern to them.

Workshop participants generally agreed on the importance of research aimed at answering fundamental questions about the nature of collaboration and its role in ECIs, both for improving the ways in which people and computers interact—the person-computer collaboration arena—and for supporting communication and collaboration among groups of people. However, different specific questions are highlighted by different research communities. Research in artificial intelligence, and computer science more broadly, addresses questions of formalizing the information that must be exchanged (Cohen and Levesque, 1990; Grosz and Kraus, 1996; Kinny et al., 1994), developing negotiation strategies and protocols for reaching agreement on how to divide work (Rosenschein and Zlotkin, 1994; Kraus and Wilkenfeld, 1993) developing languages for communicating or negotiating such information (Sidner, 1994a,b), and measuring the difference in theoretical power or system performance made by adding collaborative capabilities (Bender and Slonim, 1994; Jennings, 1995). Analyses within the paradigms of sociology, organizational behavior, and anthropology examine the ways in which groups function. This diversity makes clear the need for interdisciplinary efforts as we examine the introduction of collaborative capabilities into ECIs.

Appropriately defining the capabilities that systems need and the functionality that can be expected from them as well as developing ways to design collaboration at different levels into systems are major research challenges. From recent research on the modeling of collaboration, it is clear that knowledge about what is being done (the collaborative activity and the goals to which it relates), how to do it, and the capabilities of the participants is essential (Grosz and Kraus, 1996). As a result, for a system to be a collaborator, it needs to "know" what the person using it is trying to do. This knowledge may be implicit in the system design rather than explicit, but it cannot be absent. Another feature of collaboration is the need for participants to negotiate (Sidner, 1994a,b; and others). Negotiation about terms ("semantic alignment"; see below), about means, and about allocation of responsibility are among the ways in which collaboration entails negotiation. Collaboration also requires that participants share both commitment to the common task and knowledge of their shared commitment (see, e.g., Bratman, 1992; Searle, 1990; Grosz and Kraus, 1996; Levesque et al., 1990; Kinny et al., 1994). Establishing the commitments and requisite common beliefs requires communication, but here too the extent to which this information must be explicitly represented by a system and thus the communication requirements may vary.

In examining the possibilities for person-computer collaboration, there was a divergence of opinion among workshop participants about how much collaborative power one should seek to incorporate into ECIs in the near term and more generally how "smart" they might be. Likewise, there was debate about the level at which systems would need to negotiate. For instance, Candace Sidner argued that all collaborators—human and machine—must be "aware of what the task is," with common knowledge about their shared undertaking. Austin Henderson argued that requiring more than minimal ability on the part of systems to understand what people using them are doing sets too high a barrier; he suggested seeking to develop systems that have some knowledge of what they are doing themselves, but not requiring that they understand what a user's purposes are. As he stated, "Maybe it doesn't understand what you are doing, but it surely understands what it is doing in its terms and can talk about those." In his paper (available on-line at http://www2.nas.edu/CSTBWEB), Gary Olson provides some support for the view that machines cannot be expected to meet a human standard by observing that groups of people develop unconscious routines that are hard to specify and therefore hard to represent in a computer system.

Although formal models of collaboration (e.g., Grosz and Kraus, 1996; Flores et al., 1988; Winograd, 1988) make reference to beliefs and intentions, computer systems do not necessarily have to reason explicitly about such mental constructs to behave collaboratively. Ants and other insects have built-in behaviors that lead to their working together (Wilson, 1971). Computer systems that are restricted to specific tasks could incorporate principles of collaboration into their design and work collaboratively without explicitly reasoning about belief or intention. For instance, interfaces can embed task and knowledge implicitly; in effect, automated teller machines (ATMs) do this. Thus, the incorporation of collaborative capabilities does not necessarily entail a requirement that a system have complex reasoning capabilities.

It is useful to consider computer systems falling on a spectrum from very function specific (e.g., ATMs, financial software applications such as Quicken) to general purpose (e.g., personal computers, database systems). People using large-scale information systems will employ systems at all points along this spectrum, and systems across the full spectrum should have capabilities for collaborating. The problems presented by communication and collaboration in general-purpose systems are long term; they entail many of the difficult problems of representation and reasoning that research in artificial intelligence has been addressing. However, the incorporation of capabilities for collaboration into systems for human-computer communication does not have to wait. Models of collaboration can be used to constrain and affect the design of function-specific systems (e.g., Rich and Sidner, 1996). Embodying a set of assumptions into the design of an interface for a function-specific system in the form of a familiar metaphor (e.g., the checkbook-balancing metaphor in Quicken) provides another avenue for incorporating some level of collaboration into a system. Organizing an interface around a particular task domain and cognitive principles related to performing that task (e.g., GLIDE¹) is another.

The function-specific approach is not, however, an application-specific approach, and misidentifying these two may sacrifice the benefits of consistency in interfaces for different tasks. ECIs must support people's interaction with multiple applications packages when using the NII. As Candace Sidner notes in her paper in this volume, no single interface metaphor is powerful enough for all work, yet a multiplicity of smaller applications, each with its own interface for performing one set of tasks, leaves people with lots of tasks to juggle and creates a need for an interface that communicates and collaborates in terms of the task rather than the application.

It is also important not to confuse collaborative systems with help systems. Systems that have collaborative capabilities should prove helpful, but "help" systems may operate without information that is crucial to collaboration. For example, some current help systems not only offer advice but also take action to help with one's task (e.g., Apple Guide, Microsoft Wizards). These systems exhibit properties of collaboration (e.g., doing things to assist in the user's task without being asked). However, at the workshop, Sidner argued that such systems do not measure up to what is required for collaboration because the missing consensus that collaborators share is critical. For instance, systems with features such as automatic spelling correction are helpful when they get things right, but because they lack knowledge of the task, they can also cause serious problems. One of the lessons of Microsoft's commercially unsuccessful "Bob," which proved not to be as helpful as expected, may be the difficulty of attempting collaboration without adequate built-in models of collaboration.²

Collaboration also requires some shared knowledge about the activity or task being done. Because current help systems often lack such information, they are unable to address some critical problems that arise for users. They do well to provide users with additional uncontextualized information (e.g., Microsoft Word's "Tip of the Day," which acquaints users with an arbitrary piece of functionality), and they are able to help users find functionality in cases where users are able to identify their information needs precisely. New generations of help systems are needed, ones that are able to analyze what users are doing and complement information access with information delivery by providing contextualized information that is relevant to the task at hand (Fischer and Nakakoji, 1991). The active help systems currently being explored in research settings (e.g., Fischer et al., 1985) provide examples of such systems.

A major challenge for research on collaborative systems is finding the appropriate level of collaborative capability for a given application. Determining the tradeoffs undoubtedly will require the kinds of iterated design processes described in Chapter 4. A general solution is not likely to be found; one person's ideal level of query may not be another's, and one individual's preferences may vary among tasks. Thus, people's expectations and the qualities they attribute to systems must be taken into account.

An additional risk is that people may attribute greater capabilities to systems that appear to collaborate than those systems that actually have. As Olson observed at the workshop, "People really have a tendency to impute animisms to complicated technical devices, so in the situation of using it, it sure feels like a collaboration even if we, as disembodied researchers, can say it isn't." Lee Sproull noted at the workshop that the ongoing relationship built up in collaborations among people is an important nontask component of their activity. If users impute collaborative abilities to systems, various social aspects of collaborations need to be attended to (Nass and Reeves, 1996). The section "Developing Trust in Systems" below examines several of these.³




Semantic Alignment

The ability to communicate clearly with people is a requirement for ECIs. Clear communication requires a shared understanding of the meaning of terms; this understanding is known as semantic alignment (Clark, 1996). ECIs need to accommodate shifts in terminology, not only for people and systems, but also for the multiple systems that may need to be coordinated in a single interaction. At the workshop, Austin Henderson observed that in "all of these situations we have to address the question of how it is that collaborating entities negotiate meaning."⁴

As explained by Terry Winograd in his paper in this volume,

Whenever two people talk, they have only an approximate understanding of each other. When they speak the same language, share intellectual assumptions, and have common backgrounds and training, the alignment may be quite close. As these diverge, there is an increasing need to put effort into constant calibration and readjusting of interpretations. Ordinary language freezes meanings into words and phrases, which then can be "misinterpreted" (or at least differently interpreted). This problem shows up at every level of computer systems, whenever information is being represented in a well-specified syntax and vocabulary.
. . . Even simple databases have this problem. If information is being shared between two company databases that have a table for "employee," they are apparently in alignment. But if one was created for facilities planning and the other for tax accounting, they may not agree on the status of part-time, off-site, on-site contract, or other such "employees."

Henderson argued that collaborating entities "start from undefined positions but a common context, and they produce enough alignment for the purposes at hand."

If a computer system is one of the communicating parties, it must participate in establishing the common ground (Clark, 1996). Many current systems work under the presumption that people will learn the system's meaning, but this assumption is a source of misinterpretation and people's difficulties in understanding how to use systems. As wider cross-sections of society use the NII, such assumptions may become untenable.

As Terry Winograd observes in his paper in this volume,

Ubiquitous networking is leading us to the point where every computer system supports communication and where every term we use will be seen and hence interpreted by others. There are traditional philosophical and linguistic approaches to making sure we have "common understanding," but these tend to be based on highly abstract or idealized examples and settings. We need to develop new theoretical foundations for talking about the kinds of "semantic approximations" that are needed for something as apparently simple as sharing data between two databases and as ubiquitous as the nodes of the Internet.

At the workshop, Craig Knoblock argued that the problem is not one that can be solved simply by imposing standards: "There is going to have to be some kind of distributed solution.... [Systems] have to change their model and update things. So there has to be enough information in the underlying structure that it is easy to make those changes. But there is no way that you can anticipate all those changes." Moreover, once obtained, semantic alignment can be undermined over time; this is the well-known problem of semantic drift.




COLLABORATION AND COMMUNICATION

Improving an Individual's Interaction:
Person-Computer Collaboration and Communication

The interface is the "face" that meets a person (individual user) who is interacting with the NII. Better systems for human-computer communication are essential if we are to have easy-to-use, large-scale information systems—systems that every citizen can use. If we compare current capabilities for human-machine communication to the ways in which people communicate with one another, it is apparent that current interfaces are severely limited. The example in Chapter 4 of telephone menu confusion problems is evidence of the gulf between person-person communication and person-computer communication. Even more telling is Andries van Dam's table-setting analogy.⁵ Bruce Tognazzini's equating of mouse clicks with grunts sheds light on the relative illiteracy of current interfaces, suggesting that direct manipulation interfaces hearken back to the days before language (other than grunting) was used for communication.⁶

Communication and collaboration are interdependent: communication requires collaboration (Grosz and Sidner, 1990; Nass and Reeves, 1996; see also Brown and Duguid, 1992), and collaboration requires communication, though not necessarily linguistic communication, as Terveen's investigations of ways to organize collaboration around shared manipulation of work materials illustrate.

In his position paper in this volume, Terry Winograd notes that people use three primary modes of interacting with others and their environment: manipulation (e.g., grasping, modifying, controlling objects), locomotion, and conversation. Each of these modes of acting must be coordinated with ways of perceiving: we manipulate objects within sight and grasp, sense in various ways as we move among locations, and listen as well as talk when we converse. Direct manipulation interfaces are rooted in the first of these modes, Web travel (and many games) in the second.

Conversations among people have features that have not been captured in either of these classes of interfaces or in the more (human) language-like command-line and query language interfaces. In her paper in this volume, Candace Sidner argues, with reference to research in natural-language dialogue processing, that our conversations are themselves collaborative activities (Lockbaum, 1994, 1995; Stein and Maier, 1995; Nass and Reeves, 1996; Clark, 1996; Clark and Shaefer, 1987). She claims that when we talk to one another, we collaborate not only about what we are doing—whether it is building a chair or trying to design a new interface—but also to make the conversation itself happen. Even when we are disagreeing or competing, for our dialogue to proceed we must collaborate at some level (e.g., that is why we speak to our interlocutors in languages we all understand).

The extended nature of conversations—which are typically more than one sentence, or a question and response, long—and the ways in which they use context are not evident in current interfaces (Moore, 1995). It is worth noting that speech interfaces are likewise single interaction oriented and lacking in these features of conversation. A major deficiency in most systems is the meager or nonexistent model of the ongoing interaction with a user. History lists and "undo" features are sometimes incorporated into interfaces, but they typically capture only a small part of the interaction and encode none of its structure. Such approaches ignore what is known about human discourse and its structure.⁷

In her paper, Candace Sidner notes that "only the user does any modeling or remembering of the interaction and its parts." Capturing some aspects of the structure of a dialogue is required for an interface to track a communication. "While an interface to a given application may have hundreds of so-called dialogue boxes, dialogue in the human sense does not take place." Sidner argues that the inadequacy of current interfaces from the perspective of systems that provide a capability for dialogue with users derives in part from their inadequate models of human communication. For instance, the dialogue is restricted to a single exchange in which the user must respond to a system query (e.g., S: "Replace?" U: "Yes") or statement (e.g., S: "File is too large for editor." U: "OK"), the user's response is strictly delimited by the system choices, and often the user cannot proceed without responding. In contrast, when people carry on a dialogue, it typically comprises multiple exchanges; no one person controls what another may say; and all parties are free to change the topic. Context setting and tracking have been studied widely and modeled by researchers in the natural language processing community, but extensions to other modalities and media are needed.

The Circuit-Fixit-Shoppe system (Smith and Hipp, 1994) and the MINDS system (Young et al., 1989) are examples of prototype systems that integrate dialogue capabilities. Specifically, they can have long sequences of interactions with a user and keep track of the roles of the individual interactions and how they all fit together. They maintain goal structures that show the required steps for realizing a central objective and build dialogue around those necessary steps. They function by selecting unachieved subgoals and carrying out interactions with the user to try to achieve them. Coherence of the dialogue is maintained because of the natural relationship between the top-level goals and their supporting subgoals. A dialogue involves the interactions between the participants as they sequentially address the various subgoals needed to eventually achieve or fail to achieve the top-level goal. The nature of the dialogue may be to jump around the proof tree from subgoal to subgoal in a seemingly random order in an attempt to find subgoals that can lead to high-level success. The associated subdialogues resemble common human-human interactions that similarly jump around from topic to topic in a problem-solving situation. These behaviors are in contrast to typical machine capabilities in which there may be little high-level structure to guide the dialogue and to guarantee a well-formed sequence of interactions.

Communication among people is not error free, misunderstanding free, or perfectly efficient. This fact influences the ways in which models of human communication can be useful for interface design in at least two ways. First, designers will not want to incorporate all characteristics of natural discourse into their systems. Second, as they expand the capabilities of systems to have more of the interaction and context-related characteristics of human dialogue, they will need to provide ways of dealing with errors and misunderstandings. The increased power, naturalness, and flexibility that more true-dialogue capabilities provide will undoubtedly engender situations in which a user or system misunderstand one another. They should also provide a richer base for error recovery techniques.

Because interfaces involve the whole experience of a person using a system (as defined in Chapter 1), they need to fulfill more than simply carrying communications between person and machine. In Austin Henderson's view, interfaces have a fourfold role: (1) to help people do what they are doing, (2) to help people learn how to do what they are doing (e.g., help systems and on-line training), (3) to assist people to manage the resources that go into doing their tasks; and (4) to evolve as the technology and the sociotechnical system in which they are using this technology changes. As he said at the workshop, "That is the domain of the interface. To take it any smaller than that is to simply say you are leaving out most of the job the people have in using a machine."

The communication-collaboration view of interfaces is one that does not expect flawless, errorless execution or fixed sequences of actions. Rather, it requires system designs to provide flexibility and means of changing courses of action when things do not go according to plan, as well as options for recovering. People spend a good deal of the time they are working with computer systems getting in and out of trouble (Suchman, 1987). Modeling of the task or intentional context (why the user is communicating in addition to what he or she is saying) as well as of the structured dialogue history is especially critical to deal with situations in which things do not work out right the first time (Sidner, 1983; Litman and Allen, 1990; Lochbaum, 1994).

Another way of viewing the move toward ECIs that communicate and collaborate with their users is to think of having an "interfaceless system," a system that allows a person to be immersed in what he or she is doing without being sidetracked by irrelevant communication details. Weld (1995) describes the advantages of intelligent interfaces—ones that free users from having to know details of where and how information is stored and describe some of the research needed to move beyond the current state of affairs. As discussed in Chapter 6, some activities of intelligent agents involve collaboration and are relevant as enablers of person-to-machine communication and collaboration.

Another concern in this arena relates to social stratification and variation. Gary Olson notes in his paper (available on-line at http://www2.nas.edu/CSTBWEB), that the dominant user interface metaphors emerged from narrow segments of society: the command-based interfaces of early personal computing came from the world of science and engineering; the popular desktop metaphor emerged from the world of the office and white-collar workers; the hypertext metaphor used in World Wide Web browsers came from the world of experimental document structures; popular interfaces like MUDs (multiuser domains) and MOOs (multiuser domains/object-oriented) emerged from computer games and virtual worlds. A legacy of these plural roots is that designers have not yet figured out how to present the information infrastructure to the broad range of potential users. Even such putative examples of widespread success as automated teller machines turn out to have surprisingly narrow distributions of users (on the order of 10 to 15 percent of the public), while more widely used systems, such as video cassette recorders, are the butt of jokes about the inability of average citizens to make full use of them.

Finally, ECIs should do more than make it possible to do things on the NII; they should make it possible to do things well. At the workshop, Loren Terveen noted that, although some interfaces make it easy to do things, "they don't necessarily make it easy to do the things well. I can design HTML (Hypertext Markup Language) pages easily, I can do all kinds of manipulation in Photo Shop, but I can't necessarily build good HTML pages or do attractive graphical images in Photo Shop. I need expert assistance." He argues further that aiming to have systems that help people do things well is additional motivation for having collaborative systems.




ECIs in Support of Person-Person Communication
and Group Activities

ECIs provide support for multiperson activities in two ways: (1) person-person communication—they support communication between individuals and among groups of people, for a range of activities only some of which are collaborative; and (2) group collaboration—they support the collaborative activities of groups, whether formal or informal, that are distributed geographically and with members active at different times of the day (i.e., support of cooperative and collaborative activities that may be carried on asynchronously). These two areas are closely related, but neither subsumes the other. On the one hand, multiperson, multimachine collaborations require communication but also a range of other interface support (e.g., ways of keeping track of the people responsible for various parts of the activity). On the other hand, people use the NII to communicate even when they are not working on a collaborative endeavor; as the social scientists at the workshop observed several times, networks facilitate social communication, and not all communicative uses of the NII are in the service of collaborations.




ECIs for Communication Among People

One of the major uses of the Internet is to enable communication among people (Sproull and Faraj, 1995; Chung and Iacono, 1996; Donath, 1996). We expect that people will similarly use the more enhanced integrated NII for communicating with one another in a variety of ways. Although in some cases they will communicate to get information (here narrowly construed), often the communication will be directed at other purposes.

The impact of networked computer-based communications systems supporting multiple modalities extends beyond those who have their hands on a keyboard. For example, Dourish et al. (1994) in an experiment at Rank Xerox Europarc that involved direct video connections between offices identified four different types of users: people in the wired offices, people who used other people's video links to find someone, the institution that capitalized on members' communications activities, and the surrounding culture that took advantage of those connections to have remote meetings.

People also consult with one another about how to use technology and about where to find information (Constant et al., 1996). At the workshop, Aki Namioka, in discussing the Seattle Community Network, noted that being on the net can be a social activity not only with the community on-line but also with others in the same "room." This same phenomenon appears to be occurring in cybercafes and rooms set up for people to play networked games together. These are very social activities, and the players appear to get a lot out of being colocated. Thus, we should not think of technology as marking the end of face-to-face meetings. It may even lead to meetings that otherwise might not occur. People tackling similar problems want to talk with each other. It is important to understand the ways in which groups pass on information to one another whether they are colocated in the same room or located apart from one other.

This experience is part of a larger pattern, according to Olson, who commented at the workshop on people using technologies in social settings. The telephone is an example, including its history of human operators, and today people commonly get Web URLs (universal resource locators) or help advice from other people (Kraut et al., 1996). He concluded that "the technologies . . . we are studying are themselves embedded in interesting collaborative social situations that we need to take into account when we build these technologies."

Loren Terveen noted in his paper in this volume that such patterns of behavior have seeds for new technology tools. For example, systems might help mediate collaboration between people. They can provide for people to support one another by allowing for asynchronous and geographically remote sharing of information. One set of applications aimed in this direction is work on "social filtering" or "virtual collaboration" (see Reidel and Miller, http://www.sims.berkeley.edu/resources/collab for other references). Research in these areas aims to use computational techniques to help people benefit from each other's experience without their having to be aware of, or communicate directly with, each other at all. Hill (http://community.bellcore.com/navigation) draws the analogy to people establishing and using trails: when walking through the forest, people know where to walk because many people have walked before them. They do not have to decide how to go anew nor do they have to decide about the people who preceded them to benefit from what others have already discovered.

As Lee Sproull explained at the workshop, people attend to social information as well as to task information within an interaction and to community as well as memory across interactions. The result is a need for interfaces to support people as social actors, not just information processors. She cautioned that "a lot of times when people talk with one another, it is not for the purpose of getting information, and if we focus only on that subset of why it is that people communicate, we will have missed an extraordinarily large fraction of what it is that is important to people when they do communicate." Sproull used the example of Usenet groups devoted to topics of physical or mental disabilities or disorders, noting that her research with Sara Kiesler showed them to be used as electronic support groups. "They are places where one can go...to get information, but, . . . if what you really want is information, the Usenet group is not the place to get the highest-quality information, or the most efficient way to get information." This is not to say that Usenet groups and the like are never the place to go for high-quality, relevant information (such information can be found, for example, at http://cancernet.nci.nih.gov and http://www-med.stanford.edu/CBHP), but to acknowledge that they may not be originators of such information, that people may use them for other reasons, and that establishing the quality of information can be difficult (see Chapter 2).

The use of the NII to facilitate communication among people forces us to consider the social aspects of communication—the ways in which communication supports communities—not just the technological means of getting bits from one party to another. As Lee Sproull explained at the workshop: "When people talk with one another, when people communicate with one another, they are not just exchanging information, they are not just acquiring it, they are not just disseminating it; they are also engaged in social action, social behavior....[W]ithin an interaction, people attend to the messenger and the audience, as well as to the message. . .. [They] attend to social information, as well as to task information. Across interactions, people attend to community as well as to memory. So these new kinds of interfaces that we are thinking about need to be designed and constructed as interfaces for social actors, not just for information processors."




ECIs for Support of Group Activities

The NII needs to support more than individual task-related activity and information gathering in the service of such tasks. Many tasks require coordinated group efforts, and people need to work with one another. In many corporate and governmental settings, group activity is the norm. But work is just the beginning, as the social patterns that have emerged on the Internet show. Groups of fans make extensive use of the Internet to discuss their favorite shows (e.g., "Star Trek," "X-Files," etc.; Clerc, 1994). As Gary Olson noted at the workshop, "The kinds of things that ordinary citizens like to do together—clubs, hobbies, interests of various kinds, civic groups, political action groups, and so on, practical problem solving—[the formal modeling and technology communities] know almost nothing about these kinds of collaborative activities, and I think they have very different kinds of needs than the kinds of intellectual tasks that [these communities] are more familiar with."

Although a substantial body of work and techniques has been developed in the computer-supported collaborative work (CSCW) community,⁸ as Terry Winograd notes in his position paper in this volume, "The current state of the art can be described as having a large 'hole in the middle.'" At the theoretical level, there are general abstract theories of how people work together and the role of communication in the process. At the practical level, there are large numbers of specialized applications (including such widely differing ones as retail point-of-sale systems and the National Science Foundation proposal application process) that support organized group activity. Winograd adds,

But we have not yet developed the conceptual and computational tools to make it easy to bring collaboration into the mainstream of applications. When I work with my research group on a joint paper, we use sophisticated word processors, graphics programs, and the like, but our coordination is based on generic e-mail and calendars, and often fails to help us at the places where breakdowns occur.

Furthermore, there is a need for much greater understanding of the ways in which technology can facilitate (or hinder) community formation, especially in nonwhite-collar work settings. The role of computer support for communication and a better understanding of privacy concerns (and the feasibility of various technical solutions to meet them) are among the challenges presented by this arena. The emerging use of computers to support communities of practice in educational settings (see Charles Cleary's paper in this volume) and networked learning communities provide rich sources on which to base some investigations in this area.

As in the case of person-computer communication and collaboration, in building systems to support group collaborations, a significant issue is the degree to which explicit representations of the interaction are embodied in the software itself. E-mail systems represent very little explicitly; point-of-sale transaction systems have detailed representations of the interaction. As Terry Winograd observed following the workshop (private communication by e-mail), "Some of the most successful software has been at each end of this spectrum (e.g., e-mail and sales terminals). . .. There are few if any examples of systems in this middle area that have had major commercial success. The benefits of the explicit structuring do not always accrue to those who do the work" (Grudin, 1993). Claims in this arena too often run to the extremes: some claim that real work cannot be formalized (Suchman, 1987), others that the design of effective software requires an explicit analysis of work (Keen, 1991; Scherr, 1993; Denning and Dargan, 1996; Medina-Mora et al., 1992; Flores et al., 1988). Workflow systems have been criticized, and there have been recent attempts to design more flexible workflow representations (Glance et al., 1996; Dourish et al., 1996).

Here, too, it is essential to look at intermediate positions, coming to understand both the limitations of formalization and the situations in which it can be effectively deployed to increase system usefulness.

At the workshop, Olson argued that it is critical to look beyond white-collar work. "If you look at the proceedings of CSCW, almost all the studies of collaboration are about white-collar work, professional work of the kind that we all do, and we know almost nothing about what kind of collaborative activities occur in much broader social communities."

Sproull's argument, cited in the previous section, that ECIs must take the social aspects of communication and collaboration into account is quite evident in this setting. Often the kinds of social interactions that must be handled arise subtly. At the workshop, Henderson gave an example: "When Xerox . . . began to put its copiers on-line, it was confronted with a problem that up until then was handled beautifully by the stand-alone machines, which were surrounded by physical space, namely, if you walk up to a machine, you can tell whether it is in use, there is somebody standing there, or it's making noise. When you begin to put them on-line and introduce the potential for people to compete for that resource, suddenly, the machine has willy-nilly created a problem for itself as to how you are going to manage that interaction."

Thus, the design of systems to support collaborative work must address interpersonal as well as task aspects of the work. Although some applications are amenable to fixed a priori solutions, others will require an ability for systems to negotiate with their users. As Henderson added at the workshop, "Trying to figure out ... a social model for interruption in the use of a copier, say, or any other resource, is probably something which is a little bit beyond us just now." Research on computer agents that negotiate with one another may offer one approach to this problem.⁹ In other settings, ECIs might provide support for person-person negotiation.

The setting of many people working together using many machines toward some common end raises social science research issues as well. In particular, the interaction between technology and social effort—effort devoted to participating in a social interaction—needs to be understood. Determining whether technology increases or decreases social effort and why is extraordinarily important. A way to estimate or measure social effort is necessary in order to build ECIs that help people minimize or manage social effort. For example, Lee Sproull argues that we know ways to measure the mental effort that is necessary to use any particular interface but that we need to develop ways to assess the social effort that is necessary to use any interface for communication or collaboration. We need to understand better the effort devoted to participating in the social interaction, attending to the messenger and the audience, as well as to the message. Storck and Sproull (1995) discuss this point in the context of video conferencing; Kiesler et al. (1996) demonstrate it in the context of how people respond to interface agents.




DIVISION OF LABOR

Computers and people have different strengths and different skill competencies. One challenge in designing collaboration into a system is determining the appropriate division of responsibility.¹⁰ The negotiation of responsibility is one component of a complete collaboration. In some settings we might want a system to negotiate with people, but for many applications, and certainly in the short term, there will be a need for the system designer to manage this division.

Two sets of issues are raised by the question of how to divide the work to be done between systems and people. First, there is the question of whether to build into a system a fixed division of labor or to give the system a capability for negotiating the appropriate division with users according to the task at hand. Second, a critical aspect of agreeing to the division of responsibility is having trust in the collaborator to do its part; this raises a range of questions concerning trust in computer systems. In addressing both these problems, there is the question of whether the extent to which systems working with people should emulate what people working together do.




Determining Which Party Will Do What

Sidner argues that in the long-term we should aim to understand collaboration and negotiation sufficiently well that we can build systems that emulate people working collaboratively. Henderson argues that "division is ... going to be probably a constantly changing matter and therefore needs to be one of the subject matters of the collaboration." The determination of who is in charge cannot be decided "up-front" but must be worked out along the way. "You need to be able to negotiate with the machine when it is doing what it is doing." This is one of the key areas in which ECI designers will have to find a middle ground between giving a system full responsibility and giving it none.

Some recent research on systems for interactive graphic design has produced very interesting exemplars of such a middle ground. These "semiautomated" design systems do not attempt to have the system take over the whole task of designing a presentation (as do various packages that restrict the user to a small number of static designs and some "intelligent interfaces" (e.g., Roth et al., 1994)), nor do they require the user to directly specify all the details (as do direct manipulation drawing packages). For example, in the GLIDE system (Ryall et al., 1996) for network diagrams, the person does global optimization, and the system does local optimization. In the Gold system (Myers et al., 1994) for business graphics, the user sketches a chart using some of the data and the system completes the diagram for the whole data set. The various Sage tools (Roth et al., 1994) assist users in creating charts and graphs by providing templates and access to past designs in ways that make them easily modifiable to accommodate new data.

A cautionary note was sounded by some at the workshop with respect to computer systems taking on greater roles. Olson said,

It seems to me that if you look at examples of technologies that have actually been helpful or useful in human activities, there is a simplicity that runs through them, and there is a real tendency in building technical systems to want to put lots of things in the system, that the system can somehow manage them better than the people can, and I think over and over again, we have gotten burned with that kind of design bias.

One of the key features of the semiautomated systems described above is their attempt to allocate responsibility to person and machine depending on the computational complexity or skill required. This approach presents a challenge to the designer in determining the division of labor and once again leads to questions of design-and-test iterative cycles.




Developing Trust in Systems

For participants in a collaboration to agree on who will do what, they must be able to trust one another. Such trust requires in part being able to rely on others to carry out a job and their commitment to doing so in the current setting (Grosz and Kraus, 1996). At the workshop, Olson argued that simplicity breeds trust and complexity breeds suspicion; this is evident by observation (e.g., people trust paper copies), but little is understood about how trust is established and maintained. Hall (1996) presents a formal approach to showing how a user can gradually come to trust his or her agent more. Hall's sense of trust is basically that the agent will do what the user wants within specified resource constraints.

At the workshop, Lee Sproull related trust to relationships, as did Stephen Kent, who outlined what information security experts refer to as "the web of trust"—social networks in which the parties trust each other to interact. Sproull explained that human collaborators not only solve problems but also build and sustain relationships with one another as part of establishing trust. Her observations speak to the question of how much systems should be like people. For example, Henderson wondered whether collaborating with a system requires a person to worry about maintaining a relationship with it.

At least four different facets of trust arise when considering collaboration and communication in ECIs: trust of a system with information (e.g., privacy), trusting what the system reports about users (authentication), trusting content (credibility), and trusting the system to function (reliability). Privacy concerns arise for individuals using systems but also for developers as they collect data in seeking to evaluate designs. The question of how we negotiate and manage credibility in an on-line environment is an open research question. We trust things we see in hardback volumes in the library more than we trust similar content on a mimeographed circular handed out by an individual. What are the corresponding mechanisms in computer-mediated information?¹¹

Another aspect of trust relates to the handling of information shared, stored, transmitted, and processed in computer-based systems. In addition to determining the kinds of information that are needed to inform systems design, we also need to seriously consider the ways in which we handle that data. Because collaborations typically require significant information exchanges, incorporating collaborative capabilities into systems may also raise questions of data confidentiality and associated personal privacy issues. This set of issues is receiving considerable attention in other NII-related contexts and is beyond the scope of this study, but the connection of system trustworthiness vis à vis information that is sensitive is relevant to the broader context of making systems more useful to every citizen, as noted in Chapter 2. Thus, although security may seem to be beyond the scope of ECI design, it will impose some constraints that must be understood for the ECI to be useful. As a result, ECI designers must take security concerns into account. Information security or trustworthiness can affect the kinds of information presumed necessary for a system to collaborate effectively, the way in which it is provided, the ways in which it is used, the granting of access to it, the capacity (and associated mechanisms) for providing anonymity or minimizing records of transactions, and so on—issues that can affect the design and use of interfaces and that should be assessed in the kinds of testing recommended throughout this report. At the workshop, for example, Sproull remarked on autologging:

We now have the ability to do a lot of autologging of data about people when they use systems. We haven't had much public discussion about when or the conditions under which those data should be collected and should be made accessible, and I see this as, in some sense, a division of labor between users and systems, but it is an issue that has to be framed within a larger political and social context, and we don't usually think of it that way.




Designer as Collaborator

One way of achieving the partial level of collaboration Henderson argues for may be to explicitly design into a system ways of obtaining and working with information important for collaboration (e.g., information about what the user is trying to do at a level beyond an individual action or system call). Such systems would have only a limited understanding of a user's goals embedded in their design. They would not understand (in any of the usual senses of the word) what the person wants, but the system designer would have done so. This situation places a spotlight on the skills and abilities of designers—what is the norm, what is the ideal—and what they imply in the context of intrinsically nonordinary design specialists designing systems for use by specific groups or whole populations (every citizen) of people.

Speaking as a successful designer, at the workshop Bruce Tognazzini characterized an ideal as follows:

As a designer, I feel when I am designing that I am collaborating with my eventual users. It is in the same way that I would collaborate over the telephone with somebody and communicate with them. At the very least, I am communicating with them, and I would claim I am also collaborating with them. The machine is just the medium for what is essentially a time-shifted conversation between the designer and the end user. Now, since many applications are not designed by designers but are designed by engineers, who are weak in communication skills, a lot of software doesn't look like it is very communicative, but my experience has been when you have a design team that collaborates on the design, and part of that collaboration is bringing in users to test it, and so forth, in this very kind of rich iterative environment, you end up with a very communicative and collaborative piece of software.

Some systems aim to gather information while a system is in use to feed back to the designers. Thus, they give substance to the notion that there is an ongoing collaboration between designers and users and provide technological support to make the collaboration more successful (see Girgensohn et al., 1994; also see Hartson et al., 1996).

In the scenario Tognazzini describes in his paper (this volume), systems designers identify and work with people who are representative of the target user community. They collaborate during the design stage so that the resulting systems are able to collaborate with the people who use them. At the workshop, Henderson noted that "as long as you are playing by that tune, everything goes fine; you fit those capabilities into your work, but it is basically you and the designer. The machine isn't changing much." From this we might conclude that if designers take into account the capabilities and properties needed for collaboration (e.g., establishing a common purpose, a way of achieving that purpose, ways of negotiating over the various choices that arise), identify and consult with target users, and tests designs in realistic environments (see Chapter 4 for discussion of relevant design methods), systems can be produced that collaborate with their users. A system's actions and responses will be structured in a way that aligns with what the user is trying to do. There are thus two collaborations: the design team with a sample user population collaborates to yield a system design that will result in a system that is able to collaborate with users. Although this model may represent the best way to proceed for communication between a single user and a system, research on how to extend "iterated design" to systems being used by multiple people and groups will be needed before it can be used for designing systems to support communication or collaboration among groups of people.

The concept of designer as implicit collaborator evoked two sets of concerns among some workshop participants. The first is that of technologist hubris. Lee Sproull cautioned that when designers talk about user models they mean users' models of the technology rather than models of users. The resulting inference is that what designers are doing is imagining model users, yet almost no one behaves like the model user the designer has in mind. As a result, it is important to broaden our understanding of what it is that users are actually about. Austin Henderson, coming to the defense of designers, maintained that many of the techniques of design are pushing designers to understand that the user does not behave as an idealized, trouble-free user and that the model user is, in fact, someone who is prone to all sorts of error. Gary Olson observed that human-computer interface efforts typically focus on individuals in construing model users, whereas there are model social systems and model organizational systems that mostly are invisible to designers.




CONCLUSIONS: RESEARCH ISSUES AND CHALLENGES

• Theories of collaboration should be developed that support the development of systems that collaborate with people and systems that assist group collaborative activities. Various research communities have been developing models and theories of collaboration (e.g., Bratman, 1992; Grosz and Kraus, 1996; Levesque et al., 1990; Cohen and Levesque, 1990; Grosz and Sidner, 1990; Searle, 1990; Olson and Olson, 1995; Flores et al., 1988), but there is much work to be done to extend them to cover the range of behaviors required for ECIs, to use them in developing ECIs, and to experiment with their use in NII settings.

• Methods should be developed to integrate capabilities for person-computer and person-person collaborations.

• Research should investigate what is needed for people to come to trust computer systems. The information that needs to be communicated by the system should be identified. Ethical responsibilities that system designers incur when producing systems that give assurances of trustworthiness to people should be examined.

• The ways in which technology facilitates community formation, the communication capabilities needed to do so, and the privacy concerns raised should be investigated.

• The social effects of different interface choices should be investigated, particularly the ways in which different presentation and communication choices affect people's interactions with media.




Research Issues for Person-Computer Collaboration

• To develop the conceptual and computational tools to make it easy to bring collaboration into the mainstream of application requires a better understanding of the tradeoffs between explicit representations (which may engender more complex computations) and collaborative power (systems that only implicitly embody certain capabilities needed for collaboration may be less general or less powerful). It should focus in part on determining how to derive system design principles from general theoretical results on modeling of collaboration.

• Research should investigate the extent to which human-computer collaborations can be usefully made more like human-human collaborations. This research is necessarily interdisciplinary; for example, it is conceivable that a technical solution could be found that would prove undesirable for sociological reasons. It must consider both the system-sociological problem of human attribution to machines of capabilities greater than they may have and the modeling problem presented by people being less than "ideal" (perfect) collaborators.

• Research should investigate the tradeoffs in presentational power of the full range of modalities for interaction and media in which to present information and the effects of context on choice. The use of systems to support multiperson activities in these different modalities and the kinds of multiperson collaboration we want to support with ECIs introduce challenging questions both technological (e.g., coordination of information presentation at different locations, delivery of video) and sociological (e.g., developing ways of measuring the effectiveness of ECIs for supporting different kinds of interaction).

• Theories of negotiation should be developed that will enable systems to handle the division of labor more flexibly. Principles should be developed for guiding the design time choice of "who will do what" in ECIs. Methods should be developed for measuring/evaluating different approaches to the division of labor.




Research Issues for Computer Support of Person-Person
Communication and Group Collaborations

• The design of ECIs to support communication among people and groups should be investigated. The scientific base should be provided and the technologies developed so that interfaces can be designed and constructed as social actors, not just information processors.

• Ways should be provided to support community building and other social aspects of communication. Supporting communication means e-mail, chat, MUDs and MOOs, video links, and so forth for every person, not just for the computer literate (i.e., lots of kids and those of us who have used machines at work) and technically sophisticated (computer science types).

• Ways in which systems can support collaborations among people, perhaps even participating in collaborations with groups, should be determined. In doing so, we must look beyond business and professional work to consider the kinds of collaboration that arise in civic groups, clubs, hobbies, and political action groups.

• An understanding should be developed of negotiation and collaboration sufficient for building into the technology the capability for people to build the social systems that will allow for handling the social interactions that arise (e.g., in a resource competition situation).

• Understanding how different sensory abilities of participants affect multisensory collaborative system design, and understanding how the design is affected by varying interface technologies, which may have different multimedia capabilities (e.g., the implications of someone operating over a voice-only connection in a collaborative interaction with others using other kinds of connection), should be developed.

• Ways should be developed for ECIs to support communication and collaboration among multiple people, each with a personal and organizational background that shapes and guides their interactions with others; within these "interaction spaces" ECIs must support communication structures at all levels, from the generic document structuring of the Web to highly task-specific interactions.

• Understanding of social effort in mediated collaborations should be studied.

• Technologies should be developed to support virtual collaborations.



---

NOTES

1. GLIDE is a presentation package, like PowerPoint, but optimized for and restricted to drawing network diagrams (Ryall et al., 1996).

2. "Bob" is a software product that guides novice users, via animated characters and settings, in starting up various home computing applications. Customers found the interface cute but lacking in the capability to help them with complex, difficult tasks. See Arar (1996).

3. There are, in fact, a range of social effects inherent in interfaces. Recent research (Nass and Reeves, 1996) has demonstrated that interactive media generate fundamental psychosocial cues regardless of whether the media are explicity designed. The wording of commands and messages and the presentation of images, for example, can also affect an interface in very subtle ways.

4. Although this problem resembles one that arises for distibuted databases in which different databases associate similar terms/data with different meanings, the challenge is much greater in the NII setting than for databases because the world in which the system is operating is both open (in contrast to the "closed-world assumption" that database systems presume) and very dynamic.

5. I want Jeeves (the P.G. Wodehouse butler); I want somebody who has my context, knows how I operate, and can anticipate what I need, and then help execute it in a completely unobtrusive kind of way, and yes, in that sense I do want to collaborate with my machine. If my machine is sufficiently intelligent, then I will call it collaboration. Today's machines don't permit me to do that . . . . [As an analogy] instead of being able to say, "set the table, we are having company for dinner," and have that translate automatically into a whole number of smaller specifications, I have to say, "pick up the dinner plate, put the fork on the left-hand side," and so on. Everything I want to do in my application, I have to do explicitly.

6. This is not to say that direct manipulation is never the right way to communicate. For instance, it works well for many games (e.g., checkers, chess) whether played on a computer or in the physical world. However, not all extensions from the noncomputer to computer-based interactions are straightforward, as a comparison of recent research on semiautomated drawing systems with commercial computer drawing packages makes clear. (See division of labor discussion of SAGE, GLIDE, GOLD systems.)

7. Grosz and Sidner (1990) have pointers to work in this area.

8. See Proceedings of Computer-Supported Cooperative Work Conferences, 1986-1996.

9. Examples of such work may be found in the proceedings of the International Conferences on Multi-agent Systems, the Distributed AI sections of the proceedings of American Association for Artifical Intelligence (AAAI) and International Joint Conference on Artificial Intelligence (IJCAI) conferences, and in Rosenschein and Zlotkin (1994).

10. Here "responsibility" means "responsibility for doing a job" or "burden," and is not used in the sense of moral or legal responsibility between people and systems.

11. Cryptography offers mechanisms for authentication and privacy. Various operating systems techniques provide for reliability.