|Kamal Ayad||Mark Day||Steve Foley|
|Dan Gruen||Steve Rohall||Quinton Zondervan|
Lotus Development Corporation
55 Cambridge Parkway
Cambridge, MA 02142
In addition to being the leading groupware product in conventional office settings, Lotus Notes and Domino [Lotus 98a] are widely popular as an infrastructure for mobile computing based on laptops. Lotus Research is a small interdisciplinary team focused on computer-supported cooperative work, grounded in observation of work settings. Accordingly, it has been natural for Lotus Research to pursue two directions: first, to extend Notes data and functionality onto new, smaller, mobile computers; and second, to consider new collaboration possibilities of those computers without reference to Notes. Some of these investigations have already been incorporated into products: Lotus EasySync [Lotus 98b] allows synchronization between certain Notes databases and the 3Com Pilot (or IBM WorkPad) [3Com 98], and includes a mail conduit originally built as a research project. In this paper, we describe two other examples of our recent investigations. The first extends Notes email to 2-way pagers and integrates that delivery with presence information from our experimental colleague awareness tool, Prairie Dog. The second describes our work on using 3Com Palm IIIs or IBM WorkPads for passing notes among colleagues in a conference room setting.
The system hinges on an email-processing agent running in the user's Lotus Notes mail database. This agent is called 007, since it is a "secret agent". For each piece of email received in the mailbox, 007 first determines whether the message is an ordinary message intended for the user or a command message intended for the agent. If the mail is intended for the user, 007 applies a collection of stored rules (configurable by the user) to determine whether to send the entire message or a summary containing the sender, subject, and length of the message. Our current service limits messages to 512 characters. The pager alerts the user when new email arrives and presents the sent version of the message.
The net effect is that the pager's user can receive email on the pager without the senders needing to know about the pager's address. The pager starts to run low on memory after about 120-150 messages, which represents at most a few day's worth of incoming email for most of us. This limited capacity, together with the somewhat difficult user interface, means that we can only use this for an alerting and summarizing function. But since this device is always connected, it's especially handy for getting a sense of recent developments when one is out of the office, or at home in the morning.Some users have fairly elaborate processing determining which messages are forwarded, while others send everything. We have noticed that our experience of the wearable email cache is very different from our experiences with conventional pagers: a common comment is that one still feels "connected" without being "chained." The value of our pagers is somewhat limited for travel by the fact that the SkyTel service we use [SkyTel 98] only covers the U.S., but we expect that we would be able to deploy a similar service on Iridium [Iridium 98] or one of its competitors if we so chose.
The 007 agent also includes capabilities for fetching long versions of mail messages that were summarized, and for replying to email using the pager. However, we find that we use these features much less than we expected when the system was first built. We have also experimented with breaking up long messages into fragments rather than sending summaries, but the fragments are sometimes delivered out of order; in addition, we are not yet able to modify or replace the pager's email client to reassemble messages. As a result, the user experience of such a fragmenting agent is rather unpleasant.
We have already had some problems with excessive mail sent to a pager. In one case, a faulty version of 007 started processing a user's entire mailbox instead of only the newly-arrived messages. In another case that was not our fault, an external mailing list robot started sending error messages (unrelated to our system's operation) every few seconds. These problems have made clear that we need to have a "panic button" capability somewhere in the system to shut down the delivery of mail to the pager, especially if one is paying for each message being delivered.
An email display small enough to wear at all times is both immediately appealing and of enduring value, but it does take a while to adjust to the pager with email. A new user tends to look down at their belt-mounted device every time a piece of email arrives, which can be a fairly frequent occurrence. It can take a while to learn how annoying this behavior is to other people who are talking with the pager's user. Different users have developed different solutions, although all recognize the problem. One has turned off all alerting; another has learned to ignore the alerts except when socially acceptable; still another has refined the filtering so that only messages likely to be urgent trigger the pager's alert.
The 007 agent typically runs on a mail server machine and thus cannot directly use the sort of low-level hooks that Prairie Dog uses to detect client machine activity. Instead, 007 uses the information exposed by Prairie Dog through the NSTP server to control whether email forwarding takes place. When the user is shown as active in Prairie Dog, email forwarding is inhibited; when the user is shown as inactive, email forwarding is re-enabled.
We think that it is critical that such messages not be intercepted. This is true both when the message is being composed as well as when it is being transmitted. To protect against someone "looking over your shoulder" while the message is being composed, we have implemented a note editor that garbles what is displayed. In our prototype, a simple rot13 algorithm is employed to make the displayed text illegible to the casual glance. Placing the pen onto the Pilot screen causes the text to be decoded so that it can be easily read.
Equally important is protecting the note as it is being passed. Once the note is composed, the infrared capabilities of the Pilot allow it to be "beamed" to other Palm devices. In this application, the limited capability of the Pilot's infrared transmission turns out to be helpful. We have performed our own measurements of our Pilots and have found that to communicate between two devices, the devices must be fairly close (no more than about a meter) and must be fairly well aligned (within 5 degrees at 1 meter, although this alignment requirement drops rapidly: at 10 cm, the devices can communicate even at 89 degrees off-axis). Indeed, the distance and alignment requirements are sufficiently stringent that there are a number of conference rooms in our building where two parties at the table are unable to communicate via infrared at all. We are working with a hardware group at IBM to investigate retrofitting Pilots with more powerful IR transceivers. At typical conference room distances, the low power used for infrared transmission means that it is very unlikely that stray transmissions can be intercepted by others. Accordingly, we see no reason for elaborate encryption schemes.
On the other hand, because of the structure of the IrDA protocols [IrDA 96] and the absence of a fixed globally-unique machine identity (IrDA devices have nothing like an Ethernet address) there is a possibility of accidentally establishing a connection to the wrong IrDA device in a crowded room. So our second piece of modest security technology is an initial, identifying handshake between the two devices. With this capability, a user's single-tap gesture asks the other device for the remote user's identity. If the user name returned is incorrect or missing, the sending user can break the connection and attempt a different alignment, knowing that the connection was made to the wrong device. If the user name returned is correct, the sending user can be fairly confident that sent data will be received only by the intended recipient. We are attempting only to prevent accidental, embarassing disclosure: our approach is vulnerable to an adversary who takes extraordinary steps to intercept the transmission or sets themselves up to spoof (using a device with the same user name as a person on the other team, for example). However, we believe that it represents a valuable, functional, low-cost solution to the problem of note-passing in typical business settings.
[3Com 98] For information about the 3Com Palm III, see http://www.palmpilot.com.
[Day 97] Day, Mark, John F. Patterson, and David Mitchell. The Notification Service Transfer Protocol (NSTP): Infrastructure for Synchronous Groupware. Computer Networks and ISDN Systems 29 (1997) 905-195.
[Day 98] Day, Mark, and Steve Foley. Selective Dissemination of Information in a Colleague Awareness Application. Demo accepted for CSCW '98.
[IrDA 96] Infrared Data Association (IrDA). Serial Infrared Link Access Protocol (IrLAP), version 1.1. See http://www.irda.com.
[Iridium 98] For information about Iridium, see http://www.iridium.com.
[Lotus 98a] For information about Lotus Notes and Domino, see http://www.lotus.com.
[Lotus 98b] For information about Lotus EasySync for Notes and Organizer, see http://www.lotus.com.
[Motorola 98] For information about the Motorola PageWriter 2000, see http://www.mot.com/MIMS/MSPG/Products/Two-way/pagewriter.
[Patterson 96] Patterson, John F., Mark Day, and Jakov Kucan. Notification Servers for Synchronous Groupware. CSCW '96, pages 122-129.
[Skytel 98] For information about SkyTel paging services, see http://www.skytel.com.
[Wax 96] Wax, T. Red Light, Green Light: Using Peripheral Awareness of Availability to Improve the Timing of Spontaneous Communication. CSCW '96 Short Papers.