Collaboration Using Multiple PDAs Connected to a PC

The Pebbles project is creating applications to connect multiple Personal Digital Assistants (PDAs) to a main computer such as a PC. We are using 3Com PalmPilots because they are starting to be ubiquitous. We created the “Remote Commander” application to allow users to take turns sending input from their PalmPilots to the PC as if they were using the PC’s mouse and keyboard. “PebblesDraw” is a shared whiteboard application we built that allows all of the users to send input simultaneously while sharing the same PC display. We are investigating the use of these applications in various contexts, such as co-located meetings.


INTRODUCTION
There are certain kinds of meetings, including design retiew's,brainstorming sessions, and organizational m&tings, where a PC is used to display sfides or a currentplan, and the people in attendance provide input When a PC is Usd as part of the presentation, often dfierent people \M want to take turns contro~ng the mouse and keyboard. For example, they might want to try out the system under consideration, to investigate different options, or to add their annotations. With standard setups, they wi~have to awkwardly swap places with the person at the PC.
We observed that at most meetings and -, attendees do not bring their laptops, probably because they are awkward and slow to set up, the batteries may not last long enough, and there is a social sti~m against typing during mmtings. Today, however, many people are taking notes on their '.Persond Dlgiti Assistant" &DA), such as a PahnPiiot or a Windows CE device. A PalinPilot is a sdl PDA from 3Com with a 3% inch diagond LCD display screen which is touch sensitive, and a srnrdl input area for printing characters using a special alphabet (see Fi=me 1). PahnPiiots are stil, they turn on instandy, the batteries last for winks. Permission to make digital or hard copies ofall or part ofthis work for personal or classroom use is --ted without fti pro~ided that copies are not made or distributed for profit or commercial advatage and that copies bmr tils notice and the full citation on the first page. To copy othm~ise. ZO republish, to post on sen,ers or to redistribute to fists, requires prior specific ptission and~ora fee.
CSCW 98 Seatie W=hington USA Copyright AChf 199S 1-5S1134094/98/11 -.S5.00 and notes are taken by writing silentiy with a stylus. With the new palm-size PCs from Microsoft just starting to be available, this type of device will become even more ubiquitous. Since many people are already using a PDA, we developed a set of applications to explore how these could be used to allow everyone to provide mouse and keyboard input to the PC without leaving their seats. We call this the 'Remote Commander: Once the PDAs are connected to the PC, many other intiguing applications become available. In addition to the Remote Commander, we also created a shared drawing pro-= named PebblesDraw, that rdlows everyone to draw simultaneously. In creating PebblesDraw, we had to solve a number of interesting problems with the standard widgets such as selection handles, menubars and palettes. Since this is a Single Displq Groupware (SDG) application, dl users are sharing the same screen and therefore the same widgets. Palettes, such as those to show the current drawing mode or the cnrrent color, normally show the current mode by high-figh~ng one of fie item in tie palette. This no longer works if there are multiple people with different modes. Furthermore, the conventional menubars at the top of the window or screen are difficult to use in multi-user situations because they may pop upon top of a different user's activities. The conventional way to identi~different users is by assi=tig each a different color, but in a drawing program, each user might want to select what color is being used to draw, causing confusion between the color identifying the user, and the color with which the user will draw. We therefore developed a new set of interaction techniques to more effectively support Single Display Groupware.
Is research is being performed as part of the Pebbles projec~Pebbles stands fon PDAs for Entry of Both Bytes and Locations from Extemd Sources.2 This paper surnmarizm the PahnPilot's features, and then describes the first hVO apphcations: Remote Commander, which allows the PahttPilots to control the PC, and PebblesDraw, which allows multiple people to draw at the same time. , which origintiy supported mdtiple cursors operating at the same time, but when produced cormnercidly, only supportd one person with one cursor at a time. Liveboards proved to be too expensive to be widely usd The Tivoh system [1S] supports up to three people using pens simtitaneously on the LiveBoard. We befieve that much of the software used with these previous technologies can be reproduced using a set of PahnP30ts and a singe PC, which will be much cheaper and easier to configure.
The Xerox ParcTab [24] project investigated using SW hand-held devices continuously connectd through Wed @) communication. hfost of the PARC btidmg was wired with special R transceivers to make the ParcTabs work The ParcTab screen was 12SX64pixels md had a few hardwired buttons and a touch-sensitive screen, which suppoti the Unistrokes 19] gesti dphabe~The ParcTab was used to investi=mtesome aspects of remote cursors, and inforrnrd vofig about how we~the speaker was doing, but due to problems with the~they found that mtitiple people simtitaneously using tie devices in the same room did not work well.
h~~i [4] @ltiti-Device, hldti-User, Mdti-~ltor) was one of tie first Single Display Groupware (SDG) environments to explore mtitiple mice on a single display. W handled up to three mice. h~~l had a single tool prdette and color palette, and a separate '%ome area" to show each user's name, current color, and dra~tig mode. MMM ordy supported editing of text and rectangles, and used color to distinguish between the users.
The term "Single Display Groupware" was coined by Stewart e~d. [23]. Stewart's RdPad [22] is a SDG environment for kids, where multiple mice are connected to a Unix computer. It uses "local tools" [2] on Pad~, where each tool does exacfly one thing (for example, there is a crayon tool). This model is easier for kids than conventionrd palettes, but it do= not have any global state (so, for example, there is no concept of a selection). Therefore,~dPad does not face many of the issues addressed in our Pebbles work. Background studies showed that children often argue and fight when trying to share a single mouse [22], but when using separate mice, cooperated more effectively. Another SDG effort is the COLT too~t [5], which explores some fimited kinds of user interactions and showed that children will stay more focused on their tasks when each child has their own mouse and they simultaneously manipulate the same object together.
Other groups are studying the use of PahnPilots in various settings, where they are not connected to a PC. For example, NotePals synchronizes people's independent notes after a meeting [7], and Georgia Tectis "Classroom 2000' project [1] is studying the use of PahnPilots in classrooms.

