Ellen Isaacs: Piazza: A desktop environment supporting impromptu and planned interactions

Published in 1996 in the ACM, Proceedings of the Conference on Computer-Supported Cooperative Work held in Cambridge, MA, pp. 315-324. (1) A PDF version of this paper is available.

Abstract

Much of the support for communication across distributed communities has focused on meetings and intentional contact. However, most interactions within co-located groups occur when people happen to run into each other. Such unintended interactions should also be supported among distributed communities. We conducted a study of the communication patterns of a large, distribed organization and found that people tend to disseminate information using formal techniques, even though people usually receive information informally. We then designed a system called Piazzathat is intended to support the range of communicationstyles evident in large communities, paying particular atten-tion to addressing the problems revealed in our study. Piazza allows people to be aware of others who are doing similar tasks when they are using their computers, thereby enabling unintended interactions. It also supports intentional contacts and planned meetings. We discuss issues for analysis in anupcoming use study.

Keywords:Informal communication, unintendedinteractions, awareness, networkers, enterprise-widecommunication, collaboration.

Introduction

The popularity of the World Wide Web has highlighted the value of transferring information anywhere, anytime overthe network. As organizations embrace sites located around the globe, users of mobile computing devices, and telecommuters working from home, they have come to rely on rapidly improving network connections to handle the information needed to run their business. So far, these networks have largely been used as an efficient way to ship around data, as exemplified by the Web. However, to restore a sense of community to distributed workers, we should think of using the network to enable the rich communication opportunities afforded by physical workplaces.

Research and development efforts to support synchronous communication so far have mainly explored the use of networked computers to help people explicitly contact other individuals and groups. For example, desktop videoconferencing and media spaces have been designed to help people contact others for impromptu conversations [Bly, et.al, 1993; Fish, et. al, 1993], and meeting support software has been developed to help groups hold pre-arrangedmeetings (e.g. ShrEdit, Colab, Forum) [Olson, et. al, 1992; Stefik et al., 1987; Isaacs, et al., 1994].

However, a small body of literature has begun to focus on the importance of interactions that occur opportunistically when people happen to see each other [Kraut, et. al, 1990b; Whittaker, et. al, 1994; Isaacs, et al., 1997]. When groups are co-located, people often "run into each other" in the halls, at the photocopier, in the cafeteria, and elsewhere. A small but important percentage of the time, they start conversations that turn out to be critical to the coordination, productivity, and well-being of the group [Kraut, et. al,1990b; Kraut & Streeter, 1995; Whittaker, et. al, 1994].

We set out to explore ways of enabling these unintended interactions for communities that are distributed across different locations. In this paper, we first provide some background on the importance of unintended interactions and some systems that partially support it. Then we report on some interviews we conducted to investigate information flow in a large distributed organization. We then describe the design of a system called Piazza that supports the various kinds of interactions needed to facilitate enterprise-wide information flow and communication. Finally, we consider how the design addresses the communication needs established earlier, and we describe some issues to be studied in a forthcoming evaluation of the system.

The role of unintended interactions

Kraut, et. al [1990b] distinguished four categories of interactions: planned (prearranged meetings), intended (explicitly sought by one person), opportunistic (anticipated by one party but occurring only when the parties happened to see each other), and spontaneous (unanticipated by either party). We focus on these latter two types of interactions, which we will call "unintended." Kraut, et. al [1990b] estimated that unintended conversations made up 52% of the interactions that occurred in the workplace they studied. Whittaker, et. al [1994] found that 92% of the interactions they observed in two office settings were not pre-arranged, although some of those were intended. These interactions were frequent and very short; 31% of workers time was spent in informal interactions, and they lasted under two minutes on average.

Previous research demonstrates the importance of unintended interactions. Kraut, et. al [1990b] showed that informal interactions are responsible for much of the information flow in an organization. In addition, the more a group engages in unplanned interactions, the more likely its project will succeed [Kraut & Streeter, 1995]. Nonetheless, that study showed that groups tend to under-utilize unplanned interactions compared with their effectiveness. Finholt, Sproull & Kiesler [1990] found that frequent, spontaneous interactions play an important role during the planning and negotiation phases of projects. Furthermore, the lack of such exchanges reduces the level of coordination and progress on projects [Kraut, et. al, 1990b]. Groups that have few informal interactions between formal meetings tend to be less productive than groups with frequent impromptu contact, even though the former tend to have more efficient, task-focused meetings.

