Rapid Prototyping of Awareness Services using a Shared Information Server

Revision as of 20:38, 23 September 2020 by Netfreak (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

William F. Walker
Advanced Technology Group, Apple Computer
1 Infinite Loop, MS: 301-3KM
Cupertino, CA 95014 USA

Abstract

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 Shared Info Server simplifies groupware development, supports diverse information types, and encourages experimentation. Several prototypes using the server have been constructed and deployed within Apple Labs.

Keywords

Rapid prototyping, Groupware, CSCW, Awareness

Problem Statement

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:

  • Promote efficient coordination of activity by conveying information about a remote colleague's current and recent activity. As Ackermann and Starr said, "It's energizing to know that your teammates are busy working away on a project." [1]
  • Provide context for initiating phone calls or video conferencing by conveying information about a remote colleague's approachability and availability. Awareness services can provide the context for successfully initiating communication, thereby avoiding the frustration Apple's telecommuters report when their phone calls yield only voice mail boxes instead of colleagues.
  • Provide people with the feeling of connectedness they attribute to being physically co-located. Some may reject the possibility of achieving this goal without a fully connected network of full duplex, broadcast-quality video links. However, the strong sense of community experienced by inhabitants of the Internet's text-based interactions offer hope that low bandwidth connectivity can convey much if used effectively.

Kinds of Awareness

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.

Shared Editing

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.

Groups

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:

  • Social Proxy. The server acts as repository for information about each member of a work group. This can include both static information like an e-mail address or a phone number as well as dynamic information, such as computer idle time and office motion detector state. When coupled with an interesting visualization client and some simple inference rules, this information becomes a kind of social proxy that can "mind the store while I'm gone."<a name="fnB0" href="#fn0">(1)</a>
  • Context for Contact. This same dynamic information can also support opportunities for casual encounters by painting a picture of someone's availability. The combination of passively captured and actively supplied information about each group member can help one decide whether to initiate communication with another group member, and what form that communication should take.

Communities

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.

Kinds of Clients

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):

Writer

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.

Reader

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).

Reader/Writer

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.

An Open Client/Server Architecture

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:

  • Language neutrality. Apple Labs employs partisans of many different programming environments, including Common LISP, MacroMedia Director, and C++. My goal was to include as many of these researchers as potential Shared Info client developers. I therefore reduced the client/server protocol to its essentials and tried to make the transport mechanism language-neutral. Since most Macintosh programming environments support sending and receiving Apple Events, this seemed like a good choice.
  • Client stupidity. Despite the simplicity of the client/server protocol, the server must be prepared for clients that quit suddenly or otherwise misbehave. Redundant commands should be ignored, and meaningful error codes returned.
  • Notification instead of polling. The Shared Info Server is designed for stateful clients that retain each data value they receive until the next value arrives. In such a context, sending notifications from the server is much more efficient than polling by the clients. While the server supports retrieving data values, this is strongly discouraged.
  • Scalability. The Shared Info Server should gracefully accommodate both large and small databases and client communication loads without difficulty. This frees the groupware prototyper from worrying whether a particular client design will cause trouble for the server.

While serving these goals, an infrastructure for awareness services needs also

to accommodate privacy and encourage adoption [2, 4, 21].


 

Figure 1. Three computers running different kinds of clients interact with a server


Privacy

In dealing with privacy and security, it is important to distinguish between the policies enforces 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.

Writer guidelines

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.

Reader guidelines

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.

Adoption

Two key factors for successful groupware emerge from surveying the

literature and observing the deployment of prototypes inside Apple Labs.

  • Reliability In my experience, a group of researchers will not, even in the name of furthering their own colleague's research, make use of a slow or unreliable awareness client. Clients must be easy to install and maintain, and should especially be amenable to automated startup when the user logs in or starts up their machine. By encouraging users to start up these clients automatically, they are much more likely to be constantly running.
  • Cost versus Benefit Designers must pay particular attention to systems which require the user's explicit effort to publish information about themselves. If the benefits do not accrue to those making the effort to publish, the effort will not occur [14].

 
Figure 2. Timeline showing the flow of messages between server and clients


Implementation Of The Shared Info Server

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.

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 Attribute'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.

Current Shared Info Clients

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.

Red light, Green light

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 4 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 screen saver module.


Gone Since

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 3).

Future Work

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.

  • Since our office space consists of desks holding up Macintoshes, our internal experiments have focused on the desktop, with gateways to mobile pagers and cell phones. Building Shared Info clients for mobile devices, especially those with wireless connectivity, offers several possibilities. Awareness information becomes ubiquitous if it can be delivered while the user is on the move. Mobile devices that can determine their position can display awareness information in a context-sensitive manner, and can transmit their position to the server, providing colleagues with additional awareness.
  • In talking with colleagues about this project, I never heard anyone say, "I've got too little information flowing into my life, I'd like more." Awareness services will ultimately fail if their introduction is not accompanied by a reduction in information from other sources. This can happen if awareness services can provide a selective view on data currently provided by broad band services, eventually replacing them.
  • As our group conducts additional experiments with the Shared Info Server, I plan to develop a set of reusable awareness visualization idioms. I plan to collect these into a tool that lets end users construct their own collages of awareness information presented in a manner they find personally meaningful.
  • Shared Info Clients implement a subset of the Shared Info Server protocol. This symmetry is designed to allow multiple servers to communicate using the current protocol. This could be used to provide redundancy for network failures or to cope with large numbers of users.
  • As I begin to work with other platforms and communication devices, using TCP/IP to communicate with the server is increasingly attractive. The issue here is to find some existing basis for designing a Shared Info Server TCP/IP protocol, rather than inventing a proprietary one. I are investigating the Common Object Request Broker Architecture (CORBA) as one basis for client/server communication.

 
Figure 4. Trace Wax's Red Light, Green Light client shows the availability of work group members using the traffic light metaphor


Conclusions

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.

Acknowledgements

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.

Appendix A: SharedInfoServer Protocol

Please see:

SharedInfoServer AppleEvent Suite

References

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,

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., S. Greenberg, 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övestrand, 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,


Footnotes

(1)Special thanks for Charlie Hill for this phrase.

(1)From his Advanced Technology Group Seminar on March 1st, 1995.

See Also