|
||||||||||||||||
|
||||||||||||||||
The following HTML text is provided to enhance online readability. Many aspects of typography translate only awkwardly to HTML. Please use the page image as the authoritative form to ensure accuracy. Page 154 5—
|
||||||||||||||||
 |
 |
Page 154 |
 |
 |
 |
|
| ||||||||||||||||||||||||||||||||
|
|
|||||||||||||||||||||||||||||||
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 155
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 156
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 157
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 158
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 159
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 160
OCR for page 161
OCR for page 162
OCR for page 163
OCR for page 164
OCR for page 169
OCR for page 170
OCR for page 171
OCR for page 172
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,
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
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
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.
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."
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
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
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.
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.