To appear in the Proceedings of the ACM CHI'96 Conference, April, 1996.

The Zephyr Help Instance: Promoting Ongoing Activity in a CSCW System

Mark S. Ackerman
Leysia Palen
Department of Information and Computer Science
University of California, Irvine
Irvine, CA 92717
ackerman, palen@ics.uci.edu
http://www.ics.uci.edu/CORPS/ackerman.html

ABSTRACT

If Computer-Supported Cooperative Work (CSCW) systems are to be successful over time, it will be necessary to promote ongoing and continuing activity, not just initial adoption. In this paper, we consider what technical and social affordances are required to encourage the continued use of a CSCW system.

To explore these issues, we examine a chat-like system, the Zephyr Help Instance, which is used extensively at MIT. The Help Instance facilitates users asking questions of one another, and is an example of a distributed help and problem-solving system. We provide an overview of the system's use as well as those mechanisms, both technical and social, that facilitate continuing its use over time.

KEYWORDS: computer-supported cooperative work, CSCW, help, computer-mediated communications, CMC, norms, organizational interfaces, social maintenance, electronic social spaces.

INTRODUCTION

If Computer-Supported Cooperative Work (CSCW) systems are to be successful, it will be necessary to promote ongoing, continuing activity. Even once a CSCW system gets past the critical mass problem, users must continue to find it not only useful, but usable. Only some CSCW systems will provide the social and technical affordances necessary to promote the social maintenance required for continued use.

We examine this issue through the study of a particular system, the Zephyr Help Instance, at MIT. The Zephyr Help Instance is a chat-like system that allows users to ask questions and other users to answer. The Zephyr Help Instance serves as an interesting field study site for several reasons:

At CSCW'94, a call was made to find "real" CSCW systems in wide-scale use. The Zephyr Help Instance has been in heavy use for 7 years (at over 30,000 messages per semester). In its organizational setting, this computer-mediated communication (CMC) system is not monitored or maintained by any authority; its existence is sustained and organized solely by its users. Because its use is discretionary, it serves as an excellent opportunity to study how users might organize their electronic social space. Relatively little is known about how people can best assist one another in a computationally distributed environment. With the Zephyr Help Instance, users help one another in a cooperative environment to continue their work tasks. There have been many times, some highlighted below, where no single person could answer the question posed, but a group of people could. Of course, this type of help would be of little value if the system were not an ongoing source of answers.

Zephyr is a bit of a paradox. The standard interface is rudimentary, consisting of either a text-based, tty interface or a simple X-based interface. Yet, the system is used extensively for technical problem-solving, as well as other types of work and social communication. The simplicity of the user interface allows us to more easily see the social affordances. It is our contention that the system allows participants to invoke a rich set of social behaviors and adaptations. Not only do these interactions allow them to problem-solve, it also allows them to maintain and organize their electronic social space. This usability capability is partially dependent on the user interface, as normally construed, and partially on the organizational or external interface [14].

Therefore, this system provides an interesting and important study. Simply put, the Zephyr Help Instance highlights some critical CSCW requirements -- requirements that have enabled it to be a success within its environment of use over time.

We begin the paper with a brief examination of the CSCW literature concerning continued use over time. Following this, we describe Zephyr in general and the Help Instance in particular. With a firm base in the use of the system, we then analyze why the Zephyr Help Instance has continued to be used.

CSCW SYSTEMS AND ONGOING ACTIVITY

Numerous CSCW and information technology studies have examined the adoption of group and organizational systems (e.g., [9]). The social impacts of computational systems have also been heavily studied (e.g., [16]).

Determining the conditions of success and continuation has been much less clear. One strand of research argues that within many organizations, where use may be mandated, continued use is dependent primarily on either coercion or user satisfaction. The studies assume that with high user satisfaction, systems will be effectively used. Many user involvement and participatory design studies fall within this research stream.

Another line of argument assumes that fit to the social situation provides for system success (or failure) over the long run. In her study of Lotus Notes, Orlikowski [15] claimed that the system assumptions cannot be contrary to the reward schemes and mental maps of the organization or of key groups. Bowers [3] came to similar conclusions in his study of a British government office. Both Orlikowski and Bowers acknowledge the necessity of organizational fit, but also paint a considerably more complex picture that requires a consideration of individuals' goals, shared understandings, and system affordances. Unfortunately, both studied implementations that were failures at the time of study, swaying their conclusions.