THE PALMPILOT
The PahnPfiot @@//pdmpilot.3com.co@ is a small inexpensive hand-held 'Tersond Digitrd Assistant" (see Figure  1) formerly sold by USRobotics (which was bought by 3Com) and rdso now sold by EM as the 'WorkPadY The PahnPilot sold over one million units in its first 1S months, and many people in our academic community are using them to take notes in meetings. Mthough our research is using PahnPflots because they are easy to program and popular, the research would equrdly apply to any PDA. We \til soon port the software to palm-size PCs running Microsoft Windows CE.
One of the most important reasons the PahnPilot is so poptiar is that it connects very easily to a PC (and dso to a Macintosh or Unix workstation) for synchronization and dotioadmg. Each PahnPfiot is shipped with a cradle and tie that connects to a computer's standard serial port. Software suppfied with the PahnPilot will synchronize the data with the PC. It is dso easy to load new applications into the PahnPfloL Pebbles takw advantage of this easy connection to a PC.
The main display of the PahnPilot is a 160x160 pixel LCD panel, with 4 levels of gray outmost applications treat it as monochrome). The scrwn is touch sensitive, so text and graphics can be selected and drawn. A snudl stylus which fits into the PahnPilot case is usutiy used for this, but a finger can dso be used for pointing and gestures. Textural characters are entered in the area at the botiom using special gestures called "Graffiti/' which is a stylized rdphabet that is designed to be easier for the PahnPilot to recognize and was downloaded about 3000 times in the first six weeks. The current version Tvorkswith Windows 95 or NT, and current versions of the PahnPiloL k designing this application, we wanted to make sure tiat it wotid fit in with the PahnPdot s~le. Therefore, it needed to be na~and non-intrusive. It shotid be easy to switch between using the Remote Commander and using other Pd&llot applications, and it shotid take advantage of the Graffiti gestures that the users had tieady learnd We dso had to dd with the PahnPiiot's titation~a sW, grayscrde screen, and a fairly slow processor. Furthermore, the users' focus shotid normrdly be directed to the PCS screen, so it shotid be possible to operate the Remote Commander without Iooking at the PahnPilo4 just as tie mouse can be used without looking.
In tie current version of Remote Commander, we rely on social protocols to control whose turn it is, which is not difficult since everyone is in the same room Everyone's inputs are rnixd together. We decidti that a more fod 'tioor contro~mechanism wodd obsmct the fluid sharing and collaboration that is typic~in meetings.~ls is supported by experience and informal experiments with other group ware systems [10].
Examp!e Uses~e n dsi.ting the Remote Commander, we had a number of uses in mind The first is as discussed above for mdtiple people in a meeting to take turns controtig the mouse and keyboard. Remote Commander is designed to support meetings where everyone is in the same room @emote participants might use other CS~applications, such as Microsoft NetMeeting.) Remote Commander might be used so different people can have a turn controlling an application, to support multiple annotations on a work product, or so everyone can enter their personal data into a shared document. Having a single, shared visurd display is important for coordination and collaboration [17], and people will take turns or dl work together on these displays. A second use for Remote Commander is to support small, informal meetings. Thae arise when two or three people are discussing something that is running on a PC, such as a demo situation, or for small impromptu design and debugging discussions.
Another use for the Remote Commander might be any time that a single user would rather have a SVIUSfor input in-* stead of a mouse, for example in situations when freehand drawing or writing is desired. The Prdtillot digitizer can even read the stylus through a sheet of paper, so Remote Commander can support the tracing of small drawings. Of course, if tracing was frequently needed, the user would probably purchase a "r# tableq but again we are taking advantage of technology the user might aheady have for a task they might do occasionally.

