Issue
Article
Vol.30 No.2, April 1998
Article
Issue
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |
Effective work groups have always relied on peripheral awareness of each other's activities, such as sounds leaking under office doors and casual encounters in the hallway. Technology encourages the distribution of human communities but denies them the communal awareness provided by physical proximity. Groupware applications are emerging as a means of supplanting or augmenting the traditional awareness mechanisms. Requirements for such systems vary widely with the nature of the groups to be interconnected and individual tastes, often leading to narrow solutions. The SharedInfoServer simplifies groupware development, supports diverse information types, and encourages experimentation. Several prototypes using the server have been constructed and deployed within Apple's Advanced Technology Group.
Apple Computer has been conducting a telecommuter program for several years. Among other benefits, this program provides Apple Labs with a group of study subjects trying to maintain awareness of remotely located work groups. A questionnaire survey and interview study of these telecommuters revealed that, while they were able to accomplish significant amounts of work at home, they had trouble staying informed about the progress of existing projects and the formation of new projects. Some of them reported feeling disconnected and wishing they had more opportunity for casual encounters with colleagues:
`Impressing upon people my own feelings (e. g., degree of commitment to some goal) is often harder than when talking in person'
`Since I'm not in their faces, my project gets pushed aside a bit.'
`The initial investigative part of a project doesn't work unless I have face-to-face contact.'
Despite these shortcomings, it appears that telecommuting will continue at Apple, and is on the rise at other locations. Our work aims to discover just how much background awareness can be restored to remotely-located people using computer-mediated communication. We will not attempt to replace face-to-face contact, but instead exploit the communication abilities afforded by networked computing devices in order to:
Since the Shared Info Server is aimed at a subset of the varied situations require awareness, I would like to distinguish between the following three situations: awareness between colleagues during synchronous shared editing, awareness within small work groups during day-to-day activities, and awareness of community activities over months and years.
Any tool for synchronous collaborative work, such as a shared text editor, needs to provide continuous awareness of what the other participants are currently doing [8]. This can be done through the use of telepointers, live thumbnails [15-18], or shared fisheye overviews [12]. This awareness information is most useful when it is rapidly distributed and tightly integrated with the tool itself. The Shared Info Server cannot guarantee the response times required by these tools. Therefore, it is aimed at groups and communities as described below.
Today's work groups stand to benefit greatly from improved awareness, as evidenced by studies of groups of distributed workers trying to coordinate their activities [3, 8, 10]. These studies highlight the importance of gathering and disseminating information about group member whereabouts and activities, and the tremendous human energy currently devoted to these tasks. If computer-mediated communication can augment these practices or extend their reach, considerable benefit should accrue.
Current awareness systems cull information from software already adopted by the group or community. On-line calendar data, if properly maintained, can be very informative to members of a work group [9, 20]. Other research uses the UNIX `finger' command to provide awareness among a UNIX machine's users. The results are displayed iconically [13] or as a collage of user names clustered by common interests [7]. Awareness of places can be efficiently conveyed through periodic video snapshots [10]. Other research focuses on the use of auditory instead of visual display for conveying awareness information [6, 11, 19, 21, 22]. In the absence of a central server, awareness information can propagate among clients using an epidemic algorithm [5].
The Shared Info Server is a piece of infrastructure designed to disseminate all these kinds of information to a variety of clients. Groupware systems built with the Shared Info Server benefit work groups in several ways:
The Shared Info Server supports awareness of community activities by collecting relevant information from other domains such as calendars or news feeds. This central repository helps group members selectively receive updates about information they find relevant rather than wading through broadband services. Live information in the Shared Info Server can form the basis of proxies for shared resources, such as conference rooms or office printers. These proxies help communities make the most of their shared resources.
The Shared Info Server receives and distributes awareness information as defined above. Clients are responsible for collecting and distributing this information to and from group members. Clients follow one of three general designs (see Figure 1):
Figure 1: Three computers running different kinds of clients interact with a server
A Writer sends information to the Shared Info Server. This information might be acquired passively, by monitoring a motion sensor, or actively, by explicit user action.
A Reader registers to receive notifications from the Database. Upon receiving a notification, the Reader presents it to the user as graphics or sounds. It might also act as a gateway to some other notification technology (such as a mobile pager).
A Reader/Writer writes a particular kind of information to the server and reads this same kind of information from the server. When everyone in the group uses such a client, complete reciprocity is achieved. This symmetry can allay fears about privacy. During development, these reciprocal clients can make the simplifying assumption that all the Server's clients are identical and all database Entities contain the same set of Attributes.
Since our laboratory is focused to rapid prototyping and deployment, I felt an open architecture would best support the construction of systems like those described above without reimplementing the networking infrastructure each time. My goals for the Shared Info Server are as follows:
While serving these goals, an infrastructure for awareness services needs also to accommodate privacy and encourage adoption [2, 4, 21].
In dealing with privacy and security, it is important to distinguish between the policies enforced and the mechanisms the platform provides. Without the latter, one cannot implement the former.
Few computer systems can guarantee their users private, secure communication. When the system includes clients of unknown provenance (as with Internet mail), guarantees are even harder to achieve. As a public server implementing a known protocol, the Shared Info Server can provide mechanisms for protecting privacy, but the implementation of policies is left largely to the clients. One simple way to encourage respect for privacy is to encourage the development of reciprocal clients that only display the kind of information they publish (see Reader/Writer clients above).
While the Server could implement traditional access lists for each piece of information, such systems often inhibit adoption by imposing a burden on the information owner. Instead of trying to regulate access with technical means, the Shared Info Server seeks to solve this problem in the social domain [2, 9].
The server should make public the list of viewers for each piece of information. Just as each person in a public space can generally determine who is listening to a particular speaker, the Server should make public the list of clients registered for updates about a particular piece of information. This is intended to engender social responsibility in the people operating these clients by making their behavior accountable to their group or community [2].
Some information may be sufficiently sensitive that its publisher would wish know who is observing it. The server should be designed to send notifications, or even to request approval from the information owner before adding new clients to the list of subscribers.
Both background daemons that collect data from sensors and graphical applications that prompt the user for input are Writers. Since Writers collect data for subsequent distribution, they form the user's primary experience of being monitored, and should represent their actions in an informative but unobtrusive manner. This can be accomplished through a wide variety of means, depending on the nature of the information being collected. When hardware sensors, such as video cameras, are involved, warning lights or signs may be the most appropriate indicator of data capture. In most cases, a client should offer the monitored person a mirror of how the recorded data about themselves appears to others.
A Writer could display the list of clients subscribed to the information it collects, but in an open system the writer can make no guarantees about the behavior of the readers. A similar issue crops up on the Internet Relay Chat, where any given participant may log the conversation. This behavior is considered improper but is impossible to detect unless the perpetrator later acts in a manner that betrays her possession of a transcript (e. g., publishing excerpts from the transcript in subsequent messages). Having accepted both the risks and benefits of an open system, the solution to this kind of problem must lie in the social domain, not the technical domain.
Like Writers, Readers can range from off-screen processes that forward data to mobile pagers to on-screen renderings of live awareness data. The major goals of any reader client are to faithfully reproduce, with attribution, the relevant data; to account as fully as possible for network or server failures; and, to discourage improper logging of data.
Two key factors for successful groupware emerge from surveying the literature and observing the deployment of prototypes inside Apple Labs.
The Shared Info Server is a Macintosh application written in C++ that attempts to satisfy these design goals. It is developed with Metrowerks CodeWarrior, and PowerPlant class library. Communication with the Shared Info Server takes place via Apple Events. These messages allow client programs to create and delete Entities and Attributes, register and unregister for changes to Attributes, and retrieve information about the database (see Appendix A for a protocol description). Reader clients are responsible for implementing a subset of this same protocol.
Figure 2 shows a sequence of messages between the Server, a Reader, and a Writer. The Server receives the Reader's Register For message and replies with the current value of the data in question. When the Writer submits a new value using the Change Value message, the Server redistributes it to all the subscribers using a the same Change Value message.
Figure 2: Timeline showing the flow of messages between server and clients
The Reader and Writer generally remain in a stable configuration of data flow, such as the one depicted in Figure 1. Here three group members are each using a Reader/Writer to share information about whether their computers are in use. Additionally, two team members are monitoring data captured automatically by a sensor.
Fundamentally, the Shared Info Server is a simple database comprised of Entities. Each Entity has one or more Attributes. Each Attribute stores a data value and type, a modification time stamp. The Apple Event protocol defines standard data types such as dates, strings, and numbers. New data types, such as pictures or sounds may be readily created and stored in the Server, but are only legible to Readers that understand them.
The Server records connections to Readers in two ways. The Server maintains for each Attribute a list of Readers registered to receive notification of changes to the Attrribute's data value. The Server also maintains a global list of all the Readers that includes when the Server last successfully sent each Reader a message, statistics about recent failed communication attempts, and for which attributes each Reader is registered. This replication permits both efficient processing of Change Value messages and removal of faulty Readers.
Thanks in large part to the ease of sending and receiving Apple Events on the Macintosh, clients for the Shared Info Server have been written in HyperCard, FaceSpan, AppleScript, Macintosh Common Lisp, and C++. I want to focus on the two most fully developed examples to date.
During the summer of 1996, Trace Wax prototyped a service called Red light, Green light (RLGL) [23]. RLGL's purpose is to distribute availability information within a work group. RLGL combines both manually entered information in the form of a traffic light with computer idle time to form as comprehensive a report as possible about the availability of a colleague. Figure 3 shows the main RLGL window, with shaded circles indicating the availability of several group members. Empty circles represent absent people. The circles also function as links to further information about each person and an opportunity for lightweight messaging. As an early developer for the Shared Info Server, Trace exposed a lot of bugs in its implementation, but ultimately benefited from not having to implement data distribution algorithms.
Figure 3: Drag and Drop client for Awareness Services displays Entities and Attributes, along with appropriate visualization widgets. The pilot light pictures indicate whether a computer is in use, while the adjoining text displays information from the Gone Since screensaver module
As part of a user study that looked at highly mobile office workers [3], Blake Ward implemented Gone Since, a screen saver module that displays the idle time of a computer and a message the owner can use to describe his or her whereabouts. Gone Since was retrofitted to forward this information to an Reader/Writer client that informs the server its owner's whereabouts and displayed the whereabouts of others. I extended what was a simple columnar display to include other data, such as motion sensors, door positions, and video portholes (see Figure 4).
Figure 4: Trace Wax's Red Light, Green Light client shows the availability of work group members using the traffic light metaphor
With the server now moderately stable, much work remains in the area of clients and improved integration of the system's pieces. Here are some proposed areas of future work.
This paper describes a Shared Info Server designed to encourage rapid prototyping of awareness services. These services provide distributed groups and communities with the context for casual encounters and useful cooperation, and support efficient coordination of behavior. If, as Pavel Curtis said, `the killer app for the Internet is people,'(2) then making those people aware of each other and instilling in them a sense of community should be a high priority. I believe doing this successfully starts with a reliable infrastructure like the one proposed here.
Blake Ward designed the Shared Info Server protocol and built the first Writer. Victoria Bellotti made many important suggestions about privacy. Charlie Hill critiqued the design of my early clients and was one of the first to communicate with the server. Joe Pallas remains my best object-oriented architecture critic. Dan Russell developed many test clients, and was our first motion detectee. Tom Bonura and Trace Wax bravely developed clients during server development and testing.
Add Entity: Add an entity to the database
Add Entity string
Remove Entity: Remove an Entity from database
Remove Entity string
Add Attribute To: Add an attribute to an entity already in the database
Add Attribute To string
attribute name string
Remove Attribute From: Remove an attribute from an entity already in the database
Remove Attribute From string
attribute name string
Change Value For: Change value for an Entity's Attribute
Change Value For string
attribute name string
attribute value anything
Register For: Register for notification of changes in an attribute's value
Register For string
attribute name string
Unregister For: Unregister for notification of changes to an attribute's value
Unregister For string
attribute name string
Get Attributes For: Get the names of all the attributes for this entity
Get Attributes For string
Get Entity Names: Get the names of all Entities in the database
Get Entity Names
Get Value For: Get the value of a particular attribute. Used sparingly, since polling is discouraged.
Get Value For string
attribute name string
Unregister: Unregister for all attributes
Unregister
1. Ackermann, M. and B. Starr, Social Activity Indicators for Groupware. IEEE Computer, 1996. 29(6): p. 37-42.
2. Bellotti, V. What You Don't Know Can Hurt You: Privacy in Collaborative Computing in Proceedings of HCI '96 (London, 1996), Springer, 241-261.
3. Bellotti, V. and S. Bly. Walking Away from the Desktop Computer: Distributed Collaboration and Mobility in a Product Design Team in Proceedings of CSCW '96 (1996).
4. Bellotti, V. and A. Sellen. Design for Privacy in Ubiquitous Computing Environments in Proceedings of ECSCW '93 (Milan, Italy, 1993), Kluwer Academic Publishers, 110-126.
5. Chesley, H., Asynchronous Background Networking on the Macintosh. develop, 1991. 2(1): p. 6-30.
6. Cohen, J. `Kirk Here:' Using Genre Sounds to Monitor Background Activity in Proceedings of InterCHI '93 (Amsterdam, The Netherlands, 1993), ACM Press, 63-64.
7. Donath, J. S. Visual Who: Animating the affinities and activities of an electronic community in Proceedings of MultiMedia '95 (San Francisco, CA, 1995), Addison-Wesley, 99-107.
8. Dourish, P. and V. Bellotti. Awareness and Coordination in Shared Workspaces in Proceedings of CSCW '92 (New York, 1992), ACM Press, 107-114.
9. Dourish, P., V. Bellotti, W. Mackay, and C.-Y. Ma. Information and Context: Lessons from a Study of Two Shared Information Systems in Conference on Organizational Computing systems (Milpitas, CA, 1993), ACM Press.
10. Dourish, P. and S. Bly. Portholes: Supporting Awareness in Distributed Workgroups in Proceedings of CHI '92 (Monterey, California, 1992), ACM Press, 212-213.
11. Gaver, W., R. Smith, and T. O'Shea. Effective Sounds in Complex Systems: The Arkola Simulation in Proceedings of CHI '91 (New Orleans, 1991), ACM Press, 85-90.
12. Greenberg, S. A Fisheye Text Editor for Relaxed-WYSIWIS Groupware in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 212-213.
13. Greenberg, S. Peepholes: Low Cost Awareness of One's Community in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 206-207.
14. Grudin, J. and L. Palen. Why CSCW Systems Succeed: Discretion or Mandate in Proceedings of ECSCW '95 (Stockholm, 1995), Kluwer Academic Publishers.
15. Gutwin, C. and S. Greenberg. Workspace Awareness for Groupware in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 208-209.
16. Gutwin, C., S. Greenberg, and M. Roseman. Supporting Awareness of Others in Groupware in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 205.
17. Gutwin, C., and M. Roseman. A Usability Study of Workspace Awareness Widgets in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 214-215.
18. Gutwin, C., S. Greenberg, and M. Roseman. Workspace Awareness Support with Radar Views in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 210-211.
19. Hudson, S. E. and I. Smith. Electronic Mail Previews Using Non-Speech Audio in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 237-238.
20. Lövstrand, L. Being Selectively Aware with the Khronika System in Proceedings of ECSCW '91 (Amsterdam, The Netherlands, 1991), Kluwer Academic Publishers, 265-277.
21. Smith, I. Toolkits for Multimedia Awareness in Proceedings of CHI '96 (Vancouver, British Columbia, 1996), ACM Press, 59-60.
22. Smith, I. and S. E. Hudson. Low Disturbance Audio for Awareness and Privacy in Media Space Applications in Proceedings of MultiMedia '95 (San Francisco, CA, 1995), ACM Press, 91-97.
23. Wax, T. Red light, green light: Using peripheral awareness of availability to improve the timing of spontaneous communication in Proceedings of CSCW '96 (Boston, 1996), ACM Press, 1996.
Dr. Walker holds a Ph. D. in Computer Science from the University of Illinois, where he studied object-oriented software design. He also studied jazz piano, worked in the Experimental Music Studios, and collaborated with composer Salvatore Martirano. He has been affiliated with the University of Illinois CERL Sound Group for ten years, where he helped develop Lemur, a sound analysis/synthesis tool.
Dr. Walker is also a Research Scientist at San Jose State University's Center for Research in Electro-Acoustic Music (CREAM), is engaged in ongoing interactive music system research with Dr. Brian Belet of the SJSU music composition department.
Bill Walker
Xerox Palo Alto Research Center (PARC)
3333 Coyote Hill Road
Palo Alto, CA 94304, USA
email: bwalker@parc.xerox.com
http://www.shout.net/~walker/
Issue |
Article |
Vol.30 No.2, April 1998 |
Article |
Issue |