While there are few field-based studies of continuing use of computational systems, to our knowledge, there are no studies examining how CMC-based help systems maintain themselves over time. Help has been extensively studied: There is a plethora of studies of technical systems (e.g., [4]), help information design (e.g., [13]), and face-to-face interactions between users and expert consultants (e.g., [1]). Nonetheless, while CMCs have considerable potential for providing access to distributed colleagues for help and problem solving, there is mostly anecdotal evidence for this capability. Sproull and Kiesler do report on a number of CMC uses, including the norms of use, in [17]. Similarly, Finholt reported on the use of distribution lists and their archives in [7]. Outside of these studies, little attention has been paid to how groups using CMCs (particularly for help) organize themselves to maintain their social spaces.

ZEPHYR MESSAGE SYSTEM AT MIT

The Zephyr system is a synchronous chat facility supported on MIT/Project Athena workstations [6]. In Athena, users can use any public-access workstation in any location. Zephyr provides a synchronous method of both communicating and finding other people in a geographically and computationally distributed environment.

Zephyr messages can be sent to a channel, called an "instance", to which multiple people are subscribed. Messages can also be sent to individuals or groups of individuals. (We are omitting description of some advanced features from our discussion here.) Sending a message to an instance is the equivalent of participating in a chat channel; the message is sent to all the people who are subscribing to the instance at that time.

Methods and data

The analysis presented here was largely based on a qualitative examination of the publicly-available message log for one semester, Autumn, 1993. The log consists of 30,052 messages, providing data for 93 days of the 105-day semester. There are gaps of 9 days and of 4 days because of failures in the logging mechanism. There are also some days with only partial data, although it is often difficult to determine when Zephyr was inactive, the logging application was broken, or the Athena system was down.

In addition to our analysis of the message log, the first author has been a participant-observer on the system for approximately three years (and a casual participant for much longer). We have also interviewed the people that started the Help Instance, and interviewed a small number of heavy and light users. We conducted 19 interviews in total. We have used this additional data to corroborate and inform our analysis.

The analysis followed qualitative techniques standardly used to examine small-scale interactions (as in [12]). We were careful to triangulate among our data.

Users

Help Instance users are entirely MIT affiliates, mostly undergraduates, since they are the typical Athena user. This does provide a different type of user population than in many organizations. For example, undergraduates have more time and more willingness to engage new technologies. Additionally, MIT has a distinct technical culture. On the other hand, MIT undergraduates have a wide diversity of technical competence and interest. In general, we believe that the Zephyr users are typical of many technical users, but we will discuss the impact of MIT as an organizational culture below.

In Autumn, 1993, there were 540 users. Usage followed the familiar exponential curve of CMCs [10]. It is important to note that there were a number of user groups. Based on our analyses of the message log, it is clear that there was a core group of "regulars" on the Help Instance (approximately 8% of users). Some people lived on the system. One user had nearly 2400 messages on the Help Instance alone. There was also an intermediate group of intermittent users (the middle of the exponential curve), who participated over the extent of the quarter but at a lower level. Some appeared to stay subscribed to the Help Instance but participated at a lower level; others may have subscribed when they wanted to ask a question or had the time to answer. There were a large number of users (39%) who sent four or fewer messages. Our interview data suggest that the tire-kickers (the tail of the curve) subscribed only when they wanted to ask a question.

Although we have interview and observation evidence that person-to-person exchanges are more common than broadcasting to public instances, we are emphasizing one particular chat channel, the Help Instance, in this paper. It should be noted that the Help Instance is only one channel on the system. Still, the Help Instance was enormously popular and useful.

Zephyr in use

The following sections show how Zephyr is used. Before discussing the technical and social mechanisms by which the Help Instance continues over time as a social space, we need to ground that discussion by describing what occurs on the system.

In the following two message exchange, the user named azir asks a question, and clee answers it. (All names and other identifiers have been changed in any data presented here. Additionally, we have modified the headers and messages slightly for readability and because of page constraints.)

Time: 18:57:10 Date: Fri Oct 29 1993
From: @times(@b(@i( Course II ))) <azir>
after i change a list to a group, how long
before i can use it?