PaImPilot Module
There are hvo modules of the Remote Commander -one which runs on the PahnPilot and the other runs on the PC, and these hvo are connated using serial cables.

Moving the Cursor
Fiawe 1 shows the Remote Commander application runfig on fie p~fiilo~me Imge b]@ upper area is used to represent the mouse. Moving the stylus (or' your finger) across the screen of the PaWllot moves the cursor on the PC. Through experimentation, we arrived at a system which provides good control.
The current design uses relative coordinates. This is analogous to the smti touchpad on some laptops, like the Macintosh PowerBook. Movement across the PdrnPilot screen is mapped to an increment movement across the PCS screen, so the actual position where you put down the stylus is not important just how far it is moved from the initird position.
OriginMy, we tried directiy mapping the 160x160 pixels of the PrdmPilot to the 1024x768 pixels (for example) of the PC, using absolute coordinates. Thus, tapping in the upper left of the Prdfidot screen would move the cursor to the upper Iefi of the PC screen. However, this did not work at d. Since each pixel on the PahnPilot represented about 6 pixels on the PC, and since characters are often less than 6 pixels wide, this made it impossible to select individud characters. Furthermore, the positions reported by the PahnPdot digitizer are very jittery, varying by 1 or 2 pixels in rdl duections when the stylus is kept still, so the cursor jumped dl over the PCS screen.

2S7
Thejitte~coordinates coming from the PHIIot were SW a problem when we switchti to relative coordinates, making it difficult to position the cursor accurately. Looking at other applications running IocWy on the PahnPdo4 such as varions sketching pro=grams,we noticed that the jittery values were not Mtd to our pro-but smm to be a property of the device. Therefore, we added~tenng of the positions. After experimenting with various algorithms and parameters, the best behavior resulted from collecting the last 7 points returned by the PahnPiio~and returning the average as the current poin~This removes most of the jitter witiout adding too much lag. This fltering starts over each time the stylus comes in contact with the PahnPiio4 and the array of the last 7 points is initirdiiti with the initial poinT his allows points to be providd immediately when the stylus comes in contact \tith the surface. We dso added exaccelemtion 10 the PahnPfiot output so one swift mo~'ementacross the PahnPfiot screen w'odd move entirely across tie PP5 screen.

Alouse Buttons
Another issue concerns emtiating the mouse buttons. As I\5th a touchpa~the SVIUSof the PWiot must be in contact with the surface in order to move the cursor, so a different method is needed to signal pressing of the mouse buttons. This is not a problem for applications which run on tie PahnPilot itself, since the screen displays tie objects that the user wants to point a6 and there is no need for a separate cursor.
We provide three different ways to si=wd pressing a mouse button. FMSLtapping on the blank area of the PahnPiiot screen with the stylus causes the Remote Commander program to send a c~ck event (down press fo~owed by a release) of the left mouse button to the PC. A double-cfick can easily be sent to the PC by double-tapping. A tap is determined by a press and release at the same place. Since Windows, and now Macintosh system S, Mow menus to stay up when cficked on, this is an easy way to select items in menus and to push on-screen bnttons. User experience with tis tapping is mixed It appears to take practice to be able to tap without moving, and novices seem to draw fitie fines when hey want to tap. On tie other han~others seem to tap by acciden~possibly due to some bounce of the stylus on tie surface, or when trying to draw SW items. We will continue to investigate adjusting the parameters to see if we can etinate these problems.
In many cases, it is dso necessary to drag with the button held down. '~ragging" is when the mouse button is pressed somewhere, then the mouse is move~and the button is released at a different poin~To support drag=tig, we first added a 'Drag" button to the Remote Commander screen (see Fi=we 1). Pressing on this Drag button starts the drag-@ngby sending a left down even~The user can then move %e stylus. Pressing on the Drag button a=tin wi~end the drag by sending the bntton-up even~Experience suggests that the Drag button is not a partictiarly good id% because people frequendy make mde errors, where they forget whether the mouse button is pressed or no~and end up drawing a line when they planned to just move the cursor, and vice versa.
We added a third way to signal pressing of the ,-.-y.; u mouse buttons, which proved to be the most SUC-~..cessful way to drag. This uses the up and down " physical buttons in the center botiom of the PahnPilot (shown in Figure 1 and at right). We use the up button for the left mouse button, and the down button for the right, which is similar to the way many laptops handle the mouse buttons. It is easy to hold the PahnPilot so that the thumb of the non-dominate hand (e.g. left hand) can work the buttons while the dominate hand (e.g. right hand) draws with the stylus. Experience shows that people do not have much trouble coordinating their two hands for this task. Unfortunately, the up and down buttons on the new Palfl version are harder to use. We wdl be investigating the support for "tap-drag' as on some touchpads, where users can tap and quic~y start dragging to signal a press and drag. Unfortunately, this has many usability problem so experimentation will be necessary to see if it is useful and to fine-tune the parameters.

Emulating the Keyboard
Writing characters in the Grtilti area of the PalmPilot will send those characters to the PC as if they were typed at the keyboard. Capital letters and punctuation marks work in the normal way for Graffhi. The PahnPilot comes with a builtin on-screen keyboard, which people often use especially for the obscure punctuation symbols for which they may not have memorized the Graffhi gestures. Unfortunately, this keyboard does not have rdl the special keys found on the PC keyboard, We F1 and~C, so we had to create our own on-screen keyboard. Just like the regular PahnPilot keyboard, you pop-up the Remote Commander's keybomd by tapping the stylus inside the "abc" area (also labeled "abcde" on some PahnPilots) at the bottom left of the Graffhi area. This brings up the screen shown in Figure 2, on which you can tap the desired keyboard key. To dismiss the keyboard, tap in the "abcde" area again, or tap the 'Done" button of the keyboard at the bottom righ~or use the Menu command when the keyboard is displayed. The small area above the keyboard is sWI available to make mouse movements or taps.
The "Shifi' "Ctr~and "At" keys on the on-screen keyboard modify the characters hit on the keyboard, and will dso modify Graffhi characters and mouse clicks. For example, to do a S~-CLICK of the mouse, you can tap the "Shiff' area on the keyboard and then tap the stylus in the q . upper area. ,.
Because S~, CONTROL and ALT clicking is so common, we wanted to provide more convenient methods for doing Wls, so we allow the four physical "application buttons" at the bottom of the PalmPilot (see Figure 1) to be used as S~, CONTROL and ALT and FUNCTION. , Litie labels above the keys show the assignment of the buttons, as shown in Fi=we 1. Since these buttons nody allow the user to quicHy switch to a different P~iot application, the use of these bnttons as shift keys can be tumd off with a Remote Commander menu command, if desired Fimre 2. The Remote Commander's on-scrmn kevboard.
The~'C~ON button allows Gfiti characters to send dl the speci~PC keyboard keys. We defined a mapping of letters to tie function keys so the user never needs to pop up the keyboard For example, holding down the function button while making the 1 gesture sends Fl, using TCTION-e sends =CAPE, etc.
Connecting the PaImPilot with the PC To use the PahnPiiot to control the PC, hey n~to be coMected 10 each other. Our gofi for the connection tihnology include rnini~interference with the use of the Pdtillots, continuous connections w~e users are writing on the Pd~llots, mdtiple P*iots operating at the same time in the same roo~and miti power consump tion.
Idedly, we wotid use some sort of wireless technology. The most popdar short-range wireless technology is infrared @), but this has many problems for our application. For example, the R built into the new Pm version of the PalmPilot appears to transmit for ordy about 1 meter, and it must be aimed at the receiver (in the same way that a TV remote control must be aimed at the~. Ody one Pd~device can he operated in the same area at a time @mause they interfere with each other), and the R W require a lot of battery power, so you wotid not necess~y want to use it for long periods of time. The designers of the P=cTabs [24] had to go to enormous lengths to make the R work in those devices, including insting mtitiple transmitters on each ParcTab, receivers on the cefigs of every roou and an elaborate software protocol to derd with mtitiple transmissions. They stil reported problems, especially with mtitiple people trying to transmit at the same time. We hope that future R technologies, We~A level 3, will resolve tiese problems for the PahnPdoL Another \tieless possibility is radio. There is a wireless modem for the PrdmPilot for about $500, and Bell Atiantic I offers wireless htemet service for about $50/month for each PdmPdoL~Is seems too expensive to use in our I Remote Commander. Other radio-based options may soon ( be available, such as the "BlueTooti' Iocd-area radio network @ttp://www.bluetooth.com).
h the meantime, we are using a wired solution, which has the advantage of being ffexible, inexpensive, and easy to set up. It lets us explore the various user interface and systems issues, and is practicrd for use today.
The Remote Commander currenfly assumes the devices are connected using the built-in serird ports of the PalmPilot and the PC. The easiest way to do this is to simply use the cradle provided with the PalmPilot. However, using the PahnPilot while it is in the cradle is quite clumsy, so instead, we usutiy use the HotSync cable sold by 3Com, which does a nice job of staying attached to the PrdrnPilot without getting in the way. It is dso inexpensive. h order to connect multjple PahnPilots to a PC at one time, the PC needs multiple serird ports. For desktop PCs, there are many cards avtiable which provide multiple serird q ports. The one we found costs about $400 for 8 ports. For laptops, we found the QSP-1OOPCMCIA card [19] which provides 4 ports (see Figure 3) and costs about $500. Most laptops have 2 PCMCM slots, so this allows up to 8 serial ports using two cards in the laptop. The cards self-configure under Windows95 and use a sequence of COM ports.
!-! ,-  shown in Figure 4. Cficking on the "Add Pofl' button brings up a &dog box in which a serial port number can be UT@ md a mer name specified.The 'TowerPoinY widgets in the midde are discussed in the next section. The Remote Commander can hande as many users as there are serial ports on the PC. b the future, we may try to make MS modtie more self-configuring, by having the program automticfly ch~k for P-ots on the PCS serird pofi.

PowerPoint version
Of course, Remote Commander can interface with my existing Windows application, bmause it just emdates the re=dar mouse and keybomd. However, we want to experiment with a&pting titing applications so they are more amenable tojotit use by mtitiple people in the same roon As an experimen~we added a specifl feature for using the Remote Commander with hficrosoft PowerPoint (versions 7.0 or 97SR-1)-h p~esentation mode in PowerPoin~nordly cticking the moused change to the next sfide, but if you go into "pen" mode, then you can draw on top of the sfides in vtious colors. When the Pow'erPoint checkboxes in the midde of tie Remote Commander me selected (see Fi=me 4), then whenever the user drags on the PahnPiiot en~Remote Commander \ti send out codes to set the color of the pen to that user's coIor. For example, in the case of Fl_we 4, whenever Brad drew on a sfide using the PdrnPflo4 the ink w'otid be black and HerVs drawings wodd be gr~n (see Fi=we 5). Remote Commander picks unique colors for each user, but users can change their colors by using the menu shown in Flame 4. It is important to emphastie that we achieved this without any modifications to Pow'erPoint -Remote Commander just uses the standard commands avdable from Pow'erPoin~The color change commands are sent before each mouse drag event (down press) to make sure that the color is set corrwdy for each user.
An observation w'tie using this feature in early versions of Remote Commander was tha~not surprisin~y, users often made ]w& ewors where they forgot to turn the Pow'erPoint mode off when switching applications. Remote Commander 290 would then send the PowerPoint change-color commands to the current application, which would do various incorrect actions. For exarnple, it was not possible to un-check the PowerPoint mode in the Remote Commander PC module because the color change commands would cause the modtie to quit! Therefore, we added more checking to try to detect whether the front-most window is redly a PowerPoint presentation and ody if so, does Remote Commander send the color+hange commands.
ti the future, we would~ie to investigate special versions of Remote Commander for other applications. For example, Microsoft Word allows the color of the text to be changed. Mthough Word lacks built-in keyboard commands to change the color, it would be easy to build special styles or macros to change the color, assign keyboard commands to these, and then have the Remote Commander execute these -, commands before each keystroke. Then, each user's input would appear in a different color. Similar techniques could be used for Excel, Pain$ and many other tools. This is a very versatie capability that would allow gesturing and annotation on top of many different applications, without the need to change the applications themselves. Eventutiy, it might be better and more robust to use OLE integration to conmol the applications, instead of sending special text as commands.

Experiences with Remote Commander
When we use the Remote Commander in meetings, we find that people inhi~y 'fiddle around' by moving the mouse even when they are not planning to do anything, which interferes with otier people's attempts at red work. The result is that someone wfll teU another to stop sending input. This problem seems to disappear with practice, but if we want to address ig Greenberg recommends having a timeout period so that one person automatically keeps the floor until~q .. there is a delay of (say) 3 seconds since their last action. At that poin~it becomes a first come, fwst served for the next person who tries to input to the shared surface [10].
The feedback from the users who have dotioaded the Remote Commander has been quite positive, and we have , received many nice compliments. Some substantive sug-i ""' gestions from users that we have included in the new version include key repeat when the user holds the stylus over an on-screen keyboard key, adding acceleration for cursor movemen~and supporting "Paste" in the PdmPilot : modde so text typed into other PahnPilot applications, like Memo, can be easily entered into the PC. Ideas from users ; SW under investigation include the ability to support turn-; ing the PahnPdot upside down or sideways, so the physicalb uttons wotid be in a more natural position (but Grtilti wodd not work in tiese orientations), and to have the cnrsor on the PC continue moving when the SVIUSis pegged at the side of the PahnPfiot screen. We will continue to gather feedback and ideas from the users and our own experience with Remote Commander.

PEBBLESDRAW
In 3ddition to Remote Commander, we bfit another application, c~ed PebblesDraw, to explore Wowing all users to have their o~rn cursors. PebblesDraw is a mtiti+mor drawing proe-th3t is analogous to other "shared white-boar~applications, with one important differen= here W the users shine the S-display-Thus, PebblesDraw qutifies as Single Disp13y Groupware. PebblesDraw is implemented using the Amtiet tooWt [15] on the PC.
The initial design for PebblesDraw is shown in Fi=me 6. Cficking on the "Add User button at the bottom Mo\vs the name, sefird port n~ber and the shape for that user to be entered. M active users are shown along the bottom of the window. At tie left are the conventional drawing and color palettes. At tie right is a button panel that contains the most common commands.
In cr=ting this application, we discovered a number of important issues not addressed by previous SDG applications. In partictiar, the standard widgets, me selection handles, palettes, and pti-down menus, do not work for mdtiple users. Previous SDG systems had fide state information associati with Each user. For example, in KdPad [23] there =e no selections. Tivofi [1S] supports ody a few pen widths. h~~l [4] ordy derdt with up to 4 users. We wanted to support more of the choices avfiable in typical drawing pro=~so a more gened mechanism was required. k addition, we wanted tie interaction s~le to be stiar to conventionti direct maniptiation applications, so it wodd be famifiar.
The problem with conventional selection handles is that they do not show which user has the object selected. One god for PebblesDraw is that each user's actions are inde-penden~Each user therefore must have their own separate selection handles. Most previous SDG applications, such as MMM [4], assign each user a color. Since PebblesDraw Mows each user to select a color that til next be drawn, we thought using color-coding would be confusing for a * drawing editor. k fac~the developer of~dPad [23] reported that using color as feedback was not a good idea , because kids had difficulty with it. COLT [5] also used a color to identify people, and reported running into trouble with one color-blind user.
For rdl time reasons, we assign each user a shape. The model was a game We Monopoly where each person picks a shape as their piece. The same shape is used as the user's cursor, and to show the user's selection, to show the text editing position, and to mark the user's commands in the undo history. We designed a set of shapes that could be easfiy distinguished when they are very small (11x11 pixels). We dso needed each shape to have a pointy part at the upper Ie& so it would be clear how to use them to point at ;. objects. The complete set of the current icons is shown in Figure 7. When a user executes an operation, it will ody operate on that user's selected objects. Thus, in Figure 6, if Brad does a CU4ody the yellow ovd will be affected. Currentiy, multiple people can select the same object at the same time. The cursor shap= are designed so users can always see that the object is multiply selected, although it can be difficult to te~by which users. The operations have the expected result if hvo people manipulate on the same object at the same time. h the future, we might want to disdlow multiple people selecting the same object if this proves too confusing. Mtematively, we might make it easier to see which users have tie object selected. For example, since there happen to be eight handles around an object and we support up to eight shapes, an obvious idea is to divide the handle positions among rdl the users who have this object selected. However, this might confuse users into thinking that they can ody change the object's size from the handles that have their shape. Further stndiw of these issues are planned.
The problem \tith the standard design for palettes is that the currendy selected tool is displayed in the palette itself (see Figure S), which does not work if different users can have different mod~. H one user is drawing a red circle at the same time that another is typing blue tex6 how would that be shown? Most CSCW applications are for multiple machines and assume that each user can see their own private copy of the palettes on their own separate displays, ;O this is not au issue. The h~~l palettes did not show any state information and showed each user's current modes ody in the home ara. The Tivofi project [1S] mentioned this problem with palettes, but apparendy provided no fedback as to the users' modes.
Fi~e S. As a single-user application, Microsoft Paint can show the current tool me tool), the current be style (medium) and the current colors (red tie and white fl) in the Palettes.
To solve this problem we provide the feedback for M the user's modes both in that user's cursor as we~x in the picture for that user at tie bottom of the window. The bottom row corresponds to the home arm in -but we feel that having the modes dso in the user's cursor wifl be less confusing and will require less eye movemen~CEcking on a item in a palette (at the left of Fl=me @ copies that mode into the user's cursor and home area Notice that the palettes do not show a current mode. kstead, the current tool is shown in the center of the box attached to the cursor, tie fine color is shown in tie oudine of the box, and the fl color is shown inside the box. k Flame 6, Herb is using the star cursor. He is currentiy in select mode, and is growing the blue rectangle. Brad is *O in select mode, and has the yellow ovd selected Robert is drawing a fieehaud shape. Both Bonnie and Mbert are editing the second row of texf ich user's text input cursor has that user's icon hanging from i~so users can simtitaneously edit text and stil know where they are working. Other mtiti-display CS~systems have usd tils kind of "overload= cursor to show the status of the various users [11]. Another issue relates to dropdown and po~up menus. The problem is that the menu for one user might pop up on top of where a different user is working, especitiy for the large menus typical in today's apphcations. Therefore, we try to minimize the use of pop-ups, so a button panel Mows the most common operations to be performed without using a pop-up menu (see Figure 6).
Another issue is .=ying out of illegal items. Since ody one user at a time can use the drop-down menus, it makes sense for tie items in those menus to gray out as appropriate for that user. For example, if Bonnie has nothing selected, then if she wodd use the dropdown menus, the commands that require a selection would be grayed out However, the button panel of commands (at the right of F1=mre6) is always visible. Therefore, it does mt work for items to be grayed OUL because some commands will be valid for one user but invdld for another user. Therefore, we had to modify dl the operations to make sure that they dld something reasonable, We beep or display an error message, if they were invoked when they were not valid for the current user. The previous implementation of these commands in Amulet assumed that since they would be grayed oug they could never be invoked when not vrdid. Another idea is to gray out the illegal items after a user starts interacting with the widgeg since other users are locked out until the first user finishes.
Gesturd input is a quick and easy way to give commands without using a tool palette. With a gesture, the path of the input device is used to inte~ret the meaning. L&e Tivoli [1S], PebblesDraw supports gestural input. For example, in PebblesDraw, making an 'V shape while pressing the right mouse button (or the bottom PdmPilot arrow button) creates a new rectangle no matter what the current selected mode is. Making a circular shape with the right mouse button down creates a circle. Other gestures support entering fines and tex~deleting objects, and undo. The advantages of gestures are that the user does not have to keep going back and forth to the palette to change tools, and the single gesture defines both the operation to perform, and the parameters such as how big the object should be.  Figure 9. Undo didog box [14] for PebblesDraw where each command is marked with the shape for the user who performed it.
The undo dialog box for Amulet was augmented to annotate each command with the shape for the user who executed it (see Figure 9). The normal Undo command undoes the last executed command no matter who executed it. The Undoby-User command undoes the last command of the user who executes this undo command.~Is takes advantage of Amulet's selective undo mechanism [14] which can undo any previous operation if it still makes sense. For example, in Figure 9, if Herb (who is using the star shape) performs undo-by-user, it will skip over Bonnie's commands and undo the Move of a rectangle (command # 34). If that rectangle had been deleted by a different user, then Herb's attempt to do undo-by-user wodd just beep, since his last command could not be undone. Of course, regular undo is ,. always possible. Mdti-user undo has been previously studied in various systems, such as G~A [3].
The implementation architecture that supports PebblesDraw is based the Amulet tootit [15]. Briefly, the part of the Remote Commander that accepts input from the serird ports and then converts it into events is finked in with Amtiet's low-level input han~lng. hstead of inserting these events into the re@ar Windows input stre~as for the re@ar Remote Commander, Amtiet was au=mented to direcdy accept multiple, ptilel streams of inpu~The Amtiet behavior objects (crdled 'Interactors") and widgets were au.mented to accept a mer-id parameter. H tie user-id is a particular user's i& then this widget is reserved for use by ordy that user. Each user in PebblesDraw has a separate selection handes widget using tis mechanism Special values for the user-id slot include "mzyone," which means everyone can use MS widge$ even simdtaneously, and "one-ata-time, " which means that whoever starts US-mg this widget gets to finish their interaction and other users cannot use it until the fist user is finished. One-at-a-time is the default and the buttons, palettes, scro~bars and menus are d marked as one-~-a-time.
NTeenvision PebblesDraw as being used to rdlow mtitiple users to create or annotate dra~tings at the same time. To make it more useful as an annotation tool, images can be read in and annotations added on top. The annotations can be save~read and further edited. For example, Fi=me 10 shows PebblesDraw being used by 3 people to annotite a plan on a map.

STATUS AND FUTURE WORK
The first version of the Remote Commander was released for general use, as mentioned above, and the second version along with PebblesDraw \til be released shotiy. One important area for Mer research is to more formally evaluate the Pebbles applications.
We have many exciting ideas for future work for other ap pfications which might benefit from mtitiple PDAs connected to a PC We are cnrrendy working on a Chat progr~so that one PDA user can write a note that ti be seen on one or more other PDAs. This might be useti for passing side notes in a meeting. Another application might support voting, which cotid eifier be foti secret or rolecrdl votes, or the info-'%OW is the speaker doing" style of votes that were done for tie ParcTab [24].
Another project in progress is joint work with Mex Waibel to use his NPen+ handwriting recoetier [13] with the PdtiIlo~NPenti is much more accurate than previous attempts &ie the Apple Newton), but is currenfly too large to run on the PdrnPilo~Therefore, we \@] use the Remote Commander mechanism so the reco=tier can run on the PC and the writing can be performed on the PahnPfio4 and tie recognized words can then be sent back to the PahnPiiot for display. This wodd rdso~ow handwriting to be used as input to arbitrary PC 3ppfications. Some new mice, We the 'TntelliMouse" from Microsoft and the "ScrolPoint' mouse from~M, have an extra input device behveen the two buttons which can be used for scro~lng. k earlier work we found that it is more effective to use the other hand for scrolling, since then the user will natily operate both input devices at the same time [6]. ' We wi~explore using the PDA as the other input device, so it can be used with the other hand for scrolling. hstead of having the users' current modm shown in the cursor as in PebblesDraw, they might be shown on each person's PDA screen. Then, the user could easily see and choose the desired mode. The PDA can also be used as the user's "private space," if they want to compose content before sharing it with the group. Another idea is to use the PDA to hold items temporarily, like the Pick-and-Drop pens [20] that make it easy to transfer information from one computer to another. Once there is a protocol for applications to dotioad their controls onto the PDA, this could be extended to allow the PDA to be a general-purpose con-* tro~er for any device, not just a PC program. For example, the PDA could control house-hold appliances, light switches and thermostats.
Of course, we want to explore many other applications of these ideas to new domains. The CSCW literature contains many interesting programs designed for multiple computers, such as 'electronic Brainstorming" and "Structured I Idea Generation Process" from Univ. of Arizona [16] and , Xerox PARCS Cognoter [21]. We want to see which oft iese \til be effective if used with PalmPilots and a singleP C display.

CONCLUS1ONS
%Tehave developed app~cahons to investigate many interesting uses for mdtiple PDAs connmted to a PC. The Remote Commander application dlo}vs mtitiple co-located users to take turns contro~g the mouse and keyboard of a PC~vithoutleaving their sea~me PebblesDra\v application demonstrates interaction twhniques that dlo~v mtitiple users to tvork on the same display simtitaneously.~ese tools can be useful for forrnrd and info-meedngs, and even for a single user. Using PDAs in this \vay takes advantage of technolo~that people rdready have and have fieady learned, and does not require changes in~vork habits. We are excited about the potentird of this approach and the positive response~vehave received from initial users.