Collaborative Information Environments to Support Knowledge
Construction by Communities
In the information age, lifelong learning and collaboration
are essential aspects of most innovative work. Fortunately, the computer
technology which drives the information explosion also has the potential to
help individuals and groups to learn much of what they need to know on demand.
In particular, applications on the Internet can be designed to capture
knowledge as it is generated within a community of practice and to deliver
relevant knowledge when it is useful.
Computer-based design environments for skilled domain workers
have recently graduated from research prototypes to commercial products,
supporting the learning of individual designers. Such systems do not, however,
adequately support the collaborative nature of work or the evolution of
knowledge within communities of practice. If innovation is to be supported
within collaborative efforts, these domain-oriented design environments (DODEs)
must be extended to become collaborative information environments (CIEs),
capable of providing effective community memories for managing information and
learning within constantly evolving collaborative contexts. In particular, CIEs
must provide functionality that facilitates the construction of new knowledge
and the shared understanding necessary to use this knowledge effectively within
communities of practice.
This paper reviews three stages of work on artificial
(computer-based and Web-based) systems that augment the intelligence of people
and organizations. NetSuite illustrates the DODE approach to supporting the
work of individual designers with learning-on-demand. WebNet extends this model
to CIEs that support collaborative learning by groups of designers. Finally,
WebGuide shows how a computational perspectives mechanism for CIEs can support
the construction of knowledge and of shared understanding within groups.
According to recent theories of cognition, human intelligence is the product of
tool use and of social mediations as well as of biological development; CIEs
are designed to enhance this intelligence by providing computationally powerful
tools that are supportive of social relations.
1. Introduction: The Need for
Computer Support of LifeLong Collaborative Learning
The creation of innovative artifacts and helpful
knowledge in our complex world – with its refined division of labor and its
flood of information – requires continual learning and collaboration. Learning
can no longer be conceived of as an activity confined to the classroom and to
an individual’s early years. Learning must continue while one is engaged with
other people as a worker, a citizen, and an adult learner for many reasons:
·
Innovative tasks are ill-defined; their solution
involves continual learning and the creative construction of knowledge whose
need could not have been foreseen (Rittel & Webber,
1984).
·
There is too much knowledge, even within
specific subject areas, for anyone to master it all in advance or on one’s own (Zuboff, 1988).
·
The knowledge in many domains evolves rapidly
and often depends upon the context of one’s task situation, including one’s
support community (Senge, 1990).
·
Frequently, the most important information has
to do with a work group’s own structure and history, its standard practices and
roles, the details and design rationale of its local accomplishments (Orr, 1990).
·
People’s careers and self-directed interests
require various new forms of learning at different stages as their roles in
communities change (Argyris & Schön,
1978).
·
Learning – especially collaborative learning –
has become a new form of labor, an integral component of work and organizations
(Lave & Wenger,
1991).
·
Individual memory, attention, understanding are
too limited for today’s complex tasks; divisions of labor are constantly
shifting and learning is required to coordinate and respond to the changing
demands on community members (Brown & Duguid, 1991).
·
Learning necessarily includes organizational
learning: social processes that involve shared understandings across groups.
These fragile understandings are both reliant upon and in tension with
individual learning, although they can also function as the cultural origin of
individual comprehension (Vygotsky, 1930/1978).
The pressure on individuals and groups to
continually construct new knowledge out of massive sources of information
strains the abilities of unaided human cognition. Carefully designed computer
software promises to enhance the ability of communities to construct, organize,
and share knowledge by supporting these processes. However, the design of such
software remains an open research area (Stahl, 1999).
The contemporary need to extend the learning process from
schooling into organizational and community realms is known as lifelong learning. Our past research at
the
Section 1 illustrates how computer support for lifelong
learning has already been developed for individuals such as designers. It
argues, however, that DODEs – such as the commercial product NetSuite – that
deliver domain knowledge to individuals when it is relevant to their task are
not sufficient for supporting innovative work within collaborative communities.
Section 2 sketches a theory of how software productivity environments for
design work by individuals can be extended to support organizational learning
in collaborative work settings known as communities of practice; a scenario of
a prototype system called WebNet illustrates this. Section 3 discusses the need
for mechanisms within CIEs to help community members construct knowledge in
their own personal perspectives while also negotiating shared understanding
about evolving community knowledge; this is illustrated by the perspectives
mechanism in WebGuide, discussed in terms of three applications. A concluding
section locates this discussion within the context of AI and society.
2. Augmenting the Work of Individual Designers
In this first Section we discuss how our DODE
approach – which has now emerged in commercial products – provides support for
individual designers. However, because design (such as the layout,
configuration, and maintenance of computer networks) now typically takes place
within communities of practice, it is desirable to provide computer support at
the level of these communities as well as at the individual designer’s level
and to include local community knowledge as well as domain knowledge. Note that
much of what is described in this section about our DODE systems applies to a broad
family of design critiquing systems developed by others for domains such as
medicine (Miller, 1986), civil engineering (Fu, Hayes, & East,
1997),
and software development (Robbins & Redmiles,
1998).
2.1 Domain-Oriented Design Environments
Many innovative work tasks can be conceived of as design processes: elaborating a new
idea, planning a presentation, balancing conflicting proposals or writing a
visionary report, for example. While designing can proceed on an intuitive
level based on tacit expertise, it periodically encounters breakdowns in
understanding where explicit reflection on new knowledge may be needed (Schön, 1983). Thereby, designing entails
learning.
For the past decade, we have explored the creation of DODEs
to support workers as designers. These systems are domain-oriented: they incorporate knowledge specific to the work
domain. They are able to recognize when certain breakdowns in understanding
have occurred and can respond to them with appropriate information (Fischer et al., 1993). They support
learning-on-demand.
To go beyond the power of pencil-and-paper representations,
software systems for lifelong learning must “understand” something of the tasks
they are supporting. This is accomplished by building into the system knowledge
of the domain, including design objects and design rationale. A DODE typically
provides a computational workspace within which a designer can construct an
artifact and represent components of the artifact being constructed. Unlike a
CAD system, in which the software only stores positions of lines, a DODE
maintains a representation of objects
that are meaningful in the domain. For instance, an environment for local-area
network (LAN) design (a primary example in this paper) allows a designer to
construct a network design by arranging items from a palette representing
workstations, servers, routers, cables, and other devices from the LAN domain.
Information about each device is represented in the system.
A DODE can contain domain knowledge about constraints, rules
of thumb, and design rationale. It uses this information to respond to a
current design state with active advice. Our systems used a mechanism we call critiquing (Fischer et al., 1998). The system maintains a
representation of the semantics of the design situation: usually the
two-dimensional location of palette items representing design components.
Critic rules are applied to the design representation. When a rule “fires,” it
posts a message alerting the designer that a problem might exist. The message
includes links to information such as design rationale associated with the
critic rule.
For instance, a LAN DODE might notice that the length of a
cable in a design exceeds the specifications for that type of cable, that a
router is needed to connect two subnets, or that two connected devices are
incompatible. At this point, the system could signal a possible design
breakdown and provide domain knowledge relevant to the cited problem. The
evaluation of the situation and the choice of action is up to the human
designer, but now the designer has been given access to information relevant to
making a decision (Fischer et al., 1996).
2.2 NetSuite: A Commercial Product
Many of the ideas in our DODEs are now
appearing in commercial products, independently of our efforts. In particular,
there are environments for designing LANs. As an example, consider NetSuite, a
highly rated system that illustrates current best practices in LAN design
support. This is a high-functionality system for skilled domain professionals
who are willing to learn to use its rich set of capabilities (see Figure 1).
NetSuite contains a wealth of domain knowledge. Its palette of devices that can
be placed in the construction area numbers over 5,000, with more downloadable
from the vendor every month. Each device has associated parameters defining its
characteristics, limitations, and compatibilities –domain knowledge
used by the critics that validate designs.
In NetSuite, one designs a LAN from scratch, placing devices
and cables from the palette. As the design progresses, the system validates it,
critiquing it according to rules and parameters stored in its domain knowledge.
The designer is informed about relevant issues in a number of ways: lists of
devices to substitute into a design are restricted by the system to compatible
choices, limited design rationale is displayed with the option of linking to
further details, and technical terms are defined with hypertext links. In
addition to the construction area, there are LAN tools, such as an automated IP
address generator, and utilities for reporting on physically existing LAN
configurations. When a design is completed, a bill-of-materials can be printed
out and an HTML page can be produced for display on the Internet. NetSuite is a
knowledgeable, well constructed system to support an individual LAN designer.
2.3 The Need to Go Further
Based on our understanding of organizational
learning and our investigation of LAN design communities, we believe that in a
domain like LAN management no closed system will suffice. The domain knowledge
required to go beyond the functionality of NetSuite is too open-ended, too
constantly changing, and too dependent upon local circumstances. The next
generation of commercial DODEs will have to support extensibility by end-users
and collaboration within communities of practice. While a system like NetSuite
has its place in helping to design complex networks from scratch, most work of
LAN managers involves extending existing networks, debugging breakdowns in
service, and planning for future technologies.
Many LAN management organizations rely on home-grown
information systems because they believe that critical parts of their local
information are unique. A community of practice has its own ways of doing
things. Generally, these local practices are understood tacitly and are
propagated through apprenticeship (Lave & Wenger,
1991).
This causes problems when the old-timer who set things up is gone and when a
newcomer does not know who to ask or even what to ask. A community memory is
needed that captures local knowledge when it is generated (e.g., when a device
is configured) and delivers knowledge when needed (when there is a problem with
that device) without being explicitly queried.
The burden of entering all this information in the system
must be distributed among the people doing the work and must be supported
computationally to minimize the effort required. This means:
1.
The DODE knowledge base should be integrated
with work practices in ways that capture knowledge as it is created.
2.
The benefits of maintaining the knowledge base
have to be clearly experienced by participants.
3.
There may need to be an accepted distribution of
roles related to the functioning of the organizational memory.
4.
The software environment must be thoroughly
interactive so that users can easily enter data and comments.
5.
The information base should be seeded with basic
domain knowledge so that users do not have to enter everything and so that the
system is useful from the start.
6.
As the information space grows, there should be
ways for people to restructure it so that its organization and functionality
keep pace with its evolving contents and uses (Fischer et al., 1999).
DODEs must be extended in these ways to support communities
of practice, not just isolated designers. This reflects a shift of emphasis
from technical domain knowledge to local socially-based community knowledge.
3. Supporting Communities of Practice
In this Section, we briefly define “community of
practice” – a level of analysis increasingly important within discussions of
computer-supported cooperative work (CSCW) – and suggest that these communities
need group memories to carry on their work. The notion of DODEs must be
extended to support the collaborative learning that needs to take place within
these communities. A scenario demonstrates how a CIE prototype named WebNet can
do this.
3.1 Community Memories
3.1.1 Communities of Practice
All work within a division of labor is social (Marx, 1867/1976). The job that one person
performs is also performed similarly by others and relies upon vast social
networks. That is, work is defined by social practices that are propagated
through socialization, apprenticeship, training, schooling, and culture (Bourdieu, 1972/1995;
Giddens, 1984; Lave & Wenger, 1991), as well as by explicit
standards. Often, work is performed by collaborating teams that form
communities of practice within or across organizations (Brown & Duguid,
1991).
These communities evolve their own styles of communication and expression, or
genres (Bakhtin, 1986; Yates
& Orlikowski, 1992).
For instance, interviews we conducted showed that computer
network managers at our university work in concert. They need to share
information about what they have done and how it is done with other team
members and with other LAN managers elsewhere. For such a community, information
about their own situation and local terminology may be even more important than
generic domain knowledge (Orr, 1990). Support for LAN managers
must provide memory about how individual local devices have been configured as
well as offer domain knowledge about standards, protocols, compatibilities, and
naming conventions.
Communities of practice can be co-located within an
organization (e.g., at our university) or across a discipline (e.g., all
managers of university networks). Before the World Wide Web existed, most
computer support for communities of practice targeted individuals with desktop
applications. The knowledge in the systems was mostly static domain knowledge.
With intranets and dynamic Web sites, it is now possible to support distributed
communities and also to maintain interactive and evolving information about
local circumstances and group history. Communities of practice need to be able
to maintain their own memories. (The problem of adoption of organizational
memory technologies by specific communities involves complex social issues
beyond the scope of this paper. For a review of common issues and positive and
negative examples of responses, see (Grudin, 1990;
Orlikowski, 1992; Orlikowski et al.,
1995).)
3.1.2 Digital Memories for Communities of Practice
Human and social evolution can be viewed as the
successive development of increasingly effective forms of memory for learning,
storing, and sharing knowledge. Biological evolution gave us episodic, mimetic,
and mythical memory; then cultural evolution provided oral and written —
external and shared memory;
finally modern technological evolution generates digital (computer-based) and
global (Internet-based) memories (Donald, 1991; Norman,
1993).
At each stage, the development of hardware capabilities must
be followed by the definition and adoption of appropriate skills and practices
before the potential of the new information technology can begin to be
realized. External memories, incorporating symbolic representations,
facilitated the growth of complex societies and sophisticated scientific
understandings. Their effectiveness relied upon the spread of literacy and
industrialization. Similarly, while the proliferation of networked computers
ushers in the possibility of capturing new knowledge as it is produced within
work groups and delivering relevant information on demand, the achievement of
this potential requires the careful design of information systems, software
interfaces, and work practices. New computer-based organizational memories must
be matched with new social structures that produce and reproduce patterns of organizational
learning (Giddens, 1984; Lave
& Wenger, 1991).
Community memories are to communities of practice what human
memories are to individuals. They make use of explicit, external, symbolic
representations that allow for shared understanding within a community. They
make organizational learning possible within the group (Ackerman &
McDonald, 1996; Argyris & Schön, 1978; Borghoff & Parechi, 1998;
Buckingham Shum & Hammond, 1994; Senge, 1990).
3.1.3 Integrative Systems for Community Memory
Effective community memory relies on integration. Tools
for representing design artifacts and other work tasks must be related to rich
repositories of information that can be brought to bear when needed.
Communication about artifacts under development should be tied to the artifact
so they retain their context of significance and their association with each
other. Also, members of the community of practice must be integrated with each
other in ways that allow something one member learned in the past to be
delivered to other members when they need it in the future. One model for such
integration – on an individual level – is the human brain, which stores a
wealth of memories over a lifetime of experience, thought, and learning in a
highly inter-related associative network that permits effective recall based on
subjective relevance. This – and not the traditional model of computer memory
as an array of independent bits of objective information – is the model that
must be extended to community memories.
Of course, we want to implement community memories using computer
memory. Perhaps the most important goal is integration in order to allow the
definition of associations and other inter-relationships. For instance, in a
system like those to be discussed in Section 3 using perspectives, it is
necessary for all information to be uniformly structured with indications of
perspective and linking relationships. A traditional way to integrate
information in a computer system is with a relational database. This allows
associations to be established among arbitrary data. It also provides
mechanisms like SQL queries to retrieve information based on specifications in
a rather comprehensive language. Integrating all the information of a design
environment in a unified database makes it possible to build bridges from the
current task representation to any other information. Certainly,
object-oriented or hybrid databases and distributed systems that integrate data
on multiple computers can provide the same advantages. Nor does an underlying
query language like SQL have to be exposed to users; front-end interfaces can
be much more graphical and domain-oriented (Buckingham Shum, 1998).
Communities themselves must also be integrated. The Web
provides a convenient technology for integrating the members of a community of
practice, even if they are physically dispersed or do not share a homogeneous
computer platform. In particular, intranets are Web sites designed for communication
within a specific community rather than world-wide. WebNet, for instance, is
intranet-based software that we prototyped for LAN management communities. It
includes a variety of communication media as well as community memory
repositories and collaborative productivity tools. It will be discussed later
in this Section.
Dynamic Web pages can be interactive in the sense that they
accept user inputs through selection buttons and text entry forms. Unlike most
forms on the Web that only provide information (like product orders, customer
preferences, or user demographics) to the webmaster, intranet feedback may be
made immediately available to the user community that generated it. For
instance, the WebNet scenario below includes an interactive glossary. When
someone modifies a glossary definition the new definition is displayed to
anyone looking at the glossary. Community members can readily comment on the
definitions or change them. The history of the changes and comments made by the
community is shared by the group. In this way, intranet technology can be used
to build systems that are CIEs in which community members deposit knowledge as
they acquire it so that other members can learn when they need to or want to,
and can communicate about it. This illustrates computer support for
collaborative learning with digital memories belonging to communities of
practice.
3.2 Extending the DODE Approach to CIEs for Design
To provide computer support for collaborative
learning with CIEs, we first have to understand the process of collaborative
learning. Based on this analysis, we can see how to extend the basic
characteristics of a DODE to create a CIE.
3.2.1 The Process of Collaborative Learning
The ability of designers to proceed based on their tacit existing expertise (Polanyi, 1962) periodically breaks down and they have to rebuild their understanding of the situation through explicit reflection (Schön, 1983). This reflective stage can be helped if they have good community support and effective computer support to bring relevant new information to bear on their problem. When they have comprehended the problem and incorporated the new understanding in their personal memories, we say they have learned. The process of design typically follows this cycle of breakdown and reinterpretation in learning (see Figure 2, cycle on left) (Stahl, 1993b).
Figure 2.
Cycles of design, computer support, and organizational learning.
When design tasks take place in a collaborative context, the
reflection results in articulation of solutions in language or in other
symbolic representations. The articulated new knowledge can be shared within
the community of practice. Such knowledge, created by the community, can be
used in future situations to help a member overcome a breakdown in
understanding. This cycle of collaboration is called organizational learning
(see Figure 2, upper cycle). The personal reflection and collaborative
articulation of shared perspectives makes innovation possible (Boland & Tenkasi,
1995; Tomasello, Kruger, & Ratner, 1993).
Organizational learning can be supported by computer-based
systems of organizational memory if the articulated knowledge is captured in a
digital symbolic representation. The information must be stored and organized
in a format that facilitates its subsequent identification and retrieval. In
order to provide computer support, the software must be able to recognize
breakdown situations when particular items of stored information might be
useful to human reflection (see Figure 2, lower cycle) (Stahl, 1993a). DODEs provide computer
support for design by individuals. They need to be extended to collaborative
information environments (CIEs) to support organizational learning in
communities of practice.
3.2.2 Extending the DODE Approach to CIEs for Design
The key to active computer support that goes
significantly beyond printed external memories is to have the system deliver
the right information at the right time in the right way (Fischer et al., 1998). To do this, the software
must be able to analyze the state of the work being undertaken, identify likely
breakdowns, locate relevant information, and deliver that information in a
timely manner.
Systems like NetSuite and our older prototypes used critics
based on domain knowledge to deliver information relevant to the current state
of a design artifact being constructed in the design environment work space
(see Figure 3, left).
One can generalize from the critiquing approach of these
DODEs to arrive at an overall architecture for organizational memories. The
core difference between a DODE and a CIE is that a DODE focuses on delivering
domain knowledge, conceived of as relatively static and universal, while a CIE
is built around forms of community memory, treated as constantly evolving and
largely specific to a particular community of practice. Where DODEs relied
heavily on a set of critic rules predefined as part of the domain knowledge,
CIEs generalize the function of the critiquing mechanisms.
Figure 3. Generalization of the DODE architecture (left) to a CIE (right).
In a CIE, it is still necessary to maintain some
representation of the task as a basis for the software to take action. This
task representation plays the role of the design artifact in a DODE, triggering
critics and generally defining the work context in order to decide what is
relevant. This is most naturally accomplished if work is done within the
software environment. For instance, if communication about designs takes place
within the system where the design is constructed, then annotations and email
messages can be linked directly to the design elements they discuss. This
reduces problems of deixis (comments referring to “that” object “over there”).
It also allows related items to be linked together automatically. In a rich
information space there may be many relationships of interest between new work
artifacts and items in the organizational memory. For instance, when a LAN
manager debugs a network, links between network diagrams, topology designs, LAN
diary entries, device tables, and an interactive glossary of local terminology
can be browsed to discover relevant information.
The general problem for a CIE is to define analysis
mechanisms that can bridge from the task representation to relevant community
memory information items to support learning on demand (see Figure 3, right).
To take a very different example, suppose you are writing a paper within a software environment that includes a digital library of papers written by you and your colleagues. Then an analysis mechanism to support your learning might compare sentences or paragraphs in your draft (which functions as a task representation) to text from other papers and from email discussions (the community memory) to find excerpts of potential interest to deliver for your learning. We use latent semantic analysis