Time: 18:57:52 Date: Fri Oct 29 1993
From: starlight on a moonless night <clee>
you can use it immediately

The rapidity and burstiness of interaction are impossible to duplicate in print, but long lulls are punctuated with frantic bursts of activity. That these messages are only 42 seconds apart is normal. This pacing gives the system a flavor very different from net news or e-mail.

The pace of query and response is an extremely important feature of the system. Messages fly by. If they are not answered within a few minutes, it is likely that they never will be. In general, users ignore any older messages; the system is effectively memoryless.

Several additional things about the messages should be noted. First, the example messages above are unusually short, but the available editors as well as the rapidity of the exchanges tend to keep messages below 10 lines long. All of the lines arrive together. Second, the user must keep track of the conversational threads to know how a message fits into potentially many simultaneous exchanges.

Third, there is some identifying information in addition to the message itself. The timestamp, originating machine, and user id are provided by the system and guaranteed to be correct. The signature on the From line, however, is set by the user. These signatures, or "zsigs", are extremely interesting in their own right. Unfortunately, the zsigs have been shortened here because of space constraints. Finally, the messages are simple in format and flexible in structure. As can be noted from the first From line, there are markup codes for fonts, font styles, and color. (The formatting appears as only markup commands on the tty interface.) There are no other embellishments to the messages.

As mentioned, the user interface for Zephyr is rudimentary. Incoming messages pop up on the user's X screen or scroll by in a tty window; outgoing messages are written with a line-oriented editor. More sophisticated interfaces exist, but are seldom used.

Distributed use of the Help Instance

Many exchanges are like the one presented above -- a single question followed by a single answer. However, one of the advantages of distributed problem solving is that a community of people is involved and many people can attend to each question. Some of the most interesting interactions on the Help Instance capitalize on its distributed nature; these interactions occur when an answer could not be readily provided, and it takes several people multiple iterations to arrive at a solution. Below is an exchange where one person adds to the answer of another:

Time: 20:48:09 Date: Fri Oct 29 1993
From: @i[@(blue)Faded] <chatter>
Thanks for helping me before, but now I have
another problem.
I'm trying to use ftp.
I've gotten into another schools files, but
how do you open them

Time: 20:48:38 Date: Fri Oct 29 1993
From: The Ranger <ranger>
get filename

Time: 20:49:25 Date: Fri Oct 29 1993
From: @tt{@i{The next zsig lies.}} <phopkins>
that copies the file into your current directory
"man ftp" at an athena prompt for more info

Time: 20:49:57 Date: Fri Oct 29 1993
From: @i[@color (blue)Faded] <chatter>
Thanks again!

In this situation, chatter has asked a question about getting files from another site. ranger answers succinctly but his answer "corrects" the naively formed question by chatter. ranger's answer tells chatter how to retrieve files, but not to open them as chatter asks, because that cannot be done with ftp. After the time for a conversational turn for chatter has elapsed, phopkins decides to add more information that elaborates on ranger's answer and provides more help for a novice's use of ftp. Finally, chatter thanks everyone for the help.

The CMC nature of the Help Instance also allows corrections and modifications where necessary. In the following exchange, rpt corrects the initial response.

Time: 06:27:32 Date: Thu Oct 14 93
From: Health is merely the slowest possible
rate at which one can die. <elf>
Who wrote "Hallelujah!"? Or is the author
unknown?

Time: 06:28:27 Date: Thu Oct 14 93
From: band-aid <johnson>
If you're speaking of the Halleljuah chorus,
it is from Hayden's Messiah.

Time: 06:28:36 Date: Thu Oct 14 93
From: Robert Talbott <rpt>
Handel, not Hayden

In addition to multi-party answers, the chat-like nature of the Help Instance allows a user to ask for additional help if he doesn't understand the answer:

Time: 15:44:28 Date: Fri Oct 29 1993
From: Snoozin' <felly>
Why is a load average made up of three
numbers? What do the numbers mean?

Time: 15:45:24 Date: Fri Oct 29 1993
From: Redhead at the wheel <kat>
I think they are short, medium, and long-
term numbers, but I'm not sure. I think they
mean nothing, but I'm not sure

Time: 15:46:05 Date: Fri Oct 29 1993
From: Mythical man-month at work <dan>
1 5 15

