Piazza: A Desktop Environment Supporting

Impromptu and Planned InteractionsEllen A. Isaacs, John C. Tang, and Trevor Morris

SunSoft2550 Garcia Avenue

Mountain View, CA 94043-1100, USATel: 415336-1 167; 415 336-1636; 415336-3097

E-mail: ellen.isaacs@sun.tom; john.tang@sun.tom; trevor.morris@sun. com

ABSTRACTMuch of the support for communication across distributedcommunities has focused on meetings and intentional con-tact. However, most interactions within co-located groupsoccur when people happen to run into each other. Suchunintended interactions should also be supported amongdistributed communities. We conducted a study of the com-munication patterns of a large, distributed organization andfound that people tend to disseminate information using for-mal techniques, even though people usually receive infor-mation 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 adchessing the problems revealed in our study. Piazzaallows people to be aware of others who are doing similartasks when they are using their computers, the~by enablingunintended interactions. It also supports intentiomd contactsand planned meetings. We discuss issues for analysis in anupcoming use study.

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

INTRODUCTIONThe popuhuity of the World Wide Web has highlighted thevalue of transferring information anywhere, anytime overthe network. As organizations embrace sites located aroundthe globe, users of mobile computing devices, andtelecommuters working from home, they have come to relyon rapidly improving network connections to handle theinformation needed to run their business. So far, thesenetworks have largely been used as an efficient way to shiparound data, as exemplified by the Web. However, to nxtoma sense of community to distributed workers, we shouldthink of using the network to enable the rich communicationopportunities afforded by physical workplaces.

Research and development efforts to support synchronouscommunication so far have mainiy explored the use ofnetworked computers to help people explicitly contact other

ComputerSupportedCooperativeWork ’96, Cambridge MA USA@1996 sun Mi~r~~ysteMs Inc. ,411rights reserved.

individuals and groups. For example, desktop videoconferencing and media spaces have been designed to helppeople contact others for impromptu conversations lllly, et.al, 1993; Fish, et. al, 1993], and meeting support softwarehas been developed to help groups hold pre-arrangedm~tings (e.g. ShrEdit, Colab, Forum) [Olson, et. al, 1992;Steiik et al., 1987; Isaacs, et. al, 19941.

However, a small body of literature has begun to focus onthe importance of interactions that occur opportunisticallywhen people happen to see each other ~aut, et. al, 1990b;Whittaker, et. al, 1994; Isaacs, et al, in press]. When groupsare co-located, people often “run into each other” in thehalls, at the photocopier, in the cafeteria, and elsewhere. Asmall but important percentage of the time, they startconversations 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 unintendedinteractions for communities that are distributed acrossdifferent locations. In this paper, we first provide somebackground on the importance of unintended interactionsand some systems that partially support it. Then we reporton some interviews we conducted to investigate informationflow in a large distributed organization. We then describethe design of a system called Piazza that supports thevarious kinds of interactions needed to facilitate ente@se-wide information flow and communication. Finally, weconsider how Piazza’s design addresses the communicationneeds established earlier, and we describe some issues to bestudied in a future evaluation of the system.

THE ROLE OF UNINTENDED INTERACTIONSKraut, et. al [1990b] distinguished four categories ofinteractions: planned (prearranged meetings), intended(explicitly sought by one person), opportunistic (anticipatedby one party but occurring only when the parties happenedto see each other), and spontaneous (unanticipated by eitherparty). We focus on these latter two types of interactions,which we will call “unintended.” Kraut, et. al [ 1990blestimated that unintended conversations made up 52% ofthe interactions that occurred in the workplace they studied.Whittaker, et. al [1994] found that 92% of the interactionsthey observed in two office settings were not pre-mmnged,although some of those were intended. These interactionswere frequent and very short; 3190 of workers’ time was

315

spent in informal interactions, and they lasted under twominutes on average.

Previous research demonstrates the importance ofunintended interactions. Kraut, et. al [1990bl showed thatinformal interactions are responsible for much of theinformation flow in an organization. In addition, the more agroup engages in unplanned interactions, the more likely itsproject will succeed maut & Streeter, 1995]. Nonetheless,that study showed that groups tend to under-utilizeunplanned interactions compared with their effectiveness.Finholt, Sproull & Kiesler [1990] found that frequent,spontaneous interactions play an important role during theplanning and negotiation phases of projects. Furthermore,the lack of such exchanges reduces the level of coordinationand progress on projects ~aut, et. al, 1990bl. Groups thathave few informal interactions between formal meetingstend to be less productive than groups with frequentimpromptu contact, even though the former tend to havemore efficient, task-focused meetings.

Further ~search shows that groups who do not maintain so-called “weak ties” with people outside their group tend to beless productive [Granovetter, 1973; Nelson& Mathews,1991]. Weak ties are relatively low-intensity relationshipswith little mutual obligation and are maintained withinfrequent contact, most likely unintended encounters.Weak ties have been shown to promote flexibility andeffective decision making. In addition, groups withrelatively few weak ties have a tendency to negativelystereotype other groups [Nelson & Mathews, 1991]. FMy,informal office discussions are shown to be important inhelping people learn and adopt the social conventions andprocedures of a community [Suchman & Wynn, 1984].

Systems Supporting Unintended InteractionsDespite the critical role of unintended interactions, only afew software systems have included features that make itpossible to come across someone unintentionally and startup a conversation. The media space work lllly et al., 1993;Fish, et. al, 19931 highlighted the use of audio and videoconnections among distributed sites to help people noticethe work activity of others and make contact, regardless ofwhether they are down the hall or at a remote site. However,explicit attempts to support serendipitous encountersthrough this technology has so far proven to bedisappointing. The main weakness of these attempts is thatthey have brought together people who do not necessarilyhave a context or need to interact, and placed them in asituation where it is awkward to ignore each other CKraut,et.al, 1990b; Abel, 19901. One media space system that didgain acceptance is Portholes at Xerox EuroPARC. It allowedpeople to stay aware of others by viewing a matrix of slowlyupdating video snapshots of the offices of a fixed set ofpeople l?lourish & Bly, 1992]. These views could prompt auser to establish an audio-video confection with someonethey saw in Portholes.