Further research shows that groups who do not maintain so-called "weak ties" with people outside their group tend to be less productive [Granovetter, 1973; Nelson & Mathews, 1991]. Weak ties are relatively low-intensity relationships with little mutual obligation and are maintained within frequent contact, most likely unintended encounters. Weak ties have been shown to promote flexibility and effective decision making. In addition, groups with relatively few weak ties have a tendency to negatively stereotype other groups [Nelson & Mathews, 1991]. Finally, informal office discussions are shown to be important in helping people learn and adopt the social conventions and procedures of a community [Suchman & Wynn, 1984].

Systems Supporting Unintended Interactions

Despite the critical role of unintended interactions, only a few software systems have included features that make it possible to come across someone unintentionally and startup a conversation. The media space work [Bly et al., 1993; Fish, et. al, 1993] highlighted the use of audio and videoconnections among distributed sites to help people notice the work activity of others and make contact, regardless of whether they are down the hall or at a remote site. However, explicit attempts to support serendipitous encounters through this technology has so far proven to be disappointing. The main weakness of these attempts is that they have brought together people who do not necessarily have a context or need to interact, and placed them in a situation where it is awkward to ignore each other [Kraut, et al., 1990b; Abel, 1990]. One media space system that did gain acceptance is Portholes at Xerox EuroPARC. It allowed people to stay aware of others by viewing a matrix of slowly updating video snapshots of the offices of a fixed set of people within a site [Dourish & Bly, 1992]. These views could prompt a user to establish an audio-video connection with someone they saw in Portholes.

In our previous research, we saw a hint of unplanned interactions in Forum, which enabled live presentations to a distributed group [Isaacs, et al., 1995]. Sometimes audience members noticed others in the audience list and exchanged text messages. However, noticing a name in a scrolling list was much less natural than seeing the person at a talk, and exchanging text notes was more cumbersome than leaning over to whisper to each other.

The socially rich interactions that occur in MUDs (multi-user domains) illustrate how even a text-only system can support unplanned interactions [Curtis, 1992]. As users navigate through regions in a virtual world and encounter others (via text descriptions and commands), they are able to interact and create complex social organizations. More recent graphical virtual communities [Morningstar & Farmer, 1992] add richer visual representations of places and people, making it easier to notice and start interactions with others. However, these worlds tend to be disjoint from participants' "real worlds" and they occur only within a space that the user must explicitly choose to visit.

An alternative approach to supporting unintended interactions is embodied in the Virtual Places work by Ubique. Virtual Places allows users to see graphical representations of others browsing the same Web page at the same time and to open up a text or audio chat with them. Virtual Places also offers mechanisms for navigating through Web pages together.

All these systems are a step in the right direction, but they have one or more of the followed limitations. They:

require people to rendezvous at a specified on-line "place" in the network to see others
lack enough context to help people enter interactions
do not enable a seamless transition from a sighting to an interaction
involve a pre-set group of people

All of these components are important. To maintain a sense of connection among a large community, people need to be able to: "happen across" a large subset of the population on a regular basis without having to go to a specific physical or on-line location; have some reason to start up an interaction with others; and enter an interaction with little effort.

So far, the research has pointed to the untapped potential of unintended interactions in supporting distributed collaboration, and the challenges of applying technology to address this issue. Before designing a system to address this issue, we wanted to learn more about how members of a large distributed organization currently disperse and collect information.

Information Flow In A Large Organization

We conducted a series of interviews within Sun, which employs about 15,000 people in six continents. We interviewed 12 people in different parts of the organization, many of whom had been involved in communicating information to other parts of the organization. Participants included a human resources manager, employee communications specialists, high-level technical professionals, a sales representative, a director in the CEO's office, a system administrator, and several managers and engineers. Interviews involved people from four sites across the company.

The following are the four prominent outcomes of these interviews:

People disseminated information using formal mechanisms, but they retrieved information through informal means.

People most commonly said they distributed information by:

Using the formal hierarchy: People often presented their ideas to top management and asked them to pass the information down the chain.
E-mail: It was common for people to identify an appropriate distribution list and post a message.
Publishing documents: People often posted documents on the company's internal Web or created a formal report. In some cases, they prepared a high-quality brochure and sent it to everyone's company mailbox or to their homes (e.g., information about company benefits).

In many cases, people used more than one of these techniques. For example, they might make a formal presentation to a vice president's staff, hand out a document, and send e-mail to others announcing the availability of the document. A few used alternative media such as videotapes, audiotapes, or on-line audio-video presentations.

On the other hand, when asked how they retrieved information, people most commonly said they did so by:

Asking someone: Most people said they either walked down the hall and asked someone face-to-face, sent e-mail to someone who might know the answer, or called someone.
Waiting to run into someone: For information less urgent, people often waited until they saw someone whom they expected to run into in the near future, perhaps at a meeting, the cafeteria, the fitness center, etc.
Having unexpected, informal conversations: Many people found out information when they happened to see someone in a common area or when they walked by people's offices.
Using on-line tools: Such tools included the internal Web pages, an on-line documentation set that holds the company human resources information, the on-line rolodex tool, e-mail they saved, etc.