Time: 15:46:35 Date: Fri Oct 29 1993
From: Snoozin' <felly>
Huh?

Time: 15:47:07 Date: Fri Oct 29 1993
From: Synthetic syntax spoken <descartes>
Load averaged over the last 1, 5, and 15
minutes, respectively

In this example, user felly posted a question; kat gave a partial response. Another user dan gave a different partial response, perhaps in an effort to disambiguate kat's. Yet another user, huey, gave the final correct answer which disambiguated the previous partial responses. While kat made the initial effort to help felly, both dan and huey joined the conversation in an attempt to make the answer as precise and helpful as possible. This example is one kind of collaborative interaction that illustrates the distributed problem-solving that takes place on the Help Instance. More complex problem-solving also takes place, with extensive iteration and negotiation among users to understand and define the problem.

Finally, many questions get posted that never receive an answer, while others receive responses from many people at once. While this appears to be a failure of the system, it is expected by users. Realizing that one might not get an answer is actually very important to the sustained functioning of the system. Additionally, some questions get a single response referring to a place where a "stock" answer or other information resources can be found.

To summarize, the Zephyr Help Instance provides a mechanism by which users can answer one another's questions. They do this in a distributed environment, and many people can listen and participate in the exchanges. Because participation is always discretionary, users can answer, modify answers, or correct mistakes as they wish. Furthermore, many users can simultaneously participate to solve complex problems. The pace of the system provides immediate feedback and response.

The system capabilities must be augmented by social mechanisms for the system to actually work. For example, the synchroneity of Zephyr promotes use when urgency matters, but a human consultant is not available. However, there must also be enough people on the system to hear the request. The next section examines the social conditions of use.

WHY ZEPHYR CONTINUES TO WORK

Technically, Zephyr and its Help Instance are relatively simple. What makes the Help Instance interesting is not its technical capabilities, but that it works so successfully. Its viability is partially dependent on its technical affordances for social use and partially on the social mechanisms in place for maintaining the sociality. We will discuss those social mechanisms in the following sections.

A shared understanding of the purpose

The Help Instance was begun purposefully as a forum for user questions. It was begun in 1988 by a small group of technically expert undergraduates who were willing to answer questions, and it has maintained the same basic format since.

The Help Instance is now a well-known and well-defined place to ask questions and provide answers within the MIT community. The regularity of activity reinforces that same activity [8]. On the Help Instance, asking questions and finding answers reinforces the actors' providing questions and answers in the same location. Indeed, the actors would be disconcerted if they came to the Help Instance, and it did not contain questions and answers.

Social policing removes wildly deviant behavior on the Help Instance. This is made possible by a system affordance. Because Zephyr has a number of channels--and even more can be created dynamically by any user--it is easy to take an exchange off the Help Instance and continue to exchange Zephyr messages elsewhere. In fact, the Help.d Instance provides an established forum for discussing opinions, analyzing previous help responses, or flaming. Users often tell people to take a dialog to the discussion channel:

Time: 14:32:17 Date: Fri Nov 19 1993
From: Mike <mavedon>
I can go faster not having to take my hands
off the keybd to operate a mouse. also, mousing
bothers my wrist more than typing..

Time: 14:33:15 Date: Fri Nov 19 1993
From: Andrew Topper <andrew>
then use xrn, and stop flaming.
the nature of this sort of thing is that there
*cannot* be One Perfect Interface For Everyone.


Time: 14:32:37 Date: Fri Nov 19 1993
From: Mike <mavedon>
(and this should really go to help.d)

They also reinforce that users should stick to the proper content for a channel:

Time: 21:20:24 Date: Fri Oct 29 1993
From: I'd explain it, but there's a
lot of math. <susan>
please, stick to the appropriate instance,
chang, we're on help.d

Like all the norms discussed here, the playing out of this norm is dependent on the situational context and on the players involved [18]. Flames and opinions do exist; users complain about print quotas, compilers, and their workloads. Still, the content of the Help Instance is remarkably consistent. There is a "common-enough" understanding of the space's purpose.

Roles of asker and answerer

The Help Instance, as a sociality, must reinforce the desire of people to ask questions and for people to answer. While there are many potential questioners, users will not come to the Help Instance unless they can expect their questions to be answered in a manner that is not psychologically or socially problematic. Likewise, potential answerers must find it socially or psychologically beneficial to expend the time and effort to answer questions.