In our previous research, we saw a hint of unplannedinteractions in Forum, which enabled live presentations to adistributed group [Isaacs, et al, 1995]. Sometimes audience

members noticed others in the audience list and exchangedtext messages. However, noticing a name in a scrolling listwas much less natural than seeing the person at a talk, andexchanging text notes was more cumbersome than leaningover to whisper to each other.

The socially rich interactions that occur in MUDs (multi-user domains) illustrate how even a text-only system cansupport unplanned interactions [Curtis, 1992]. As usersnavigate through regions in a virtual world and encounterothers (via text descriptions and commands), they are able tointeract and create complex social organizations. Morerecent graphical virtual communities [Morningstar &Farmer, 1992] add richer visual representations of placesaud people, making it easier to notice and start interactionswith others. However, these worlds tend to be disjoint fromparticipants’ “real worlds” and they occur only within aspace that the user must explicitly choose to visit.

An alternative approach to supporting unintendedinteractions is embodied in the Virtual Places work byUbique [http://www.ubique.com]. Virtual Places allowsusers to see graphical representations of others browsing thesame Web page at the same time and to open up a text oraudio chat with them. Vial Places also offers mechanismsfor navigating through Web pages together.

All these systems are a step in the right direction, but theyhave 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 aninteraction

● involve a pm-set group of people

All of these components are important. To maintain a senseof comection among a large community, people need to beable ti “happen across” a large subset of the population ona regular basis without having to go to a specific physical oron-iii locatiq have some reason to startup an interactionwith others; and enter an interaction with little effort.

So far, the research has pointed to the untapped potential ofunintended interactions in facilitating distributedcollaboration, and the challenges of applying technology tosupport them. Before designing such a system, we wanted tolearn how members of a large distributed organizationcurrently disperse and collect information.

INFORMATION FLOW IN A LARGEORGANIZATIONWe conducted a series of interviews within Sun, whichemploys about 15,000 people in six continents. Weinterviewed 12 people in different parts of the organization,many of whom had been involved in communicatinginformation to other parts of the organization. Participantsincluded a human resources manager, employee

316

communications specialists, high-level technicalprofessionals, a sales representative, a director in the CEO’soffice, a system administrator, and several managers andengineers. Interviews involved people from four sites acrossthe company.

The following are the four prominent outcomes of theseinterviews:

People disseminated information using formalmechanisms, but they retrieved information throughinformal means.People most often said they distributed information by:

● Using the formal hierarchy: People often pmented theirideas to top management and asked them to pass theinformation down the chain.

● E-mail: It was common for people to identify an appro-priate distribution list and post a message.

● Publishing documents: People often posted documentson the company’s internal Web or created a formalreport. In some cases, they pxvpared a high-quality bro-chme and sent it to everyone’s company mailbox or totheir homes (e.g., information about company benefits).

In many cases, people used more than one of thesetechniques. For example, they might make a formalpresentation to a vice president’s staff, handout a documentand send e-mail to others announcing the availability of thedocument. A few used alternative media such as videotapes,audiotapes, ur on-line audio-video presentations.

On the other hand, when asked how they retrievedinformation, people most cmmnonly said they did so by:

.

●

●

✎

Asking someone: Most people said they either walkeddown the hall aud asked someone face-to-face, sent e-mail to someone who might know the answer, or calledsomeone.

Waiting to run into someone For information lessurgent, people often waited until they saw someonewhom they expected to see in the near future, perhaps ata meeting, the cafeteria, the fitness center, etc.

Having unexpected, informal conversations: Many peo-ple found out information when they happened to seesomeone in a common area or when they walked by peo-ple’s offices.

Usimzon-line tools: Such tools included the internal Webpage:, an on-line documentation set that held the com-pany human resomces information, the on-line rolodextool, e-mail they saved, etc.

The interesting thing about these two lists is that there islittle overlap. People do not directly get information the wayothers try to convey it to them. The next finding indicatesthat 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 tomanagement never made it to the rank and file employees.When they sent e-mail, they had difficulty choosing whichmailing lists to include. When it was imperative to reachevery single employee (e. g., Human Resourcesannouncements), it was difficult to make sure everyone hadseen the information and taken appropriate action.

People were aware that large-scale e-mails or videos wereinefficient because it was difficult to convey their relevanceto all the recipients. Those who experimented with audioand video messages received mixed nx+ctions.For example,when employee communications sent out short, on-linevideos from the CEO, some recipients said the videos gavethem “the warm fuzzies” because they could see the CEO asa person and have more of a prsonal connection with him.Others, though, thought the videos were so corny and low incontent that they never watched them.

This tinding supports Kraut & %reeter’s [1995] finding thatformal techniques are over-utilized relative to their value.Our results indicate that people realize that their methodsare less effective than they would like. Given this awareness,and that people usually use word of mouth to getinformation, we wondered why people did not use word ofmouth more often to communicate their message. We found

Information disseminators are wary of word of mouth.People felt uncomfortable giving their information to othersand hoping it would spread because doing so did not letthem control the message. Also, they could not easilydetermine what impact the message was having; they couldnot see people’s immediate reactions or answer theirquestions. Finally, they felt it was hard to guaranteereaching everyone who should hear a message if theinformation is passed on informally.

When we focused on recipients’ complaints about themessages they received, we found thab

Those receiving information felt they were getting aninappropriate amount of information, and often not theright information.A common complaint was that people were getting toomuch information, but not enough analysis. E-mail wasusually the worst offender. This organization’s culture isexceptionally (some say pathologically) dependent one-mail, and people disliked getting information that appearedto have no relevance to them. But at the same time, they feltthere was a lack of information about higher-level concerns(e.g., the company’s strategy and direction). People also feltthat information, again especially in e-mail, often came at atime when it was not needed. When they did need theinformation, they had difficulty finding where they hadstored it (if they had). This information overload effect hasbeen found by others [e.g., Hiltz & Thmff, 1985; Whittaker& Sidncr, 19961.

F~ly, many people felt that the information they receivedwas not credible, especially formal, official information.

317

All-hands meetings, company-wide e-mail announcements,and formal planning presentations were cited as suspect.People said if they really wanted to know aboutSornetig.they would ask someone who they knew stayed in touchwith company issues and whose analysis they trusted.

When we explored this last point, we realized theimportance of those people who collect information andspread 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 thati

Although effective “networkera” were critical toinformation flow, they were not formally recognized.Networkers felt that collecting information helped them dotheir jobs, and that those who used the information wereappreciative, but most said that their managers did not valuethat work as an important part of their jobs. Most were notexplicitly rewarded for networking. The exception to thisfinding was in the sales and sales technical support fieldorganization, where the job clearly depends on knowingwhat is going on around the company. In that organization,those who knew many people and lots of information werepublicly recognized and rewarded.

The finding that networkers are critical to information flowis consistent with that of others who looked at workprocesses in smaller organizations. Workplace field studieson a customer support group EIhrlich & Cash, 19941, and aCAD design group [Gantt & Nardi, 19921, for example,have shown that certain people tend to become (formal orinformal) focal points for information, and that others in theorganization depend on their skills in collecting,synthesizing, and distributing information.

These observations, combined with the literature onunintended interactions, led us to explcxe ways of using ournetworked computing technology to address these issues inorganizational information flow. Supporting and improvingthe effectiveness of word-of-mouth in a distributedorganization emerged as a major theme. We investigatedways of enabling people to encounter others in thecomputational workspace and to easily initiate interactions.Also, we considered ways to let networkers know how theirinformation spread and affected others. We also wanted toaddress the limitations of previous efforts that supported thiskind of interaction in isolated applications or situations.Instead, we wanted to integrate this support to users’activities throughout the desktop. Therefore, we focused onmaking communication support available as a desktop-widefacility that may be integrated with any application,enabling users to remain aware of and contact others as theymove from task to task on their desktops.

PIAZZA: ENABLING SPONTANEOUSINTERACTIONS ON THE DESKTOPPiazza’s approach is to use networked computers to prwideopportunities to encounter others through tasks andactivities accomplished on-line. As people go about theirtasks, they can see who else is working on similar tasks. Inmany 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 outabout the other person’s work, or generally coordinate theiractivities. Piazza is integrated into the desktop, so people meable to stay aware of others as they go about their usualactivity, rowing from application to application.

In Phzza, people are considered to be working “nearby” inthe strictest sense when they are looking (1) at the same data(2) at the same time (3) using the same application. Thesethree dimensions may be relaxed to gain a broader notion ofnearby. Two people may be looking at the same data indifferent applications (e.g., viewing the same Web pagefrom different browsers), using the same application tomanipulate different data (e.g., using the same on-lineorganization chart looking at a different part of theorganization), or looking at the same data at different times(e.g., reading the same e-mail message within a half hour ofanother). The definition of nearby is determined by the classof application.

Piazza addresses the major cxmcerns with previous work inthe following ways: Because it is integrated into thedesktop, users do not have to go to an isolated place tointeract it is always there as they go about their work. Theshared task gives people a context from which reasons tointeract may naturally arise. The design makes it easy forpeople to enter into interactions once they see each other.And finally, in a distributed environment, interactionsbetween remote colleagues become as likely as thosebetween co-located ones; users do not have to specify the setof people they can encounter.

Piazza consists of five components. Some are “stand-alone”applications and others are components to ke added to otherapplications, but all are integrated with each other and withother desktop applications. The components are:.

.

.

●

✎

Encounter,which enables people to be aware of and eas-ily contact other people who are conceptually “nearby.”

Gallery, which enables people to stay aware of and eas-ily contact a pre-selected group of people with whomthey work more closely.

People BrowseC which enables people to get informationabout or contact anyone else in the community.

GZance, which enables people to make audio-video con-nections to others they see in Eucounter, Gallery, or thePeople Browser.

Project Rooms, which allow people to congregate in oneplace to conduct audio/video/text discussions or meet-ings, supplemented by documents and other sharedmaterial.

So far, we have completed a design spedication for all thecomponents, and have implemented the core features ofEucounter, Gallery, and People Browser in the OpenStepTMdesktop. We explain each component in more detail anddiscuss some uf the design issues raised.

318

EncounterEncounter is a desktop component that maybe included inany application. It enables users of that application to beaware of others who are nearby. If, for example, a Webbrowser incmporated Encounter, a user would be able to seeother people who were looking at the same page at the sametime. If they then moved on to an Encounter-aware filebrowser, they would see who else was looking at the samefolder. As the user moves from application to application,their Eucounter window updates to show who is nearby totheir current task. T’heintent is to give users a backgroundsense of who is “there” as they go about their tasks. Inmostcases, they will simply note the presence of others but notactively interact with them. However, every once in a while,they may decide to contact someone they see as they goabout their work, just as they do in shed physical settings.

Figure 1a shows a snapshot of an Encounter windowassociated with the current application, the OpenStep editor.It shows that the current user (the person in the upper right)and two other people am viewing the document at this time.Figure lb shows what happens when that user opens a mailmessage. Now his Encounter window is associated with themail message, and he cau see that another recipient of themessage is currently nxling it.

The small images in the Encounter window are intended tobe unobtrusive but to give some basic information aboutnearby users. In particular, the images indicate at a glancewhether 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 la). If they havebeen idle for more than 30 seconds, then their image islooking down and to the side, as if their attention iselsewhere (e.g. top left in F@ue la). If they are interactingon-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 fromone state to another, a subtle sound announces the change,and their representation slowly fades from one image toanother.

At the bottom of Encounter is a shared text area that can beused for a lightweight group discussion. As people type,their words appear in the text area, and anyone else in thatEucounter can see it. For example, a user may ask whetheranyone has read a file in a directory being viewed, and if so,those people may choose to oDen an audio-videoConnection.-or the ~teraction may r~main in the shared textarea. much like a chat room interaction.

If users want more speeific information about someone intheir Encounter, they can select the person’s image and seetheir name and how long they have been active or idle, orwith whom they are interacting. (In Figure 1, the bottom leftimage is selected, i.e. pressed in, and the name and activetime appears below.) They can also select one of the buttonsat the bottom of the Encounter window to get moreinformation or to interact with the person. The left buttoninitiates an audio-video connection with that person(discussed in the Glance section). The middle button bringsup a Stickup note, which they can use to type a message andpost to the other person’s screen. The right button brings upthat person’s representation in the People Browser, whichhas more information about them and provides more waysto contact them. This component is discussed further in thePeople Browser section.

Currently, Encounter images are static. However, shouldmany people have cameras and should network bandwidthallow, these images could be video images, updating at arate appropriate to the network and to users’ preferences.

Privacyhy application intended to provide background awarenessofothers needs to enable users to protect their pnvsey. TheEncounter does this by providing three other modes inaddition to the standard mode just described. If a user doesnot 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 oneother person is nearby as they move from application toapplication. The header of each application shows a

## Utilities$

sub ussge {print “Ussge: log [-d] [-mail,

,,:,exit;

}

rechecked in the code? ‘$%~ # :,,,# Aryument processing

Sscale = 1;.,,

whiI-e (SARGV[ 01 =-. /--11 ( .:$fiag = ihift(@Aac%j; - ~if (Sflsg eq “-d”) { \

%~qs .= “ +“ :,.,. ,,,,..,,., .,

Figure 1. Snapshotsof Encounterassociatedwith two applications.In Figure 1a, left, the user opens a documentand sees thattwo othersare also viewingit. One is idle and the other isactively usinghk computer.(The user’kimage is at the top right.) In Figure 1b, right,the user movesto a mail message and sees that one other personisviewingthe message.

319

silhouette of a person (see Figure 2). When others arenearby, the silhouette is filled-in, when they are not, thesilhouette is hollowed-out. Also, when someone arrives orleaves, a subtle sound indicates that change in state.

Figure 2. Design sketchesof Encounterinthe minimizedstate. The filled-instate indicatesthat others are nearby,the hollowed-outone showsthat no one is nearby.

In addition, users who have their Encounter minimizedappear in others’ Encounters as a silhouette, indicating thatthe person prefers not to be bothered (see lower left image inFigure 3). A user who sees a silhouette can click on it to findout 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 closedoffice door. The user might choose to send a Stickup ratherthan glance someone who appears as a silhouette.

Figure3. Design sketchesof Encounterin the expandedstate, usedfor large gatherings.Useracan flip betweenthetwo viewsto see the faces of peopleviewingthe sameevent 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 alarge group of people are nearby. For example, an on-linevideo presentation may be attended by dozens or hundredsof people, which would overwhehn the small version of the

Encounter window. The user can switch between two viewsof the expanded Encounter. One view shows a scrollingmatrix of images of the people attending, and the othershows a list of the names. The names list can be searched orsorted 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 andthey would not be aware of anyone else. Users may decidewhich level of awareness they prefer on a desktop-wide orper-application basis.

GalleryIn addition to the Encounter component, which allowspeople to “run into” others, the Gallery component lets usersremain aware of a predeiined set of people. Each personpopulates their Gallery with people they want to track, mostlikely their team members and other close colleagues. Muchlike Portholes, the Gallery remains on the desktop, givingusers a low-level awareness of their co-workers’ level ofactivity and the ability to quickly contact them. Figure 4shows an example of a Gallery. The Gallery operates muchlike Encounter in that it shows who is actively using theircomputer, who is interacting with others, and who is idle. Italso provides the same set of buttons that enable users tocontact or get information about those people. Jn addition,Gallery may be used to gain access to certain ProjectRooms, discussed later. In Figure 4, the user has includedthe COCO Project Room in her Gallery so she may quicklygo there at any time. The image also indicates whetheranyone else is currently in the Project Room (again, viasolid or hollow icons), so the user may choose to join simplybecause she sees that others are there.

Figure 4. Snapshot of a Gallery.The top left and lowermiddle person are activelyusingtheir computers,theupper middle and rightare idle,and the lowerleft is talk-ing to someone else. The lowerrightslot providesaccess to a Project Room.

.m. nJLU

The intention of the Gallery is to give members of adistributed group a feeling of awareness similar to thatshined by co-located groups. Over the course of a day, userswill have an idea who was working in their offices, who wasout for the day, who might have had many meetings, and soon. Kraut, Egido, & Gallagher [1990a] showed that the greatmajority of interactions that happen at the workplace occurbetween people located on the same hall. Gallery tries toextend that “hall” to include others who may be doingclosely related work but are not physically nearby.

Users may also choose to replace their own image withanother one, for example one indicating they are out of theoffice, do not want to be disturbed, working at home, etc. Ifa user’s Encounter is in the minimal state, then their Galleryimage also indicates that they do not want to be disturbed,although they can override that state. Someone may notwant to be aware of others doing similar tasks, while stillwishing to remain accessible to their closer colleagues.

People BrowserSo far we have discussed ways that people may “run into”others who are viewing the same application and ways thatpeople can either stay aware of or explicitly contactsomeone in their Gallery. The People Browser allows peopleto contact someone who is not in their Gallery and does nothappen to be in their Encounter. It also allows users to getmore information about others.

The People Browser by default contains the full set ofpeople available to a user (e.g. the entire organization), Italso provides a way to add others, for example, colleaguesfrom other institutions. Figure 5 shows a snapshot of thePeople Browser, on the left. In this case, the user has chosena person and has brought up her business card, shown on theright. The buttons at the bottom of the Browser enable theuser 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 acommunity would enable access in the media available inand most appropriate to that community. The card providesinformation about the person’s title, department, postal ‘

address, office number, manager’s name, and so on. Eachuser provides information about themselves, so they maycontrol what information others can retrieve about them.

The People Browser and Glance (described next) also serveas desktop components that are easy to incorporate into anyapplication that deals with users. For example, a printingapplication could display a list of print jobs, each with apicture of the job owner. Double clicking on the picturewould bring up the People Browser with that personselected.

Glance

Encounter, Gallery, and People Browser provide easy accessto Glance, which enables audio-video connections betweendesktops. If a user sees someone they would like to talkwith, they select that person and “glance” them. If bothparties have video equipment, an audio-video connection ismade. If one or more person has only audio, the connectionincludes only audio from those participants. In place of thevideo is a static image of the person. The goal of this designis to enable broad participation among users with a range ofequipment. We also hope to allow those who have onlyaudio to manually switch their image to one of a selectionthat express such reactions as puzzlement, disagreement,approval, amusement, etc.

The Glance mechanism is similar to that of Montage mang& Rua, 1994]. To glance someone, the user se~cts th;person’s image and clicks the Glance button. The personbeing glanced hears an approach sound and the image of theperson glancing fades onto their screen. If they would like tointeract, they join the interaction and audio is enabled. (SeeFigure 6 for an example of a three-way glance.) In additionto the images of the participants, Glanw includes a sharedtext area and access to Stickups. Because the OpenStep textwidget supports compound objects, users can drop otherfiles into the text region to share those files. When a glanceends, the shad 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

Figure5. Snapshotsof the People Brows(most buttonof the People Browser.

er, left, and a person’sbusinesscard, right,whichwas launchedfrom the right-

321

sees in Encounter that two people are interacting, they canjoin the interaction by selecting one or both of the peopleand glancing them. Those in the glance hear an approachsound and see the newcomer fade in. They can allow thatperson to join or not. Once fully implemented, we hope toenable as many as five-way connections.

Figure 6. Design sketchof a three-wayvideo glance.

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 leavea Stickup message, check the person’s calendar to see whenthey might be back, or send e-mail. Our study of Montageshowed that about 75?40of attempts to glance others wereinitially unsuccessful in that the person was not there or wasnot available for an interaction [Tang, et. al, 1994]. InPiazza’s design, the user has an initial indication of whetherthe person is available, so we expect fewer unsuccessfulglances. A user may choose to send a Stickup to someonewho has been icllefor two hours rather than trying to glancethem. Or they may wait to glance the person until they see

Project RoomProject Rooms are places where groups can congregate tohave discussions or meetings and to store material ofinterest. Project Rooms are intended to be used in at leasttwo ways, visualized in Figure 7. In Figure 7a, the room isbeing used to discuss a topic of interest to the group. Theimages at the top represent the people in the room. There isan audio comection among those people and those withvideo appear as live video images. The text region providestext chat functionality and allows the participants to holdspontaneous votes during the discussion. At the bottom aretwo documents relating to the topic that users may want toview during the discussion. The discussion may occur overtime with people coming and going at d~erent times, or itmay occur as a meeting with a fixed start and end time.

Figure 7b visualizes the use of a Project Room as a storagearea for a pro~t group. The intention is for group membersto go to the Project Room to store and retrieve documents ofshared interest (thus the storage area is expanded toaccommodate the documents). When people visit the room,they may encounter others in their group also looking atshared information, in which case they can easily have anaudio-video conversation. When someone updates adocument or leaves a new one, they may use the text area toarmounce the change to the group (as George has done). Inaddition, the group may decide to “meet” in the ProjectRoom at a certain time to have a meeting.

Users can create or join Project Rooms from a Project RoomBrowser, which shows a list of Project Rooms currently inuse with short descriptions of each. Users can also enter orcreate Project Rooms from Encounter, Gallery, or from aGlance. Suppose two people run into each other whilereading a company-wide e-mail about a change in theirbenefits policy. One glances the other and they begin todiscuss the topic. They decide they would like others to jointhe discussion, so thev create a Proiect Room. When others

the person is active. read that message, ~y see an icd in their Encounter thatlets them join that Pro~t Room,

Figure 7. Design sketchesof two views of a projectroom. in 7a, left, the projectroom is being used to holda groupdis-cussion.In 7b, right,it is beingused to store documentsshared by a groupand to postannouncements,althoughpeoplemay have interactionsif they are visitingat the same time.

322

Alternatively, the person who sent the message about thebenefits change can aunounce that they will be in a ProjectRoom during a specific time range and include anattachment in the message that takes users there. Thisfeature allows someone to make a formal announcement,but still be available for “word-of-mouth” discussion wherethey can guide people’s understanding of the announcement.

ImplementationPiazza is currently under development. Encounter in itsstandard form is nearly finished and has been integratedwith several applications, but the expanded and minimizedstate have not been implemented. Gallery and PeopleBrowser are largely complete, Glance is in the early stagesof development, and Project Rooms have not been started,

Piazza is implemented in the OpenStepTMenvironment onSolaris.m Central to its implementation are distributedPeople Objects, which stme the available information abouta person. All the other Piazza components visualize theinformation in the People Object in different ways.Encounter also uses a distributed architecture. Eachapplication links in an Encounter proxy, which it notifiesany time the user changes location. The proxy contacts theuser’s server, which multicasts that new location to all otherEncounter servers. Those servers store the new informationand consult the application to determine whether the newlocation is considered “nearby” and therefore needs to bereflected in the user interface. Glance, Stickup, and thePeople Browser are implemented as services that can beaccessed by other applications.

SUPPORTING ENTERPRISE-WIDECOMMUNICATIONHaving described the details of Piazza, we return to themotivation for its design to consider how we attempted toaddress the issues raised. Our primary goal was to make itpossible to have opportunistic and spontaneous interactionswith other members of a large distributed community.Piazza attempts to do so by allowing people to see who elseis “nearby” (i.e., working on a similar task at about the sametime) and then to naturally transition into an interactionthrough video, audio, text, or whatever medium is available.By allowing people to see others doing similar tasks, thereshould be enough context for people to start up lightweight,impromptu interactions.

Another goal was to make it easier for members of a largecommunity to distribute information in the way that peoplemost like to receive it. Our interviews showed that peoplelike to get information by word of mouth. but thatdistributors of information are suspicious of thismechanism. The Project Rooms were largely inspired bythis problem, although we think Piazza’s other mechanismsmay also play a role. In particular, the Project Rooms weredesigned to make it easy to disperse a message usingrelatively formal mechanisms (documents, Web pages, e-mail messages), while still providing a way to talkinformally 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 indiscussions as people come across the information at theirown pace. In addition, the author of a document couldchoose to always appear in the Encounter of someoneviewing it, again making it easy for ~ple to ask the sourceabout 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 howthe information assisted others. Although not implemented,it would also be possible to allow people to document thenumber of ~ople visiting the information. We cannot becertain whether such benefits will arise, of course, until thesystem is well used and tested, which we expect to happenin the upcoming months.

ISSUES FOR STUDYPiazza is still under development, but when it becomes momfully implemented, we plan to deploy it within a broadcommunity and conduct a formal use study. In that study, wehope to learn more about the types of interactions initiatedthrough the components (Encounter, Gallery, PeopleBrowser and Project Rooms) and whether they differ ininteresting ways. We are especially interested to learnwhether it is possible to enable unintended interactions in away that is useful and that strengthens the sense ofcommunity among a distributed group. We would like tocompare Piazza-based unintended interactions to those thatoccur among co-located groups to learn whether theyhappen as frequently and serve a similar purpose.

In addition, we want to explore the following specific issuesraised by Piazza’s approach to community-orientedcommunication.

Task-based encounters. Unlike previous systems,unintended encounters in Piazza are based around tasks,rather than locations. We would like to learn whether acommon task provides enough of a reason for people tooccasionally contact others, even if they are strangers. Justas people routinely ask for help af strangers located near thesource of confusion (e.g. asking for help with a jammedcopier), we would like to know whether it is equallyacceptable to ask a stranger who is using the same on-lineapplication how to complete an unfamiliar task.

Scoping. Clearly, the Encounter and Project RoomBrowsers will need to be scoped to include a reasonableportion of the larger community. If all the Web browsers ofthe world were to include Encounter and be scoped to theworld, then users would see far too many strangers everytime they looked at a popular page. On the other hand, thescope of Encounter should not be so small that people rarelymn into others and the~fore do not come to feel part of thedistributed community. We expect that different applicationsand different data sources will be scoped di&xently, but weneed more experience to learn the best approach.

323

Distributing information. We are interested to learnwhether disseminators of information will use ProjectRooms to announce their news and handle informal queries.We also would like to learn whether an established on-lineforum for dispwsing information will change management’sview 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 enablenetworkers to formally document the value of their service.

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

In the future, we hope to explore these issues and others aswe complete Piazza’s development and study its use acrossa broad community. We hope that Piazza will make asignificant step toward the difi5cult problem of enablinglightweight, impromptu interactions among members of awidely distributed organization.

REFERENCES1.

2.

3.

4.

5.

6.

7.

8.

9.

Abel, M.J. (1990). Experiences in an exploratory distrib-uted organization, In J. Galegher, R. Kraut & C. Egido,(F@.), Intellectual Teamwork, Hillsdale, NJ: Lawrence~haum 489-510.Bly, S.A,, Harrison, SR. & Invin, S. (1993) Media Sp=:Bringing people together in a video, audio, and computingenvironment,Communications of the ACM,361, 28-47.Curtis, P. (1992) Mudding: Social phenomena in text-bawd virtual realities, Proceedings of the 1992 Conferenceon Directions and Implications of Advanced Computing,Berkeley.Dourish, P.& Bly, S. (1992). Portholes: Supporting awme-ness in a distributed work group. Proceedings of the Con-ference on Computer-HumanInteraction (CHI), Montmy,Ck ACM %3SS, 541-547.Ehrlich, K. & Cash,D. (1994). Turning Information IntoKnowledge Information Fiiding as a CollaborativeActiv-ity, Proceedings of Conference on Processing of DigitalLibraries, College Station, TX, 119-125.Finholt, T., Sproull, L. & Kiesler, S. (1990). Comnmnica-tion and performance in ad-hoc task groups. In J.Galegher, R. Kraut & C. Egido, @da.), Intellectual Team-work. Hillsdale, N.J.: Lawrence Erlbaum, 291-325.Fish, R., Kraut, R., Root, R. & Rice, R. (1993). Video as atechnology for informal communication. Communicationsof theACM, 361,48-61.Gantt, M. & Nardi, B. A. (1992). Gardeners and Gurus:Patterns of Cooperation Among CAD Users, Proceedingsof the Conferenceon Computer-HumanInteraction (CHI),Monterey, CA ACM ~SS, 107-117.Granovetter,M. (1973). The strength of weak ties, Ameri-can Journal of Sociology, 78, 1360-1380.

10.

11.

12.

13.

14.

15.

16.

17.

18.

19.

20.

21.

22.

23.

24.

25.

Hiltz, S.R. & Turoff, M. (1985) Structuring computer-mediated communication systems to avoid informationoverload, Communicationsof the ACM, 28:7,680-689.Isaacs, E. A., Morris, T. & Rodriguez, T.K. (1994), AForum for supporting interactive presentations to distrib-uted audiences. Proceedings of the Conference on Com-puter-Supported Cooperative Work (CSCW), Chapel Hill,NC: ACM ~SS, 405-416.Isaacs, E.A., Morris, T. Rodriguez, T.K. & Tang, J.C.(1995). A comparison of face-to-face and distributed pr-esentations.Proceedings of the Conference on Computer-Human Interaction, Denver, CO: ACM Press, 354-361.kWlcS,E.A., Whittaker, S., Frohlich, D., & O’Conaill, B,(in press). Informal communication se-examined: Newfunctions for video in supporting opportunistic encountemIn K. Finn, A. Sellen, & S. Wilbur, Video-Mediated Com-munication, Mahwah, Nt LrwmmceErlbaum.Kraut R.E., Egido C. & Galegher J. (1990a) Patterns ofcontact and communication in scientific meamh collabo-ration. In J. Galegher & R. Kraut (Eds.) Intellectual team-work, HWe, NJ Erlbauw 149-171.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(E&), People’s Reactions to Technology,Newbury ParkSage Publications, 145-199.Kraut, R.E. & S*ter, L.A. (1995). Combination in soft-wrue development, Communicationsof the ACM, 38:3,69-81.Morningstar, C. & Farmer, F.R. (1991). The lessons ofLucasfdxn’s Habitat, Cyberspace, Michael Benedikt, Ed.,Cambridge MIT ~SS, 273-301.Nelson, R.& Mathews,K.M. (1991).Network characteris-tics of high-performing organizations,Journal of BusinessCommunications,28:4,367-386Olson, J.S., Olson, G.M., Storrosten, M. & Cartner, M.(1992) How a group-editor change the character of adesign meeting as well as its outcome, Proceedings of theConference on Computer-Supported Cooperative Work,Toronto ACM Pros, 91-98.Stefik, M., Foster, G., Bobrow, D.G., Kahn, K., Lanning,S.& Suchman, S. (1987) Beyond the chalkboard Com-puter support for collaboration and problem solving inmeetings, Communicationsof the ACM, 301, 32+7.Suchman L. & Wynn E. (1984). procedures and problemsin the office. Ofice: Technologyand People, 2, 133-154.Tang, J.C., Isaacs, E.A. & Rua, M. (1994). Supporting dis-tributed groups with a Montage of lightweight interac-tions. Proceedings of the Conference on Computer-Supported Cooperative Work (CSCW), Chapel Hill. NC:ACM~SS, 23-34.Tang, J.C. & Rua, M. (1994). Montage: Providing tele-proximity for distributed groups, Proceedings of the Con-ference on Computer-Human Interaction, Boston, MAACM PIWS, 37-43.Whittaker,S., Frohlich,D. & Ddy-Jones, O. (1994). Infor-mal workplace communication: What is it like and howmight we support it?, Proceedings of the Conference onComputer-Human Interaction, 13aston,MA: ACM Pros,131-137.Whittaker, S. & Sidner, C. (1996). Email overload explor-ing personal information management of email, Proceed-ings of the Conference on Computer-Human Interaction,Vancouver ACM Fless, 276-283.

324