The interesting thing about these two lists is that there is very little overlap. People do not directly get information the way others try to convey it to them. The next finding indicates that people recognize that a problem exists.

People believe that channels they use to disseminate information are not very effective.

People were unhappy that the information they presented to management never made it to the rank and file employees. When they sent e-mail, they had difficulty choosing which mailing lists to include. When it was imperative to reach every single employee (e.g., Human Resources announcements), it was difficult to make sure everyone had seen the information and taken appropriate action.

People were aware that large-scale e-mails or videos were inefficient because it was difficult to convey their relevance to all the recipients. Those who experimented with audioand video messages received mixed reactions. For example, when employee communications sent out short, on-line videos from the CEO, some said the videos gave them "the warm fuzzies" because they could see the CEO as a person and have more of a personal connection with him. Others, though, thought the videos were so corny and low in content that they never watched them.

This finding supports Kraut & Streeter's [1995] finding that formal techniques are over-utilized relative to their value. Our results indicate that people realize that their methods are less effective than they would like. Given this awareness, and that people usually use word of mouth to get information, we wondered why people did not use word of mouth more often to communicate their message. We found:

Information disseminators are wary of word of mouth.

People felt uncomfortable giving their information to others and hoping it would spread because doing so did not let them control the message. Also, they could not easily determine what impact the message was having; they could not see people's immediate reactions or answer their questions. Finally, they felt it was hard to guarantee reaching everyone who should hear a message if the information is passed on informally.

When we focused on recipients' complaints about the messages they received, we found that:

Those receiving information felt they were getting an inappropriate amount of information, and often not the right information.

A common complaint was that people were getting too much information, but not enough analysis. E-mail was usually the worst offender. This organization's culture is exceptionally (some say pathologically) dependent on e-mail, and people disliked getting information that appeared to have no relevance to them. But at the same time, they felt there was a lack of information about higher-level concerns (e.g., the company's strategy and direction). People also felt that information, again especially in e-mail, often came at a time when it was not needed. When they did need the information, they had difficulty finding where they had stored it (if they had). This information overload effect has been found by others [e.g., Hiltz & Turoff, 1985; Whittaker & Sidner, 1996].

Finally, many people felt that the information they received was not credible, especially formal, official information. All-hands meetings, company-wide e-mail announcements, and formal planning presentations were cited as suspect. People said if they really wanted to know about something, they would ask someone who they knew stayed in touch with company issues and whose analysis they trusted.

When we explored this last point, we realized the importance of those people who collect information and spread it to their colleagues near and far. These "networkers" seemed to be critical to the information flow. However, when we talked to networkers, we found that:

Although effective "networkers" were critical to information flow, they were not formally recognized.

Networkers felt that collecting information helped them do their jobs, and that those who used the information were appreciative, but most said that their managers did not value that work as an important part of their jobs. Most were not explicitly rewarded for networking. The exception to this finding was in the field organization (sales and sales technical support), where the job clearly depends on knowing what is going on around the company. In that organization, those who knew many people and lots of information were publicly recognized and rewarded.

The finding that networkers are critical to information flow is consistent with that of others who looked at work processes in smaller organizations. Workplace field studies on a customer support group [Ehrlich & Cash, 1994], and a CAD design group [Gantt & Nardi, 1992], for example, have shown that certain people tend to become (formal or informal) focal points for information, and that others in the organization depend on their skills in collecting, synthesizing, and distributing information.

These observations, combined with the literature on unintended interactions, led us to explore ways of using our networked computing technology to address these issues in organizational information flow. Supporting and improvingthe effectiveness of word-of-mouth in a distributed organization emerged as a major theme. We investigated ways of enabling people to encounter others in the computational workspace and to easily initiate interactions. Also, we considered ways to let networkers know how their information spread and affected others. We also wanted to address the limitations of previous efforts that supported this kind of interaction in isolated applications or situations. Instead, we wanted to integrate this support to users' activities throughout the desktop. Therefore, we focused on making communication support available as a desktop-wide facility that may be integrated with any application, enabling users to remain aware of and contact others as they move from task to task on their desktops.

Piazza: Enabling Spontaneous Interactions on the Desktop

Piazza's approach is to use networked computers to provide opportunities to encounter others through tasks and activities accomplished on-line. As people go about their tasks, they can see who else is working on similar tasks. In many cases, users may simply note that someone else is "nearby" without contacting them. But every now and then, they may contact someone nearby to ask a question, find out about the other person's work, or generally coordinate activity. Piazza is integrated into the desktop, so people are able to stay aware of others as they go about their usual activity, moving from application to application.