If the system use is to be stable, the creation of potential benefits and the removal of potential liabilities for both questioners and answerers must be institutionalized through some norms and roles. In this, we follow Strauss that these roles will not be extensively and consciously elaborated, and they are partially dependent on the specifics of the participants [18].

For the Help Instance participants, there appear to be two active roles, that of asker and that of answerer. The role of asker is more elaborated in that there is a recognition that users progress from "frosh" (freshman) to more expert users, and this progression should be accounted for in potential answers.

These two roles are heavily intertwined with the attribute of "cluefulness", where people range along a continuum of "clueless" (e.g., freshmen and other naive questioners) to "clueful" or "clued" (e.g., those who answer well). This attribute of "cluefulness" is deeply rooted in the MIT culture, but is often found in technical organizations. It is most often associated with a level of technical expertise and understanding, but it also connotes an internalization of specific institutional and professional norms such as deference to expert authority. We will remark on those aspects "cluefulness" that are important to Zephyr use in our discussion below.

Socially, these two roles -- asker and answerer -- reinforce each other. Indeed, it is important to remember that participants move fluidly between the two. Because of the link to "cluefulness", the roles are also socially reinforced by and are socially reinforcing with the organizational culture of MIT. This process of reinforcement is key to the system's success. However, system affordances make the reinforcements visible and possible.

In the following two sections, we discuss these roles, their norms, and the resulting reinforcements. We will then be able to discuss the system affordances that enable these social mechanisms.

Reducing burden: the role of asker

The information seeker creates a tension within the Help Instance. The purpose of the Help Instance is to provide answers; however, this will be continued only if any burden on the answerers is minimal. Since reciprocality (i.e., the returning an item of similar value) cannot always be met, this need often gets expressed through demands that the asker take the proper actions to seek out the answer through other means:

Time: 16:47:40 Date: Thu Oct 7 1993
From: Brian Burke <brian>
Can someone help me find the E-mail
address of a friend of mine at another
college?

Time: 16:48:10 Date: Thu Oct 7 1993
From: May I help you? <erikson>
You might add consult and look in
/mit/consult/doc/college-email-* first.

Time: 16:48:28 Date: Thu Oct 7 1993
From: in complete contrast <mayabe>
if it's at cornell, maybe.
otherwise, read the stock answers.
there's also a FAQ in news.answers
about finding addresses for colleges.

Knowing to first search the system and external sources of information is part of being "clueful", and therefore part of what distinguishes people capable of answering from those who are "clueless". In the following message, bsutton, one of the more prolific providers of information, admonishes one of his colleagues who did not first search the Unix help pages:

Time: 14:35:55 Date: Wed Nov 10 1993
From: That is not my beautiful house. <bsutton>
*you* I expect to read the manpage when you're
dealing with something you don't know.

This requirement to exhaust other information sources before coming to the Help Instance is not always invoked. It is not invoked for "regulars" of the system, perhaps because they have been presumed to have searched or because they will reciprocally provide other information.

Even when this norm is invoked, it is most often invoked gently. The following exchange provides an example. A freshman, diamond, wants to know how to use uuencode, a program that produces ascii output from binary data. This program is a fairly common application, and on-line help exists in several forms. Two users, arno and chang, tell him to consult external sources. shasha tells him, unusually, to "rtfm", or to read the manuals. Shortly afterwards, however, chang also gives him the answer. In this manner, diamond gets his answer but is also provided with a sharp reminder to check other sources first. He is not told to go away, but neither is his behavior completely tolerated:

Time: 02:12:50 Date: Fri Nov 12 1993
From: @color(red)Intuition refund <diamond>
anyone knows how to use uuencode
and then send it thru mail (which one)?

Time: 02:13:29 Date: Fri Nov 12 1993
From: Sh! I'm hunting foah a rabbit! <arno>
There is a stock answer on that, I think.
Look under MAIL.

Time: 02:13:51 Date: Fri Nov 12 1993
From: <chang>
man uuencode

Time: 02:14:08 Date: Fri Nov 12 1993
From: @bold(Well! morning to you, too.) <shasha>
to summarize the answers, rtfm :-)

Time: 02:16:52 Date: Fri Nov 12 1993
From: <chang>
uuencode <filename | mhmail ......

