Page 154

5—
Communication and Collaboration

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



The National Academies | 500 Fifth St. N.W. | Washington, D.C. 20001
Copyright © National Academy of Sciences. All rights reserved.
Terms of Use and Privacy Statement



Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.

OCR for page 154
Page 154 5— Communication and Collaboration 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

OCR for page 154
Page 155 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 hyperlinked 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).

OCR for page 154
Page 156 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

OCR for page 154
Page 157 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

OCR for page 154
Page 158 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

OCR for page 154
Page 159 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., GLIDE1) 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

OCR for page 154
Page 160 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.2 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.3 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,

OCR for page 154
Page 161 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."4 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 seem 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

OCR for page 154
Page 162 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.5 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.6 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

OCR for page 154
Page 163 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.7 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.

OCR for page 154
Page 164 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."

OCR for page 154
Page 169 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,8 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

OCR for page 154
Page 170 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.9 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

OCR for page 154
Page 171 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.10 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.

OCR for page 154
Page 172 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.

OCR for page 154
Page 173 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?
11 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 trust-worthiness 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:

OCR for page 154
Page 174 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).

OCR for page 154
Page 175 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

OCR for page 154
Page 176   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 trust-worthiness 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

OCR for page 154
Page 177   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

OCR for page 154
Page 178   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).

OCR for page 154
Page 179 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.