In Piazza, people are considered to be working "nearby" in the strictest sense when they are looking (1) at the same data (2) at the same time (3) using the same application. These three dimensions may be relaxed to gain a broader notion of nearby. Two people may be looking at the same data in different applications (e.g., viewing the same Web page from different browsers), using the same application to manipulate different data (e.g., using the same spell checker on different documents), or looking at the same data at different times (e.g., reading the same e-mail message within a half hour of another). The definition of nearby is determined by the class of application.

Piazza addresses the major concerns with previous work in the following ways: Because it is integrated into the desktop, users do not have to go to an isolated place to interact; it is always there as they go about their work. The shared task gives people a context from which reasons to interact may naturally arise. The design makes it easy for people to enter into interactions once they see each other. And finally, in a distributed environment, interactions between remote colleagues become as likely as those between co-located ones, without having to specify the set of people they can encounter.

Piazza consists of five components. Some are "stand-alone" applications and others are components to be added to other applications, but all are integrated with each other and with other desktop applications. The components are:

Encounter, which enables people to be aware of and easily contact other people who are conceptually "nearby."
Gallery, which enables people to stay aware of and easily contact a pre-selected group of people with whom they work more closely.
People Browser, which enables people to get information about or contact anyone else in the community.
Glance, which enables people to make audio-video connections to others they see in Encounter, Gallery, or the People Browser.
Project Rooms, which allow people to congregate in one place to conduct audio/video/text discussions or meetings, supplemented by documents and other shared material.

So far, we have completed a design specification for all the components, and have implemented the core features of Encounter, Gallery, and People Browser in the OpenStep(tm) desktop. We explain each component in more detail and discuss some of the design issues raised.

Encounter

Encounter is a desktop component that may be included in any application. It enables users of that application to be aware of others who are nearby. If, for example, a Web browser incorporated Encounter, a user would be able to see other people who were looking at the same page at the same time. If they then moved on to an Encounter-aware file browser, they would see who else was looking at the same directory. As the user moves from application to application, their Encounter window updates to show who is nearby to their current task. The intention is to give users a background sense of who is "there" as they go about their tasks. In most cases, they will simply note the presence of others but not actively interact with them. However, every once in a while, they may decide to contact someone they see as they go about their work, just as they do in shared physical settings.

Figure 1a shows a snapshot of an Encounter window associated with the current application, the OpenStep editor. It shows that the current user (the person in the upper right) and two other people are viewing the document at this time. Figure 1b shows what happens when that user opens a mail message. Now his Encounter window is associated with the mail message, and he can see that another recipient of the message is currently reading it.

Figure 1a

Figure 1b