Time: 02:17:12 Date: Fri Nov 12 1993
From: @color(red)Intuition refund <diamond>
thanks

Another part of being "clueful" is knowing how to phrase a question satisfactorily. This is something that users have to learn, since Zephyr messages are relatively short. In an exchange too long to reproduce here, a freshman regarded publicly as a "clueless frosh" has been told to seek out one of the experts for a face-to-face tutorial. He asks whether it is really necessary, given the lateness of the hour. cmkao comes back with:

Time: 02:02:01 Date: Sat Nov 6 1993
From: Familiar Assonance <cmkao>
Yes, but stop asking
us questions that we're getting frustrated
with in that case :-)

The freshman asks why this is a problem repeatedly. Finally, bsutton informs him:

Time: 02:03:27 Date: Sat Nov 6 1993
From: Psycho killer, anyone? <bsutton>
because, bluntly, you don't know enough
to ask meaningfull questions or
to realize why we can't give you answers
when you ignore our questions to you
or even to understand that you don't know
some things and can't ignore some things.

Of course, the role of the information seeker requires the complementary role of information provider. We next turn to this role.

The role of provider

Concurrently with the need to reduce potential burden on the answerers, the askers need to know that they can ask their questions without psychological or social cost. To effectively continue the Help Instance as a sociality, then, the answerers must not belittle or berate the askers. While being clueful provides the understanding necessary to provide answers, it does not necessarily result in suitable exchanges. Users must also learn how to answer appropriately for the social space.

The responses are expected to be nuanced according to the asker's capabilities and to be polite. In the following example, taken from a longer exchange, hasan has asked how to change permissions on a subdirectory so that other users can access it. This is an arcane task in the Athena environment because of its complex access control. The entire exchange takes 41 minutes (interwoven with several others) and has 9 participants. At one point, sirius tries to be helpful and provides some elementary information. hasan gets indignant at the assumption, and sirius tells him that he was trying to be a helpful information provider. The [...] indicates that several extraneous messages were omitted between hasan's message and sirius's response.

Time: 10:49:17 Date: Mon Oct 18 1993
From: he said, she said. <sirius>
by the way, hasan, ~ means your home
directory, which, in your case, is
/mit/hasan

Time: 10:50:18 Date: Mon Oct 18 1993
From: Hasan <hasan>
Bloody hell, I did know that. Humph.

[...]
Time: 10:53:31 Date: Mon Oct 18 1993
From: Moonlight reflects the rain. <sirius>
hasan -- sorry if some of the things
I'm telling you are things you
already know ... but it's difficult to
judge how much someone knows, and lots
of people will not ask about confusing
jargon even if it is meaningless t
to them.

Sharp or acerbic answers often bring a response from other answerers. After one answerer was curt with a naive questioner, he was taken to task not to be sharp:

Time: 16:15:02 Date: Sat Dec 11 1993
From: Paul Su <pauls>
Switch to help.d?

"Which word didn't you understand?" is one of my pet peeves. The true answer is typically "It is not a particular word, but how the word is related to the concepts under discussion". But almost always the person on the receiving end of this doesn't have the tolerance to formulate such a formal answer.

We should note that the Help Instance is "polite enough." There are no doubt users who find the tone dismissive, difficult, or problematic. Nonetheless, we have noted a usual tone of politeness in the Zephyr exchanges. Askers often send an extra message of thanks, and the answerers seldom are dismissive.

The visibility of expertise

The two roles of asker and answerer get played out in a very publicly visible environment. Zephyr's user interface requires messages to be highly public and visible, which adds to the system's social reinforcement. The visibility affords for public acceptance of an answerer's expertise, requires self-control over incorrect answers, as well as provides an easy path by which people can be recruited for the role of answerer.

Answering questions correctly is extremely self-reinforcing in the MIT culture. With the culture's anchor in technical expertise (as is "cluefulness"), one can gain the admiration of colleagues for showing proficiency. Said one interviewee, "I answer partially to be helpful, and I answer partially to show off." One's performance on the Help Instance is public -- and visible to anyone subscribing. If one is capable of correct answers, then the Help Instance is a good forum for garnering the attention most prized by the organizational culture.

