Knowledge Communities:
Online Environments for Supporting Knowledge Management and its Social Context*

2.2 The Social Construction of Knowledge

This sort of situation is not the exception, it is the rule. A wide variety of research programs – for instance, ethnographies of workplaces, social studies of science, critical theory, organizational memory, the sociology of knowledge – point to the deep connections between knowledge management and social context.

For example, ethnographic studies of workplaces reveal a wide array of social practices implicated in the production and dissemination of knowledge. Lave and Wenger have developed the notion of a community of practice. They note that one way in which people come to master a body of knowledge is through a sort of apprenticeship or "legitimate peripheral participation" in the activities of a group of practitioners (Lave and Wenger, 1991). Wenger (1998) describes the daily work in an insurance claims processing office, and shows how it is entwined with social relationships and processes. Similarly, in an ethnography of copier service technicians, Orr (1996) reveals that technical knowledge is socially distributed across a network of technicians, and that it is tapped into and disseminated through oral processes such as storytelling.

A similar sense of the social nature of the production and dissemination of knowledge comes from the field of social studies of science – see Latour and Woolgar (1979) and Latour (1987). For example, Traweek's ethnography of particle physicists (1988) examines some of the social phenomena that structure the practice of high energy physics. She notes the impact of social relationships on the placement of graduate students, the evaluation of experiments, and access to equipment and facilities. Her comments on the role of conversation are particularly interesting:

At a more general level, Brown and Duguid (1995) note that even documents, which appear to be fixed, immutable public entities whose very purpose is to transcend social contexts, "play an important role, bringing people from different groups together to negotiate and coordinate common practices." Documents, they suggest, in their production, use, and distribution, have their own social life, and function as mediators of and catalysts for social activity.

2.3 Social Capitalism

An awareness of ways in which work is bound up with social factors has assumed a prominent place in business discourse regarding knowledge management. Often referred to as organizational learning in these contexts, knowledge management in the organization is seen as a collective process in which teams create and share knowledge (e.g. Senge, 1990; Nonacka and Takeuchi, 1995; Cohen and Prusak, 2001; Boone, 2001). While proponents typically invoke a systems perspective in thinking about organizational processes, they also emphasize social factors – such as relationships, trust, reputation, and commitment – in their descriptions of how such processes play out. As a Vice President of Strategy puts it:

Recently the concept of social capital – the "features of social organizations such as networks, norms, and social trust that facilitate coordination and cooperation for mutual benefit" (Putnam, 2000) – and the possible role it may play in the networked organization, has come to the fore. Cohen and Prusak (2001) explain the connection:

Elaborating on the connection between social capital and knowledge sharing, Cohen and Prusak point out that exchanging knowledge depends on a social connection – "without some degree of mutuality and trust, the knowledge conversations will not get started; without some degree of shared understanding, they will not go very far" (Cohen & Prusak, 2001, p. 86). They also note that the knowledge exchanged in spontaneous conversations "is often social knowledge – shared aims and interests discovered, signals and stories shared that build confidence, trust, and connection–rather than technical or business knowledge that can be directly applied to a product or problem" (Cohen and Prusak, pp. 86-87).

2.4 The Challenge

Thus far we have argued that knowledge management is not just an information problem, but that it is a social problem. That is, we’ve suggested that effective knowledge management involves networks of people, relationships, and social factors like trust, obligation, and commitment. One can’t isolate knowledge from its social context without denaturing it, without stripping it of the social resources and social knowledge that contribute to its utility.

Taking the social nature of knowledge seriously raises a considerable challenge for those interested in designing knowledge management systems. We suggest that the place to start is to stop thinking in terms of knowledge management, and start thinking in terms of supporting the larger social context in which knowledge management is embedded. Our response to this challenge is to explore the role of online multiuser environments. In particular, we are interested in environments within which users can engage socially with one another, and, in the process, discover, develop, evolve, and explicate knowledge. We refer to online multi-user environments used in these ways as "knowledge communities." In what follows we discuss current environments that function as knowledge communities, and then turn to our own work on the topic.

3. Knowledge Communities

Knowledge communities have a long history, albeit not by that name. The idea that networks of computers might provide a medium within which individuals might come together to share knowledge and expertise dates back to at least 1960. Perhaps the first vision of this nature was offered by Simon Ramo (Ramo, 1961), who wrote of "many millions of human minds ... connected together." Ramo offered a number of scenarios, including one of an attorney consulting an on-line database that contained more than data:

Over the ensuing decades the idea spread and evolved. From its beginning as a vague if exciting vision, it took concrete form in the special purpose DELPHI and EMISARI systems pioneered by Murray Turoff in the early ‘70s (Turoff, 1972; Hiltz and Turoff, 1993) and in the PLATO Notes system in the mid ‘70s (Wooley, 1993). In the late ‘70s and early ‘80s the idea took off, spreading and evolving, under pressures from application domains such as education and gaming, into a variety of genres of software ranging from bulletin board systems to MOOs.

3.1 Some Examples of Knowledge Communities

A complete account of the systems which are used to enable online groups to share knowledge among themselves is well beyond the scope of this chapter. Instead, we will take the tack of looking at some representative examples to give an idea of both the types of systems and the forms of use that are used in managing online knowledge. It is important to note that we are not just interested in the software; we are interested in the combination of the software and the way in which it is put to use by its users – we refer to this comvination of technology and usage as a knowledge community.

One genre of software that supports knowledge communities is the MOO. MOOs, originally developed as multi-user text-based gaming environments, have been applied to a number of pedagogical and business ends. Examples include MOOSE Crossing, an educationally-oriented environment for children from eight to thirteen (Bruckman, 1997); Pueblo, a school-centered MOO in Phoenix, Arizona (O'Day, et al, 1996); Tapped In, a distributed community of teachers (Schlager, et al., 1998; Schlager et al., in press); and a MUD used by employees at Argonne National Labs for work-related talk (Churchill and Bly, 1999).

Another genre of system that can support knowledge communities is the electronic mailing list, or listserv. While mailing lists are used for a variety of purposes, the existence of mailing lists used to share knowledge among cohesive, long-lasting communities is well documented. In one case, a community of about a thousand professional journalists have used a mailing list to help one another with technical problems and to find story-specific information sources for over six years (Millen and Dray, 1999; Millen 2000). Another example, the use of a mailing list to support discourse amongst a scholarly community, is described by Ekeblad (1999). And a third example, the use of a listserv by a community of soap opera fans, to share knowledge ranging from plot summaries to character background information, is described by Baym (Baym 1995; Baym 1997).

In addition to the genres of mailing lists and MOOs, which can be turned to a variety of ends other than knowledge sharing, quite a few systems have been designed with their principal aim being the support of a knowledge community. One example is Answer Garden (Ackerman, 1998), a blending of bulletin board and email systems that makes a network of questions and answers available to its users, and uses email to automatically route new questions to appropriate experts whose answers are then incorporated into the network. The Zephyr Help Instance (Ackerman and Palen, 1996) has a similar purpose – providing online help information – but uses a synchronous chat-like mechanism to broadcast questions and answers to the user community. Another genre of knowledge community system is the collaboratory. Collaboratories are aimed at the needs of the scientific community, and provide real time access to scientific instruments along with synchronous communication channels ranging from textual chat to real time audio and video (Olson and Olson, 2000). Collaboratories are a highly successful class of applications, with many in existence that have supported dozens to hundreds of users for periods of years.

If one examines these systems and the ways in which they’re used to share knowledge, an interesting commonality emerges: Virtually all of these systems exhibit a rich array of social phenomena, in spite of the fact that most provide only textual communication mechanisms, typically synchronous chat, asynchronous email, or both (as in MOOs). (Even collaboratories, which are increasingly support ing various forms of high bandwidth synchronous interaction, functioned well when chat was their dominant communication channel.) Examples of the social phenomena found in most knowledge communities range from interpersonal phenomena such as the negotiation of status and reputation or the development of trust, to the emergence of group norms and conventions. While these systems bear eloquent testimony to the ingenuity of their users in using textual representations to support a rich array of social phenomena, we suspect that we can do better.

This brings us to the question which informs our own work. What would it mean to design an infrastructure for a knowledge community from the ground up? That is, if we take seriously the charge that knowledge management is a social problem as well as an information problem, one response is to ask how we can better support social interaction. How do we go about designing a system which supports not just information sharing, but that supports the exchange of social knowledge and resources, the creation and growth of interpersonal networks and accompanying social phenomena such as trust, obligation, commitment and accountability?

To address this question, we’ve developed a system called "Babble" which we’ve used as a testbed for exploring these issues over the last four years. We begin by discussing the rationale that underlies Babble's design: the notion that increasing the visibility of the presence and activity of participants in an online environment can provide a foundation for a variety of social processes and activity. Next we describe the system that we’ve implemented, and discuss the ways in which we’ve come to use it as part of our daily work practice. Finally, we discuss our experiences in deploying Babble to other work groups.

3.2 Supporting Online Social Interaction

In the building where our group works there is a door that opens from the stairwell into the hallway. This door has a design problem: opened quickly, it is likely to slam into anyone who is about to enter from the other direction. In an attempt to fix this problem, a small sign was placed on the door: it reads, "Please Open Slowly." As you might guess, the sign is not a particularly effective solution.

Let’s contrast this solution with one of a different sort: putting a glass window in the door. The glass window approach means that the sign is no longer required. As people approach the door they see whether anyone is on the other side and, if so, they modulate their actions appropriately. This is a very simple example of what we call a socially translucent system.

We call systems that exhibit these properties — of perceptual salience, awareness, and accountability — socially translucent systems. But there is one other aspect of social translucence that deserves mention. Why is it that we speak of socially translucent systems rather than socially transparent systems? Because there is a vital tension between privacy and visibility. What we say and do with another person depends on who, and how many, are watching. Note that privacy is neither good nor bad on its own–it simply supports certain types of behavior and inhibits others. For example, the perceived validity of an election depends crucially on keeping certain of its aspects very private, and other aspects very public. As before, what we are seeing is the impact of awareness and accountability: in the election, it is desirable that the voters not be accountable to others for their votes, but that those who count the votes be accountable to all.

We see these three properties of socially translucent systems – visibility, awareness, and accountability – as critical building blocks of social interaction. Notice that social translucence is not just about people acting in accordance with social rules (see Erickson & Kellogg, 2000). In socially translucent systems we believe it will be easier for users to carry on coherent discussions; to observe and imitate others’ actions; to engage in peer pressure; and to create, notice, and conform to social conventions. We see social translucence as a requirement for supporting online communication and collaboration in general, and knowledge communities in particular.

This brings us to the question of how to support social translucence in online environments. How can we provide the cues that allow our socially based processes to operate – and which are so ubiquitous and lightweight in the physical world – in online systems? Two obvious approaches are to use video or 3D virtual environments. However, these have several drawbacks for our purposes. First, they don't scale well: we would like to support conversations among fairly large numbers of people. Second, both approaches are best suited for supporting synchronous interactions, whereas we would like to support both synchronous and asynchronous interaction. Third, they are both relatively demanding in terms of processing power, bandwidth, and display space and characteristics: we would like to be able to support mobile employees working over sub-56K connections and using devices with smaller displays.

As a consequence, we have taken a more abstract approach to supporting social translucence. The abstract approach involves portraying social information in ways that are not closely tied to its physical analogs. Exemplars of the abstract approach include the Out to Lunch system (Cohen, 1994), which uses abstract sonic cues to indicate socially salient activity, and Chat Circles (Viegas, et al. 1999), which uses abstract visual representations. This approach also includes the use of text to portray social information; as we have already noted, text has proved surprisingly powerful as a means for conveying social information in knowledge communities.

3.3 The Babble System

Babble (Erickson, et al., 1999) is an online environment intended to support both synchronous and asynchronous text-based conversations within small to medium sized groups. The principle goal of Babble has been to serve as a platform for exploring ideas about the social effects of supporting mutual awareness among online groups. However, to do this effectively, we needed to be able to observe 'real' workgroups using it as part of the daily work process. As a consequence, Babble needed to be sufficiently robust and lightweight to be usable by groups who don't care about the technology itself.

In terms of infrastructure, Babble is a client-server system with both components written in SmallTalk. Babble stores all data, except for user specific preferences and state (e.g., the user's last location, last items read, and so forth) on the server and broadcasts it as needed. Babble clients request the data they need from the server (e.g., when a user switches to a new conversation the client requests the content), and also notify the server of events that it will broadcast to other clients. As this architecture suggests, Babble only works when on a network; when disconnected it has no cache of conversation text. The Babble server runs on a variety of server-class machines; the principle client runs on PCs, though we have had, for varying durations, clients that ran on the Macintosh (in Java) and on the Palm Pilot. Here we discuss only the PC client, since that comprises the vast majority of our experience.

In terms of functionality, Babble resembles a multi-channel, text-based chat system in that many users can connect to it, and select one of a variety of conversations to participate in (or create their own). However, Babble differs from conventional chat in two ways, both of which stem from our interest in supporting knowledge communities. First, the textual conversation that occurs in Babble is persistent: that is, unlike conventional chat where newly arriving users only see what has transpired since they've joined a channel, Babble users can see everything ever typed in any existing conversation. These traces give the system the potential to function as a knowledge store, or what we prefer to call a "discourse base." Second, Babble makes the presence and activity of the participants visible by a variety of means, but principally through what we call the social proxy.

Figure 1 shows the Babble user interface. In the upper left hand corner is a list of the names of users currently connected to Babble. In the middle upper pane is the social proxy, which we will describe shortly. In the upper right pane is a hierarchical list of the Babble conversation topics (grouped in categories and subcategories). And the pane that occupies the lower half of the window contains the text of the current conversation (whose topic name is highlighted in the topics list); within the pane, each 'comment' is prefaced with the name of the user, and date and time of its creation (recall that Babble conversations need not be synchronous; indeed, some are asynchronous, with hours, days or weeks separating comments). Babble provides a variety of other types of functionality via the menu bar, context-sensitive menus accessed via right clicks, and keyboard shortcuts. These include functions for creating messages, creating, changing, and deleting topics and categories, conducting private, ephemeral chats, and so forth.

The social proxy, in the upper middle part of the window, represents the current conversation as a large circle, and the participants as colored dots, referred to, hereafter, as marbles. Marbles within the circle are involved in the conversation being viewed; marbles outside the circle represent those who are logged on but are viewing other conversations. What makes the social proxy interesting has to do with the position of the marbles in the circle. When a user becomes active, either 'speaking' (i.e., typing) or ‘listening’ (i.e., interacting with the conversation window by clicking or scrolling), the user's marble moves rapidly to the center ring of the circle. If the user stops interacting, the marble gradually drifts out to the inner periphery of the circle over the course of about twenty minutes. Thus, when there is a lot of activity in the conversation, there is a tight cluster of marbles around the center of the circle. The social proxy shown in Figure 1 depicts a situation in which five people have been recently active (i.e., speaking or listening) in the current conversation, and two others have been idle for a while (and an eighth person is off viewing another conversation).

When people leave the current conversation their marbles move outside the circle; when they enter the conversation, their marbles move into the circle. When a person logs onto the system, it creates a virtual wedge for their marble, adjusting the position of all the marbles in the social proxy; when they depart, the wedges are destroyed, and the remaining marbles adjust to uniformly occupy the space. All marble movements are shown with animation, thus making arrivals, movements, and departures visually salient. Although simple, this social proxy gives a sense of the size of the audience, the degree to which the audience is actively listening or contributing, as well as indicating whether people are gathering or dispersing, and who it is that is coming and going.

In addition to the social proxy (which we refer to as 'the cookie'), Babble uses additional mechanisms to reveal the presence and activity of users. In the topic list, to the left of the topic names, are 'mini-cookies', thumbnails of the social proxy for each topic with a participant in it. So, in Figure 1, we can see that there is a single person in the second topic, "Amusing Wendy." Babble also highlights information that the user hasn't yet seen: the names of topics with new material in them are shown in red (e.g., "Amusing Wendy" in Figure 1), and comments that have been added to the current conversation since the user last 'touched' Babble are shown in reverse highlighting.

One of the shortcomings of the cookie is that it only works for synchronous interactions – that is, it shows only the presence and activities of people who are currently logged on to Babble. This is a considerable drawback because the majority of the conversations carried on in Babble are asynchronous, with just a few comments per day (or per week, or per month). As a consequence, we designed a second, asynchronous social proxy for Babble: the Timeline (Figure 2).

The basic goal of the Timeline was to provide a way for a ‘speaker’ to see that people were ‘listening’ (or not), even when the listening was offset in time. The Timeline proxy works as follows: each user is represented by a row in the Timeline; when they are logged on to Babble, they leave a flat trace or line, and when they ‘speak’ they leave a vertical mark or blip on the line. If the line/blip is in color, it means that that user was present/speaking in the conversation currently being viewed by the user of the timeline; if they were in a different conversation, the line/blip is shown in gray (and the line becomes thinner). As the user mouses over the Timeline, the name of the topic, the user, and the time being examined is shown in the upper left corner; the user can scroll back through as much as one week of activity. The Timeline also provides access to other functionality via a menu accessed via a right-click on another user’s row (e.g., private chats).

For example, in Figure 2, we can see that nine people have logged onto Babble (shown by the presence of lines), and that all of them have spent some time in the current conversation (shown by the color/increased thickness of the lines), and that many but not all have ‘spoken’ (shown by the blips). The line being indicated by the cursor shows that the user ‘Peter’ logged on around 11am, made a couple of comments in the "Commons Area" conversation, switched to another topic, and then switched back to the Commons area about 1pm, and then logged off.

3.4 How a Babble is Used by a Group

While one must be wary about drawing conclusions concerning the usability of software when it is used by its developers, our aim here is to simply provide a sense for how Babble is actually used by a group. We’ll begin by describing the group, and then move on to discuss how Babble is actually used. In the next section we'll discuss our deployments of Babble to other groups and some of the phenomenon that we’ve observed across different deployments.

Our group has used Babble for about four years. The group is centered around the software development group (AKA "the lab") that designed and implemented the system, and includes a mix of computer scientists and social scientists (including the authors). The size of the group has varied in number over the years from four to nineteen users. Part of the variance is due to the ebb and flow of people characteristic of groups in large organizations; and part is due to current members of the lab inviting "associates" – colleagues with whom they had strong social or professional ties – to join Babble.

Geographically, the group of Babble users is about half co-located in New York, and half distributed. Most of the lab members are located in the same building, although offices tend to be distributed around the building – so actual adjacency is rare. Three members of the lab are telecommuters, and spend the majority of their time tens to hundreds of miles away; other members of the lab frequently work at home. Four of the six associated colleagues (i.e. those not officially members of the lab, but users of Babble) are remotely located.

Socially, the lab is a cohesive group, with considerable camaraderie. In addition to work-based collaboration, the lab members occasionally socialize, although usually within business hours (e.g., going out to lunch) The associates vary in the strength and number of their ties to the lab members, some known to almost all lab members, and others known only to one or two lab members with whom they have shared interests. Conversation in the Babble system moves fluidly between work and social talk; it is always civil, frequently informal, and joking, teasing, and other ludic behavior is not unusual.

Overall, the Babble system as used by the lab can be characterized as a core of relatively synchronous activity surrounded by a constellation of asynchronous conversations. At the center of activity is a topic called the "Commons Area," a place where collocated and remote members greet one another, share news, engage in banter, and ask general questions. Members of the lab tend 'hang out' in the Commons Area, often remaining logged on for most of the work day. Comments in the Commons Area tend to be short and informal, with relaxed syntax and punctuation, use of paralinguistic expressions ("ummm"), onomatopoeia, emoticons, and playful tropes (for example, the ‘tossing of cookies’ to ‘a dog’ who usually ‘accompanies’ one of the participants – all done via text, of course). The content of conversation in the Commons Area ranges from purely social talk (such as the custom of saying "good morning"), to the posing of general questions, to reminding people of an impending meeting of general interest, to more technical discussions about work projects. (In theory, more topic-oriented discussion is ‘supposed’ to take place in specific topics; in practice, work talk often grows out of social discussions, and the recognition that a substantive conversation that ‘belongs somewhere else’ is taking place is often not recognized until after the fact.) Because of the amount of talk that occurs in the Commons, the content of the Commons Area is automatically archived once a week.

In addition to the commons area, there are a variety of other topics or conversation areas in Babble. These have ranged in number from a dozen or so in the early days of Babble to several dozen, the growth being facilitated by the addition of an expandable hierarchical topic list. These topics tend to have asynchronous and mostly sporadic conversation, and they tend to be focused on particular purposes, typically either project-oriented or person oriented. Examples of topics include personal offices (e.g., "Tom's Office"), project-oriented topics (e.g., "Babble Ethnographies–CB Babble"), and occasional non-work topics (e.g., "Bad Jokes").

In general, uses of Babble can be grouped into three general categories: social/ludic; informative; and instrumental. Social/ludic activities are those engaged in for social and entertainment purposes such as the custom of exchanging morning greetings, and the topic devoted to jokes. Informative activities have to do with actions on the system that are addressed to the group as a whole, or to no one in particular, and generally are done without expectation of a reply or responsive action. These activities include posting announcements and other news believed to be of general interest, commenting on project activity, and keeping on-line notebooks or offices. The third type of activity is instrumental, that is, activities engaged in with a particular end in mind. These include starting or participating in focused discussions, posting bug reports, holding on-line meetings, and asking questions. These activities are often, though not always, addressed to a particular participant or group of participants.

3.5 Adoption and Social Phenomena across Babble Deployments

Over the last four years we've deployed Babbles to about twenty groups. We’ve studied the deployments using techniques ranging from ethnographic studies – see Bradner, et al. (1999) for a study of six Babbles – to studies based on surveys and analyses of log data and conversation archives.

We have had mixed experiences with the adoption of Babble. Sometimes groups try Babble out, but fail to adopt it (typically about six weeks pass before it is evident whether or not the Babble is going to be adopted by the group). Other times groups use Babble for a period of months, and then cease (either because it was for a particular event or period that has ended, or because the composition or needs of the group change). It isn’t clear how to operationally define a successful deployment of Babble: the group uses it for its entire existence? the group uses Babble actively for six months? the group uses Babble to carry out a particular activity? If we take, as a rule of thumb, that a Babble is successful when it is used on a more or less daily basis by several people for more than six weeks, we can say that about half of our Babble deployments have met with success. As of this writing, we have five Babbles running, all of which are well past the six week mark, and all exhibiting robust daily activity.

When a Babble is adopted by a group, it usually supports a variety of communicative purposes and practices (often similar to those described in the previous section). Here, we describe four social phenomena that we’ve observed in a number (though not all) of successfully adopted deployments that are most relevant to knowledge communities.

One phenomenon is waylay, in which a user watches for a particular person to become active on Babble (signaled by the movement of their marble into the center of the social proxy), and then initiates a conversation (either publicly within Babble, via Babble’s private chat mechanism or by some external means such as the telephone). Because the movement of the marble occurs when the user has just begun an episode of typing or mousing, it indicates a opportune moment for contact (since the user’s attention has just shifted to communication with the group). Waylay is used for purposes ranging from asking questions to initiating casual social chat. In general, forms of opportunistic interaction such as waylay permit the same sorts of requests for assistance and transfers of social resources that we’ve observed in face to face knowledge sharing situations, with the accompanying effect of strengthening of interpersonal ties.

Babble also supports the maintenance of group awareness through the exchange of social knowledge. For example, when members of a Babble travel, many report reading through conversations that occurred in their absence to ‘find out what happened.’ For someone who is a member of the group and understands the context, seemingly trivial comments can convey considerable information about what’s going on at the individual, group, and organizational levels. Thus, a sign off – "I have to go to the [project] meeting now" – reveals that one participant is still involved in a particular project, and a question – "Does anyone know how to do a screen capture" – indicates that someone is beginning to write a paper. Babble also supports group awareness through the Timeline proxy. Babble participants have reported uses such as: looking to see who has visited a topic in which they had posted questions; looking to see whether a colleague who hadn’t posted recently had been online; and using the Timeline to get a sense for the activity of the community as a whole.

Another phenomenon that can be observed across Babbles is the development of social norms. That is, one participant may develop a particular way of doing something, and others will imitate it. Examples of this include what users include in their online nickname (e.g., in some Babbles users append "@mylocation" after their name), the types of online conversations created (e.g., some Babbles have categories for "personal places" or "offices"), and naming conventions (e.g., one Babble uses the term "chit-chat" to signal that a topic is intended for casual conversation. Babble groups also evolve various interactive customs, the most common being to say 'hello' upon logging in (even when no one else is present). Again, the existence of these norms supports social interaction by providing expectations about how to behave.

Finally, we’ve observed that Babbles are typically regarded as semi-private, "trusted" places. This became apparent when ‘strangers’ appeared in various Babble systems. Sometimes the strangers were unannounced new members, sometimes they were visitors provided access by an unreflective manager, and, in one case, the stranger was actually an unannounced conversational software agent. But in all cases, the arrival and presence of the stranger (reflected in the social proxies along with the presence of the regulars) was greeted with considerable consternation. In each case, the appearance of strangers provoked concern about how unguarded conversations might be interpreted by those from different contexts, and led to the creation of visitor and membership policies. We suggest that this concern reflects the success of Babble as an online space that is rich in social context.

One issue that is not clear, so far, is the degree to which Babble’s social proxies contribute to these phenomena. Analytically, it is difficult to isolate the effects of the social proxies, from the effects of purely textual cues. Certainly, there are a number of social practices (such as waylay) which require (or are at least greatly facilitated by) the proxies. It is clear that the participants, in general, like the proxies and want them retained as a feature of the system. One user, responding to a question in Babble, writes:

It is also clear that users are able to ‘read’ Babble proxies, using them to draw inferences about the presence of individuals and the activity of the community as a whole. Another user, commenting on the Timeline proxy, remarks:

Nevertheless, although we have compelling anecdotes and a large fund of positive comments by Babble users, analytically separating social benefits conveyed by proxies from those produced by text remains as a challenge for the future.

3.6. Babble as an Infrastructure for Knowledge Communities

Babble clearly succeeds as a multi-user online environment where sustained social interaction takes place. But does it support knowledge communities? Is the social interaction combined with the sharing of information, social knowledge and social resources via personal social networks that, we suggest, is a crucial part of knowledge management? This is indeed what we have observed. In the following, we refer to examples and survey results drawn from a Babble whose membership is composed of a world wide cross-section of people in IBM and Lotus interested in online communities.

Perhaps the first point to make is that participants do feel as though they are part of a community. This is particularly important to those who are remote teleworkers:

Another says:

This is not simply a feeling of a vague belonging to a group; participants report feeling as though they are hooked into social networks. One participant reports that participation in Babble strengthened an existing network:

And these social networks are not just about talk, they can also be tapped for assistance. The participant continues:

Another Babble member notes:

These comments are prima facie evidence that knowledge sharing and expertise management are deeply social processes – that people value informal exchanges with colleagues, and may only venture a non-trivial request for information or assistance after a social relationship has been established.

4. Concluding Remarks

In this chapter we’ve argued that knowledge management is not just an information problem, but is, as well, a social problem that involves people, relationships, and social factors like trust, obligation, commitment, and accountability. This view raises a considerable challenge for those interested in designing systems to support knowledge management. Our approach has been to explore the creation of infrastructures for knowledge communities: on-line environments within which users can engage socially with one another, and, in the process, discover, develop, evolve, and explicate knowledge.

In our work on Babble, we’ve begun exploring ways of creating infrastructures that support rich forms of social interaction. We’ve found that social proxies are a promising development, and continue to be impressed with the power of plain text as a means of supporting interactions that are both complex and subtle. We believe that one of the most important aspects of a knowledge community is that it can be used as a place for unguarded discussion among people who know one another, who share professional interests, and who understand the contexts within which their remarks are being made.

The notion of a knowledge management environment as a ‘trusted place’ is an interesting and challenging one. How – technically, socially, and organizationally – can we balance the need for a safe and trusting place with the organizational imperative to share information? One decision facing us as designers is how and to what extent we "design in" norms and social conventions. For example, if we build in technical mechanisms to provide privacy, in addition to the usability impact, we also eliminate opportunities for participants to show that they may be trusted, or to rely on others to respect their privacy. The Babble prototype has no technical features for controlling access: anyone who has access to the client could, in theory, enter any Babble space. But, because Babble makes users visible, this results in groups noticing, commenting on, and ultimately discussing how to deal with this issue. We believe that a greater understanding of how to design systems that permit social mechanisms to come into play is of great importance in designing future systems for knowledge management.

Acknowledgments

Thanks to David N. Smith for creating the Babble prototype, to Mark Laff , Peter Malkin, and Amy Katriel for implementation work on the Babble server and clients, and to Cal Swart for critical assistance in the deployment of a multitude of Babbles. Thanks, as well to members of IBM's Social Computing and Pervasive Applications groups for productive conversations, and to the many dozens of 'Babblers' who have shared their insights, responded patiently to surveys, and, most importantly, used Babble in many of productive (and often surprising) ways.

References

[Tom's Home Page]
[Professional] [Life, Fun, &c] [Tell Me...]
[Bookmarks] [Publications List] <and many papers and essays>

Of more general interest: [Apple HI Alumni page] [Interaction Design Patterns page]

Maintained by Tom Erickson, snowfall@acm.org