Figures 1a and 1b. Snapshots of Encounter associated with two applications. In Figure 1a the user opens a document and sees that two others are also viewing it. One is idle and the other is actively using his computer. (The user's image is at the top right.) In Figure 1b the user moves to a mail message and sees that one other person is viewing the message.

The small images in the Encounter window are intended to be unobtrusive but to give some basic information about nearby users. In particular, the images indicate at a glance whether the person has been actively using their computer. If they are active, their image is facing outward looking "alert" (e.g. the bottom left image in Figure 1a). If they have been idle for more than 30 seconds, then their image is looking down and to the side, as if their attention is elsewhere (e.g. top left in Figure 1a). If they are interacting on-line with someone else, their image is turned to the side, speaking and with a "talk bubble" over their heads (e.g. bottom left image in Figure 4). When someone moves from one state to another, a subtle sound announces the change, and their representation slowly fades from one image to another.

At the bottom of Encounter is a shared text area that can be used for a lightweight group discussion. As people type, their words appear in the text area, and anyone else in that Encounter can see it. For example, a user may ask whether anyone has read a file in a directory being viewed, and if so, those people may choose to open an audio-video connection. Or the interaction may remain in the shared text area, much like a chat room interaction.

If users want more specific information about someone in their Encounter, they can select the person's image and see how long that person has been active or idle, or with whom they are interacting. They can also select one of the buttons at the bottom of the Encounter window to get even more information or to interact with the person (see Figure 1). The left button initiates an audio-video connection with that person (discussed in the Glance section). The middle button brings up a Stickup note, which they can use to type a message and post to the other person's screen. The right button brings up that person's representation in the People Browser, which has more information about them and provides more ways to contact them. This component is discussed further in the People Browser section.

Currently, Encounter images are static. However, should many people have cameras and should network bandwidth allow, these images could be video images, updating at a rate appropriate to the network and to users' preferences.

Privacy

Any application intended to provide background awareness of others needs to enable users to protect their privacy. Encounter does this by providing three other modes in addition to the standard mode just described. If a user does not want to see and be seen by others, they can "minimize" their Encounter. Doing so removes the Encounter window, but the user is still given an indication when at least one other person is nearby as they move from application to application. The header of each application shows a silhouette of a person (see Figure 2). When others are nearby, the silhouette is filled-in, when they are not the silhouette is hollowed-out. Also, when someone arrives or leaves, a subtle sound indicates the change in state.

Figure 2. Design sketches of Encounter in the minimizedstate. The filled-in state indicates that others are nearby,the hollowed-out one shows that no one is nearby.

In addition, users who have their Encounter minimized appear in others' Encounters as a silhouette, indicating that the person prefers not to be bothered (see lower left image in Figure 3). A user who sees a silhouette can click on it to find out who it is, and they may choose to try to contact them, but they do so knowing the person is requesting privacy. This decision would be like choosing to knock on a closed office door. The user might choose to send a Stickup rather than glance someone who appears as a silhouette.

Figure 3. Design sketches of Encounter in the expanded state, used for large gatherings. Users can flip between the two views to see the faces of people viewing the same event or to view names and search for and sort them.

In addition, Encounter may appear in an expanded state, shown in Figure 3, which is intended to be used when a large group of people are nearby. For example, an on-line video presentation may be attended by dozens or hundreds of people, which would overwhelm the small version of the Encounter window. The user can switch between two views of the expanded Encounter. One view shows a scrolling matrix of images of the people attending, and the other shows a list of the names. The names list can be searched or sorted to make it easier to keep track of certain people.

Finally, a user could simply opt to turn off their Encounter, in which case their image would not be seen by others and they would not be aware of anyone else. Users may decide which level of awareness they prefer on a desktop-wide basis or on a per-application basis.

Gallery

In addition to the Encounter component, which allows people to "run into" others, the Gallery component lets users remain aware of a predefined set of people. Each person populates their Gallery with people they want to track, most likely their team members and other close colleagues. Much like Portholes, the Gallery remains on the desktop, giving users a low-level awareness of their co-workers' level of activity and the ability to quickly contact them. Figure 4 shows an example of a Gallery. The Gallery operates much like Encounter in that it shows who is actively using their computer, who is interacting with others, and who is idle. It also provides the same mechanisms to contact or get information about those people. In addition, Gallery may be used to gain access to certain Project Rooms, discussed later. In Figure 4, the user has included the COCO ProjectRoom in her Gallery so she may quickly go there at anytime. The image also indicates whether anyone else is currently in the Project Room, so the user may choose to join simply because she sees that others are there.

Figure 4. Snapshot of a Gallery. The top left and lowermiddle person are actively using their computers, the upper middle and right are idle, and the lower left is talking to someone else. The lower right slot provides access to a Project Room.

The intention of the Gallery is to give members of a distributed group a feeling of awareness similar to that shared by co-located groups. Over the course of the day, they will have an idea who was working in their offices, who was out for the day, who might have had many meetings, and so on. Kraut, Egido, & Gallagher [1990a] showed that the great majority of interactions that happen at the workplace occur between people located on the same hall. Gallery tries to extend that "hall" to include others who maybe doing closely related work but are not physically nearby.

Users may also choose to replace their own image with another one, for example one indicating they are out of the office, do not want to be disturbed, working at home, etc. If a user's Encounter is in the minimal state, then their Gallery image also indicates that they do not want to be disturbed, although they can override that state. Someone may not want to be aware of others doing similar tasks, while still wishing to remain accessible to their closer colleagues.

People Browser

So far we have discussed ways that people may "run into" others who are viewing the same application and ways that people can either stay aware of or explicitly contact someone in their Gallery. The People Browser allows people to contact someone who is not in their Gallery and does not happen to be in their Encounter. It also allows users to get more information about others.

The People Browser by default contains the full set of people available to a user (e.g. the entire organization). It also provides a way to add others, for example, colleagues from other institutions. Figure 5 shows a snapshot of the People Browser, on the left. In this case, the user has chosen a person and has brought up her business card, shown on the right. The buttons at the bottom of the Browser enable the user to check that person's calendar, send her a Stickup, e-mail her, glance her, view her World Wide Web home page, or view her business card. The intention is that members of a community would enable access in the media available in and most appropriate to that community. The card provides information about the person's title, department, postal address, office number, manager's name, and so on. Each user provides information about themselves, so they may control what information others can retrieve about them.

Figure 5. Snapshots of the People Browser, left, and a person's information card, right, which was launched from the right-most button of the People Browser.

The People Browser and Glance (described next) also serveas desktop components that are easy to incorporate into any application that deals with users. For example, a printing application could display a list of print jobs, each with a picture of the job owner. Double clicking on the picture would bring up the People Browser with that person selected.

Glance

Encounter, Gallery, and People Browser provide easy access to Glance, which enables audio-video connections between desktops. If a user sees someone they would like to talk with, they select that person and "glance" them. If both parties have video equipment, an audio-video connection is made. If one or more person has only audio, the connection includes only audio from those participants. In place of the video is a static image of the person. The goal of this design is to enable broad participation among users with a range of equipment. We also hope to allow those who have only audio to manually switch their image to one of a selection that express such reactions as puzzlement, disagreement, approval, amusement, etc.

Figure 6. Design sketch of a three-way video glance.

The Glance mechanism is similar to that of Montage [Tang & Rua, 1994]. To glance someone, the user selects the person's image and clicks the Glance button. The person being glanced hears an approach sound and the image of the person glancing fades onto their screen. If they would like to interact, they join the interaction and audio is enabled. (See Figure 6 for an example of a three-way glance.) In addition to the images of the participants, Glance includes a shared text area and access to Stickups. Because the OpenStep text widget supports compound objects, users can drop other files into the text region to share those files. When a glance ends, the shared text area disappears along with the images, but any Stickups that were posted remain on the recipients' desktops. Glance supports multi-way interactions. If a user sees in Encounter that two people are interacting, they can join the interaction by selecting one or both of the people and glancing them. Those in the glance hear an approach sound and see the newcomer fade in. They can allow that person to join or not. Once fully implemented, we hope to enable as many as five-way connections.

If a glance indicates that the person is not available (e.g., they are on the phone or not in the office), the user can leave a Stickup message, check the person's calendar to see when they might be back, or send e-mail. Our study of Montage showed that about 75% of attempts to glance others were initially unsuccessful in that the person was not there or was not available for an interaction [Tang, et. al, 1994]. In Piazza's design, the user has an initial indication of whether the person is available, so we expect fewer unsuccessful glances. A user may choose to send a Stickup to someone who has been idle for two hours rather than trying to glance them. Or they may wait to glance the person until they see the person is active.

Project Room

Project Rooms are places where groups can congregate to have discussions or meetings and to store material of interest. Project Rooms are intended to be used in at least two ways, visualized in Figure 7. In Figure 7a, the room is being used to discuss a topic of interest to the group. The images at the top represent the people in the room. There is an audio connection among those people and those with video appear as live video images. The text region supports the voice connections and allows the participants to hold spontaneous votes during the discussion. At the bottom are two documents relating to the topic that users may want to view during the discussion. The discussion may occur overtime with people coming and going at different times, or it may occur as a meeting with a fixed start and end time.

Figure 7. Design sketches of two views of a project room. In 7a, left, the project room is being used to hold a group discussion. In 7b, right, it is being used to store documents shared by a group and to post announcements, although people may have interactions if they are visiting at the same time.

Figure 7b visualizes the use of a Project Room as a storage area for a project group. The intention is for group members to go to the Project Room to store and retrieve documents of shared interest (thus the storage area is expanded to accommodate the documents). When people visit the room, they may encounter others in their group also looking at shared information, in which case they can easily have an audio-video conversation. When someone updates a document or leaves a new one, they may use the text area to announce the change to the group (as George has done). In addition, the group may decide to "meet" in the Project Room at a certain time to have a meeting.

Users can create or join Project Rooms from a Project Room Browser, which shows a list of Project Rooms currently in use with short descriptions of each. Users can also enter or create Project Rooms from Encounter, Gallery, or from a Glance. Suppose two people run into each other while reading a company-wide e-mail about a change in their benefits policy. One glances the other and they begin to discuss the topic. They decide they would like others to join the discussion, so they create a Project Room. When others read the message, they see an icon in their Encounter that lets them join that Project Room.

Alternatively, the person who sent the message about the benefits change can announce that they will be in a Project Room during a specific time range and include an attachment in the message that takes users there. This feature allows someone to make a formal announcement, but still be available for "word-of-mouth" discussion where they can guide people's understanding of the announcement.

Implementation

Piazza is currently under development. The standard size of Encounter is nearly finished and has been integrated with several applications, but the expanded and minimized state have not been implemented. Gallery and People Browser are largely complete, Glance is in the early stages of development, and Project Rooms have not been started.

Piazza is implemented in the OpenStep(tm) environment on Solaris(tm). Central to its implementation are distributed People Objects, which store the available information about a person. All the other Piazza components visualize the information in the People Object in different ways. Encounter also uses a distributed architecture. Each application links in an Encounter proxy, which it notifies any time the user changes location. The proxy contacts the user's server, which multicasts that new location to all other Encounter servers. Each application determines which users are nearby its own user. Glance, Stickup, and the People Browser are implemented as services that can be accessed by other applications.

Supporting Enterprise-wide Communication

Having described the details of Piazza, we return to the motivation for its design to consider how we attempted to address the issues raised. Our primary goal was to make it possible to have opportunistic and spontaneous interactions with other members of a large distributed community. Piazza attempts to do so by allowing people to see who else is "nearby" (i.e., working on a similar task at about the same time) and then to naturally transition into an interaction through video, audio, text, or whatever medium is available. By allowing people to see others doing similar tasks, there should be enough context for people to start up lightweight, impromptu interactions.

Another goal was to make it easier for members of a large community to distribute information in the way that people most like to receive it. Our interviews showed that people like to get information by word of mouth, but that distributors of information are suspicious of this mechanism. The Project Rooms were largely inspired by this problem, although we think Piazza's other mechanisms may also play a role. In particular, the Project Rooms were designed to make it easy to disperse a message using relatively formal mechanisms (documents, Web pages, e-mail messages), while still providing a way to talk informally with people who are interested in the message. Someone can announce the availability of a document and then "hang around" to answer questions and participate in discussions as people come across the information at their own pace. In addition, the author of a document could choose to always appear in the Encounter of someone viewing it, again making it easy for people to ask the source about the information, either by starting a conversation orsending a Stickup or e-mail message.

In such an environment, it is possible that networkers maybe better able to demonstrate to management the value oftheir activities because they would be more aware of how the information assisted others. Although not implemented, it would also be possible to allow people to document the number of people visiting the information. We cannot be certain whether such benefits will arise, of course, until the system is well used and tested, which we expect to happen in the upcoming months.

Issues for Study

Piazza is still under development, but when it becomes more fully implemented, we plan to deploy it within a broad community and conduct a formal use study. In that study, we hope to learn more about the types of interactions initiated through the components (Encounter, Gallery, People Browser and Project Rooms) and whether they differ in interesting ways. We are especially interested to learn whether it is possible to enable unintended interactions in a way that is useful and that strengthens the sense of community among a distributed group. We would like to compare Piazza-based unintended interactions to those that occur among co-located groups to learn whether they happen as frequently and serve a similar purpose.

In addition, we will explore the following specific issues that are raised by Piazza's approach to community-oriented communication.

Task-based encounters.

Unlike previous systems, unintended encounters in Piazza are based around tasks, rather than locations. We would like to learn whether a common task provides enough of a reason for people to occasionally contact others, even if they are strangers. Just as people routinely ask for help of strangers located near the source of confusion (e.g. asking for help with a jammed copier), we would like to know whether it is equally acceptable to ask a stranger who is using the same on-line application how to complete an unfamiliar task.

Scoping.

Clearly, the Encounter and Project Room Browsers will need to be scoped to include a reasonable portion of the larger community. If all the Web browsers of the world were to include Encounter and be scoped to the world, then users would see far too many strangers everytime they looked at a popular page. On the other hand, the scope of Encounter should not be so small that people rarely run into others and therefore do not come to feel part of the distributed community. We expect that different applications and different data sources will be scoped differently, but we need more experience to learn the best approach.

Distributing information.

We are interested to learn whether disseminators of information will use Project Rooms to announce their news and handle informal queries. We also would like to learn whether an established on-line forum for dispersing information will change management's view of the value of organizing and spreading information. If managers do not currently value networkers' activities, then they may consider Project Rooms an easier way to "waste time." Alternatively, Project Rooms may enable networkers to formally document the value of their service.

Asymmetric interactions.

To enable participation within a large community, Piazza is designed to support people with audio-video equipment, audio only, and perhaps even text-only capabilities. However, we are curious whether this arrangement will motivate people without video equipment to acquire it. Our experience has been that, although many people like video, they cannot justify its expense until they see a particular need, and they often do not see a need because they do not have the equipment. We want to see whether asymmetric interactions make the need obvious.

Over the next few months, we expect to explore these issues and others as we complete Piazza's development and study its use across a broad community. We hope that Piazza will make a significant step toward the difficult problem of enabling lightweight, impromptu interactions among members of a widely distributed organization.

References

1. Abel, M.J. (1990). Experiences in an exploratory distributed organization, In J. Galegher, R. Kraut & C. Egido,(Eds.), Intellectual Teamwork, Hillsdale, NJ: Lawrence Erlbaum, 489-510.

2. Bly, S.A., Harrison, S.R. & Irwin, S. (1993) Media spaces:B ringing people together in a video, audio, and computing environment, Communications of the ACM, 36:1, 28-47.

3. Curtis, P. (1992) Mudding: Social phenomena in text-based virtual realities, Proceedings of the 1992 Conference on Directions and Implications of Advanced Computing, Berkeley.

4. Dourish, P. & Bly, S. (1992). Portholes: Supporting awareness in a distributed work group. Proceedings of the Con-ference on Computer-Human Interaction (CHI), Monterey, CA: ACM Press, 541-547.

5. Erhlich, K. & Cash, D. (1994). Turning Information Into Knowledge: Information Finding as a Collaborative Activ-ity, Proceedings of Conference on Processing of Digital Libraries, College Station, TX, 119-125.

6. Finholt, T., Sproull, L. & Kiesler, S. (1990). Communication and performance in ad-hoc task groups. In J. Galegher, R. Kraut & C. Egido, (Eds.), Intellectual Teamwork. Hillsdale, N.J.: Lawrence Erlbaum, 291-325.

7. Fish, R., Kraut, R., Root, R. & Rice, R. (1993). Video as atechnology for informal communication. Communications of the ACM, 36:1, 48-61.

8. Gantt, M. & Nardi, B. A. (1992). Gardeners and Gurus: Patterns of Cooperation Among CAD Users, Proceedings of the Conference on Computer-Human Interaction (CHI), Monterey, CA: ACM Press, 107-117.

9. Granovetter, M. (1973). The strength of weak ties, American Journal of Sociology, 78, 1360-1380.

10. Hiltz, S.R. & Turoff, M. (1985) Structuring computer-mediated communication systems to avoid information overload, Communications of the ACM, 28:7, 680-689.

11. Isaacs, E.A. Morris, T., & Rodriguez, T.K. (1994), (A Forum for supporting interactive presentations to distributed audiences. Proceedings of the Conference on Computer-Supported Cooperative Work (CSCW), Chapel Hill, NC: ACM Press, 405-416.

12. Isaacs, E.A., Morris, T. Rodriguez, T.K & Tang, J.C. (1995). A comparison of face-to-face and distributed presentations. Proceedings of the Conference on Computer-Human Interaction, Denver, CO: ACM Press, 354-361.

13.Isaacs, E.A., Whittaker, S., Frohlich, D., & O'Conaill, B. 1997. Informal communication re-examined: Newfunctions for video in supporting opportunistic encounters.In K. Finn, A. Sellen, & S. Wilbur, Video-Mediated Communication, Mahwah, NJ: Lawrence Erlbaum.

14. Kraut R.E., Egido C. & Galegher J. (1990a) Patterns of contact and communication in scientific research collaboration. In J. Galegher & R. Kraut (Eds.) Intellectual teamwork, Hillsdale, NJ: Erlbaum, 149-171.

15. Kraut, R.E., Fish, R.S., Root, R.W. & Chalfonte, B.L.(1990b). Informal communication in organizations: Form, function, and technology, in S. Oskamp & S. Spacapan (Eds.), People's Reactions to Technology, Newbury Park:Sage Publications, 145-199.

16. Kraut, R.E. & Streeter, L.A. (1995). Coordination in software development, Communications of the ACM, 38:3, 69-81.

17. Morningstar, C. & Farmer, F.R. (1991). The lessons of Lucasfilm's Habitat, Cyberspace, Michael Benedikt, Ed., Cambridge: MIT Press, 273-301.

18. Nelson, R. & Mathews, K.M. (1991). Network characteristics of high-performing organizations, Journal of Business Communications, 28:4, 367-386 Proceedings of the Conference on Computer-Supported Cooperative Work, Toronto: ACM Press, 91-98.

20. Stefik, M., Foster, G., Bobrow, D.G., Kahn, K., Lanning,S. & Suchman, S. (1987) Beyond the chalkboard: Computer support for collaboration and problem solving in meetings, Communications of the ACM, 30:1, 32-47.

21. Suchman L. & Wynn E. (1984). Procedures and problems in the office. Office: Technology and People, 2, 133-154.

22. Tang, J.C., Isaacs, E.A. & Rua, M. (1994). Supporting distributed groups with a Montage of lightweight interactions. Proceedings of the Conference on Computer-Supported Cooperative Work (CSCW), Chapel Hill, NC: ACM Press, 23-34.

23. Tang, J.C. & Rua, M. (1994). Montage: Providing tele-proximity for distributed groups, Proceedings of the Con-ference on Computer-Human Interaction, Boston, MA: ACM Press, 37-43.

24. Whittaker, S., Frohlich, D. & Daly-Jones, O. (1994). Informal workplace communication: What is it like and how might we support it?, Boston, MA: ACM Press, 131-137.

25. Whittaker, S. & Sidner, C. (1996). Email overload: explo-ing personal information management of email, Proceedings of the Conference on Computer-Human Interaction, Vancouver: ACM Press, 276-283.

(1) Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post servers or to redistribute to lists, requires prior specific persmission and/or a fee.
Copyright 1996 ACM