For undergraduates, who form the major population of Help Instance users, this visibility and public performance have extra force. As Davis found with his student nurses [5], students must articulate and rehearse their future professional roles to be successful within school and later in their careers. Successful students come to understand this need, and quickly begin to practice what Davis terms "role simulations" of "valued performances".

The public performance of one's Help Instance activity also diminishes the number of incorrect answers. Since "cluefulness" or technical expertise is enacted (i.e., agreed upon by both the participant and his audience), providing incorrect answers detracts from one's preferred persona. Information providers seldom answer when they are uncertain, and if they do (e.g., when directly asked) will mark uncertain answers appropriately.

The public performance, combined with the ease of response, also results in recruitment of new members. The Help Instance "regulars" provide a stable collectivity which a new recruit may gradually join. Seeing one's questions answered makes it more likely that one will ask questions. Opportunities to correct or elaborate on another's answers provide a forum for slowly increasing one's answering without discomfort. In a situation where no one is compelled to answer, the opportunity to correct or supplement another (politely and non-hostilely) is of high motivation. New members, then, are gradually recruited.

Background attending and lightweightness

While the roles and norms are elaborated to reduce psychological cost for users, participation might still be onerous or problematic without the ability to ignore the Help Instance while attending to one's work.

As mentioned, for people to ask questions, they must feel that they will find an answer. In order for the Help Instance to support collaborative problem solving for its users, it must be attended by many users with various areas of expertise. However, requiring that any given individual provide answers could be onerous, especially if that individual were a volunteer as in the case of the Help Instance. Furthermore, answering or even attending could interfere with one's work performance, thus reducing the likelihood of participation. Consequently, the system must allow many people to follow the progress of a topic and join in the activity voluntarily, as they see fit. Because the interactions are rapid, conversation topics change quickly, allowing users to phase in and out of attending without substantial loss. The amount of work and time required of users to help other users is dictated only by the helper him- or herself.

It appears to be socially permissible to not answer a question, even if questions from other people are being answered. We saw no evidence that this was problematic. If someone doesn't know the answer to question, it is rarely said; the question simply goes unanswered. These same guidelines enable others to not answer a question even if they might know the answer. For this reason, answering a question is seen as a voluntary gesture, and users asking questions should not expect help. In the following exchange, loy is told that he should be patient with not getting a response:

Time: 21:09:07 Date: Wed Oct 6 1993
From: Why are wrong numbers never busy? <loy>
anyone heard of a software company called
metrowerks?

Time: 21:14:18 Date: Wed Oct 6 1993
From: No hypothetical situations? <loy>
has anyone heard of a company called
metrowerks?
(if this is the second time this went here,
then I wasn't subbed before, out of practice,
sorry)

Time: 21:14:44 Date: Wed Oct 6 1993
From: Synthetic syntax spoken <descartes>
No one answered the first time; presumably no
one here has heard of it.

Background attending of a large silent audience also works as a check on the quality of answers given by individuals. As an earlier example showed, users will correct answers, and the large attendant audience serves as a safety net for people who ask questions. Accordingly, there may be less fear of asking questions or of misinforming others.

The system capability for this lightweight attending assists in sustaining the Help Instance. Interestingly, the technical features that afford lightweight attending include the limited display options. The teletype window option lets the Help Instance messages scroll by. The scrolling action allows the user to be conversationally current only on the messages that are still displayed on the screen, reducing the burden on the user to immerse him or herself in a longer-term context. When Zephyr messages are displayed using pop-up windows, each message has its own window. When someone chooses not to attend, the windows pile up on one another, with the most recent Zephyr message on top. Users can then attend to only the most recent message which appears on top. The system is largely memoryless. This lack of memory and the possibility of background attending provide for lightweight help; users need answer only as they wish.

CONCLUSIONS

The Zephyr Help Instance is a place where users can ask questions and get expert, but polite answers. It is also a place where users can answer questions and feel satisfaction and social approval.

To continue providing help, the Help Instance requires, like any sociality, a common-enough understanding of the space's purpose, a shared understanding of the key roles (i.e., questioners and answerers), some norms about acceptable and preferred behavior, and a positive adaptation to the organizational culture. In other words, in order to continue as a social place, there must be a negotiated order of some sort. The Zephyr Help Instance is a simple example of this, but one that is effective and successful.

These social mechanisms rely on several system features. Zephyr is simple technically. But, we have discussed the usefulness found in its capabilities for new instances (for policing of the topics), the system speed (for background attending), the public messages (for rewarding and recruiting answerers), as well as, paradoxically, the lack of memory and the poor display options (for background attending). Most importantly, the generality of messaging allows users to negotiate their status and roles on the system. Perhaps because the system is so simple, the users are able to effectively negotiate their roles and statuses through the system.

Some of the particular social mechanisms described here are specific to MIT or similar organizations. We would not expect to find "cluelessness" per se in many other organizations (although we might find similar labels for new and naive members). Thus, these system affordances do not necessarily enable the social mechanisms. Instead, we note that the users have made creative use of system affordances to organize and regulate their electronic social space. Users were able to seize upon the system features for their own social purposes. The system affordances became resources in the users' world [11], allowing the users to create and maintain a socially useful and usable system over time. Indeed, it is likely that other successful CSCW systems will have similar adaptations.

Acknowledgments

This work continues the Answer Garden project. This began when the first author was at Project Athena, and the authors are indebted to Wendy Mackay, Beth Anderson, and the many users and originators of the Help Instance. Wayne Lutters provided the usage statistics. Bob Halperin, Lisa Covi, Christine Halverson, David Redmiles, and Jonathan Grudin provided additional help with this paper.

The MIT Center for Coordination Science provided continued assistance for this study. This research was supported by grants from NASA (NRA-93-OSSA-09) and the UCI Committee on Research. The second author was supported through an NSF graduate fellowship.

References

1. Aaronson, A. and J. M. Carroll. Intelligent Help in a One-Shot Dialog: A Protocol Study. Proceedings of CHI + GI'87, 1987: 163-168.

2. Berger, P. L. The Sacred Canopy. Anchor, New York, 1967.

3. Bowers, J. The Work to Make a Network Work: Studying CSCW in Action. Proceedings of CSCW'94, 1994: 287-298.

4. Campagnoni, F. R. and K. Ehrlich. Information Retrieval Using a Hypertext-Based Help System. Proceedings of SIGIR `89, 1989: 212-220.

5. Davis, F. Professional Socialization as Subjective Experience. In Becker, H. S., B. Geer, D. Riesman and R. S. Weiss (ed). Institutions and the Person: Papers Presented to Everett C. Hughes. Aldine, Chicago, 1968.

6. DellaFera, C. A., M. W. Eichin, R. S. French, D. C. Jedlinsky, J. T. Kohl and W. E. Sommerfeld. The Zephyr Notification Service. Proceedings of the Usenix Technical Conference, 1988: 213-220.

7. Finholt, T. A. Outsiders on the Inside: Sharing Information through a Computer Archive. Carnegie Mellon University, Ph.D. thesis, 1993.

8. Garfinkel, H. Studies in Ethnomethodology. Prentice-Hall, Englewood Cliffs, NJ, 1967.

9. Grudin, J. and L. Palen. Groupware Success Factors: A Study of Meeting Scheduling. Proceedings of European CSCW Conference, 1995: forthcoming.

10. Hiltz, S. R. and M. Turoff. The Evolution of User Behavior in a Computerized Conferencing System. Communications of the ACM, 1981, 24(11): 739-762.

11. Hutchins, E. Cognition in the Wild. MIT Press, Cambridge, MA, 1995.

12. Hutchins, E. and L. Palen. Constructing Meaning from Space, Gesture and Talk. Proceedings of NATO Workshop on Discourse, Tools and Reasoning , 1993.

13. Kearsley, G. Online Help Systems : Design and Implementation. Ablex, Norwood, NJ, 1988.

14. Malone, T. W. Designing Organizational Interfaces. Proceedings of CHI'85, 1985: 66-71.

15. Orlikowski, W. J. Learning from Notes: Organizational Issues in Groupware Implementation. Proceedings of CSCW`92, 1992: 362-369.

16. Randall, D. and J. A. Hughes. Sociology, CSCW, and working with customers. In Thomas, P. J. (ed). The Social and Interactional Dimensions of Human-Computer Interaction. Cambridge University, New York, 1995.

17. Sproull, L. and S. Kiesler. Connections. MIT Press, Cambridge, MA, 1991.

18. Strauss, A. Creating Sociological Awareness. Transaction, New Brunswick, 1991.