GroupLab, Department of Computer Science Publications Saul Greenberg GroupLab Dept Computer Science University of Calgary

Moving Between  Personal Devices and Public Displays

Saul Greenberg and Michael Boyle

Department of Computer Science
University of Calgary
Calgary, AB, T2N 1N4, Canada
+1 403 220-6087

Cite as:
Greenberg, S. and Boyle, M. (1998) Moving Between Personal Devices and Public Displays. In submission to Workshop on Handheld CSCW, to be held at ACM Conference on Computer Supported Cooperative Work, November 14, 1998.


We are investigating how people move from individual to group work through the use of both personal digital assistants (PDAs) and a shared public display. Our scenario of this work covers the following activities. First, individuals can create   "personal" notes  on their PDAs. Second, when individuals meet in real time, they can selectively "publicize" notes by moving them to a shared public display. Third, the group can manipulate personal and public items in real time through both PDAs and the shared public display, where the notes contained on both PDAs and public display are automatically synchronized. Finally, people leave a meeting with a (more or less) common record of their activity. We describe a fully implemented system called SharedNotes that illustrates how people move through this scenario. We also highlight a variety of design issues.

Keywords: Personal digital assistants (PDAs), single display groupware, distributed groupware, disconnected computing.


In this paper, we explore the distinction between personal and public artifacts, and its consequences on the design space for CSCW tools.

Personal artifacts are things created, manipulated, and owned by one and only one person. Public artifacts differ, as they are created by cooperating group members, are considered owned by the group rather than any individual member, and are viewable and manipulable by all. Of course, these definitions just indicate two extremes in a spectrum: in everyday activity, people fluidly shift their artifacts from personal to public and the many gradations between. In a business context, for example, a person may prepare some personal notes, bring them to a meeting, and offer some or all of them for public consumption. Depending on the situation, others may copy these notes, add to them, and perhaps even take some of them away for their own personal use, thus completing the cycle from personal to public and back again. Another example is a group working around a shared visual surface, such as a large sheet of paper on a table top. Individuals may draw items close to themselves: while others are aware of this activity, these drawings are considered personal. At an opportune moment, the person may offer it to the group by drawing attention to it, thus making the drawing public (Tang 1991). At that point, the group may co-opt the drawing, where any member can add or modify it at will.

In these examples of everyday life, people's actions when shifting  artifacts between personal and public are straightforward. People's actions in groupware, however, presents a different story. Typical groupware either does not distinguish between personal and public artifacts, or does so in ways that make the transition between the two awkward and heavy-weight. Consequently, our research interest is to create software that supports these transitions, and to understand its design nuances.

To pursue this research, we designed a system called SharedNotes that allows people to create and manipulate both personal and public notes between two devices: a personal digital assistant (PDAs, in this case the 3COM Palm Pilot), and a shared public display (also known as single display groupware) implemented in GroupKit (Roseman and Greenberg 1996). What makes this choice of devices interesting is that PDAs are perceived as highly personal devices, while single display groupware are highly public devices. However, we wanted these two devices to support both personal and public activity.

We begin with a scenario of activity that illustrates how we envisage the use of our SharedNotes system. The scenario will illustrate the following points.

  1. Personal Work. Individuals can create, rank, and annotate personal notes created on their PDAs.
  2. From Personal to Public. Individuals can selectively publicize notes: when the group meets in real time, they are automatically replicated to a shared public display.
  3. The Public Arena. The group can create and manipulate both personal and public items in real time through both PDAs and the shared public display. Notes contained on both PDAs and public display are automatically synchronized.
  4. Between Meetings. People leave a meeting with a (more or less) common record of their activity. The record is not static, as they can continue working with it.

We will then raise a variety of design issues and concerns that we plan to discuss at the workshop.


Our scenario describes how a few people who are setting up a usability laboratory explore their equipment requirements. We will imagine that this began through an email exchange, where one person suggests to others that each think about what equipment is needed, and that all would meet to discuss these items in a meeting on the following day. We will take the perspective of Michael, one of the team members.

Personal Work.

While taking the bus home, Michael starts thinking about some of the equipment needed. He pulls out his 3Com Palm Pilot and creates a new meeting called Usability Lab which will contain his---and eventually all other people's---notes on the topic (Figure 1). He enters the meeting and starts listing some equipment he would like to see. These appear as items in the "Personal Notes" pane of his display (Figure 2, lower half). He also gives each item a rank, from 1 (high priority) to 3 (low priority) (Figure 2, lower left). He then adds an annotation to one of his notes by tapping an annotation icon (Figure 2, right side) and filling in the pop-up Note Annotation dialog (Figure 3). The annotation icon's appearance then shows which notes have attached annotations. Finally, he decides that he would like to tell the group about some, but not all of the equipment he has listed. He does this by tapping the publicize checkbox next to the relevant notes, which will publicize it to the rest of the group when they next meet (Figure 4). Over the course of the evening, he sporadically creates new notes, modifies existing ones, and adds annotations as ideas come to him.

fig1.gif (40726 bytes) fig2.gif (43433 bytes)
Figure 1. Creating/selecting a meeting

Figure 2. The personal / public space


fig3.gif (40874 bytes)

fig4.gif (41115 bytes)

Figure 3. The annotation dialog

Figure 4. Pending public notes

From Personal to Public.

The following day, Michael and the others meet in their laboratory, which includes a large public display and attached PC. Because Michael happens to be the first one there, he turns on the display and readies the custom software that can communicate with the Palm Pilots. He then seats his Pilot onto a cradle attached to the computer (in the future, this will occur automatically through wireless technology), which immediately propagates all of Michael's personal notes that have been marked as publicize onto the public display (Figure 5). Unlike the Pilot interface, the public display actually behaves as a structured drawing editor:  text notes can be moved around and drawing marks can be added.  As notes are publicized, they are moved from personal to public pane on  Michael's Pilot. For example, the snapshot in Figure 6  shows the personal and public display being synchronized, and how the publicized notes now appear on the public pane.

fig5.gif (4941 bytes) fig6.gif (42099 bytes)
Figure 5: The public display after Michael has connected Figure 6. The Pilot display during connection

The other people start coming into the room, and connect as well. As they do so, the   personal notes they had checked as publicize are also propagated to the public display. Conversely, all public notes appear on each person's Pilot, in the Public Pane. In Figure 7, we see that Michael's Pilot now containing other people's notes (e.g., there are now 9 public notes) that was checked as publicize by another person on their Pilot . If Michael wanted to, he could choose via a menu option to see all publicized notes (as in Figure 8), only his own publicized notes (not shown), or only other people's notes (e.g., Figure 9).

fig7.gif (5356 bytes) fig8.gif (41503 bytes)fig9.gif (41473 bytes)
Figure 7-9: The public and pilot display showing public notes. In Figure 9, only other people's public notes are visible

The public arena

At this point, people can discuss these notes and individuals can manipulate them via the public display and their PDAs. However, the PDAs and public screen enable different features and powers.

On the public display, people can create new text items and edit older ones directly (e.g., a new note titled "Studio monitor" is being added at the bottom of Figure 10), and these will propagate down to the Pilots (Figure 11, last item in the public pane). These text items behave just like the other drawing objects, and can be repositioned, deleted, selected, and so on, as illustrated in the differences between Figures 7 and 10. Participants can also draw on the public display e.g., the box and circle in Figure 10. Annotations are revealed by selecting an item (the pop-up window in Figure 10). While individual's personal annotations cannot be edited on the public display, a new "Public" annotation can be added and edited (in this case, the public display is named "GroupLab".

On the Pilot side, Michael can continue to create personal notes and publicize them at will. By selecting the annotation indicator for any note in the Public pane, he can view annotations made by others, and can edit his own annotation (Figure 12). He can change his own ranking of that note, which will be reflected back in the average ranking score. However, he cannot change the contents of the actual text  note for reasons that will be explained later.

During this meeting, people may move between connected and disconnected work, simply by moving their Pilots in and out of the cradle. The contents are resynchronized when connections are made.

fig10.gif (9191 bytes)
Figure 10: Viewing all public notes and an annotation
fig11.gif (41402 bytes) fig12.gif (40639 bytes)
Figure 11. The updated public note Figure 12: Public annotations

Between Meetings

At the meetings end, the session is saved.  The public display maintains a persistent version of all the work done so far (e.g., Figure 13 shows the final view of the public display). Michael (and all the others) walk away with a textual record of the meeting notes on their Pilots. However, this is not the end. Over the next few days, Michael and the others can add and edit new personal notes, and can further annotate or re-rank public notes on their personal Pilots. Alternately, one or more of the group members can work on the public display as needed. Whenever connections are made, the information is automatically synchronized and propagated as required.

fig13.gif (7828 bytes)
Figure 13. The  public display at the end of this meeting


While the scenario is plausible (and the interface perhaps convincing), there are a few oddities in the system itself. In particular, we intentionally made several design decisions that took a somewhat extreme stance on the way people had to perceive and manipulate personal and public artifacts. We did this to draw out design nuances, rather than hide them. If there is time at the workshop, we would like to discuss these design nuances and resulting issues, described and listed below (in no particular order).

Should the system make an explicit distinction between personal and public notes? SharedNotes makes this distinction in many ways. Personal and public notes are placed in separate areas on the PDA; people cannot edit and manipulate them the same way; and so on. We could have designed the system so that there was no distinction, where all notes would be publicized as soon as people meet.  A personal note would simply have been a public note not yet visible to others because the opportunity had not arisen. While this would give us a vastly simpler system, it also implies that people would have no ability to keep things personal (such as items they were not ready to offer to the group).

Should people have to take explicit action to publicize notes? Similarly, individuals now have to decide what they want to offer to others and take explicit action---checking the publicize box---to publicize a note. Perhaps notes should be automatically publicized, as mentioned previously. The tradeoff here is that this denies users the opportunity to express personal relevancy, and discourages them from using the tool as a medium in which to develop ideas. Or perhaps another interaction technique, such as Pick and Drop (Rekimoto 1997) would make this a more natural rather than abstract decision.

Personal notes, once made public, cannot be made personal again. Moving from personal to public is a one-way operation. We took this position because of the odd nature of groupware: it is unclear as to what is an original, and what is a copy. For example, if I take a personal sticky note and paste it onto a whiteboard for others to read, it becomes public. If someone takes it off the whiteboard and puts it into their pocket, it is personal again since it is no longer available to others. Alternately, if someone copies  the text of the note onto another sticky and places it in their pocket, there are now two copies: one public (the one on the whiteboard) and one personal (the one in the pocket). In contrast, we had to decide how things were treated in our electronic medium. Our design is based on the idea that as soon as a note moves to the public display, that is the only copy of the note. People walk away with a view of it, but not the ability to change the original. If we did allow them to change the note, then we have a problem of what to do when people come back together: we would now have multiple instances of a single item. Conversely, we could have designed the system around the idea that everything on the PDA is just a copy of the public note, but this too introduces complexity when managing different versions. There is no clear solution to this problem. Although algorithms and approaches are available to handle these types of inconsistencies, it just isn't clear what would make sense to a person using the system.

There are personal aspects of public notes. Public things can have personal aspects to it. In our design, for example, the text of a note is completely public. Once offered to the group, it loses its sense of identity i.e., its creator no longer has any special claim to it. Thus the text can only be edited in the public forum. Annotations differ, however, because they do retain their sense of identity. For example, a single note can have multiple annotations. Consequently, all annotations are in the public view, but individual creators (and only the creators) can modify individual annotations. Thus an annotation is a personal aspect of a public note. Similarly, individual ranks added to notes are personal aspects: each individual can alter their ranking, which is reflected in the averaged public view of the rank. While this may seem somewhat obtuse, we decided to design Shared Notes this way precisely because we wanted to retain and explore the distinction of partial ownership.

Public notes live on the public display. The master copy of all fully publicized notes reside within the public display. The public display is persistent, as it remembers these meetings and notes between sessions. When people leave and come back in at later with their PDAs, they are effectively updating the public display with new notes and annotations made on the PDA, and the public display  is propagating any changes from others back to the PDAs. Thus the public display is a kind of central server, while the disconnected PDAs contain replicas of  the information stored on the server. A benefit of this approach (along with the editing restrictions mentioned earlier) is that it makes updates easier and unresolvable conflicts rare. As well, people are assured that the public display will always contain the "latest" copy of all who have touched it with their PDAs. While disconnected, non-present people may have PDAs containing out of date and different versions of the information, the people connected to the public display will not see it. An alternate scheme would have a completely replicated database maintained on PDAs only, but this would introduce a myriad of problems in terms of deciding what is the most recent copy. However, this would allow people to exchange information outside the presence of the public display.

The PDA is not merely an input device. A variety of other researchers have examined the use of PDA with single display groupware as merely an input device e.g., Myers, Stiel and Gargiulo (1998). That is, the PDA does not maintain any notion of the meeting and its artifacts beyond the ability to manipulate them during the course of the meeting. Of course, our view is that the PDA is a personal device, and as such should record a personal view of the meeting activity. Thus it is a first class device, with different powers than the public display but still equal in status.

The PDA and public screen are different entities enabling different acts. We could have designed the PDA and public screen to have identical interfaces e.g., where the public display just looked like a large Pilot. However, we felt that each device was quite different, and that the types of things one would do with each device demanded a different set of powers and interface features. Thus the public display has no notion of personal items (as it is a public device). As well, the public display gives power to the group that is more in keeping with how people view and manipulate shared visual spaces. In this case, it is treated as a whiteboard with the difference that text items are shared notes with special properties. We did not give this power to PDAs, because spatially manipulating and editing notes within such as  limited screen did not seem like a good idea. Similarly, we felt that the PDA would be better for idea creation, rather than for group discussion. This is not without its problems, for it also means that items brought back into the PDA's public space do not maintain the spatial relations between notes.

Summary and Next Steps

This is work in progress. We are trying to understand the distinction between personal and public artifacts and how groupware design can support the way people use them. Our Shared Notes system was created to bring out some of these design issues, and to help us articulate the design space around these types of systems. We listed a few issues, but there are others we have not mentioned. For example, should people be able to move artifacts from personal to public in a continuous way, rather than in a discrete manner as done in SharedNotes? Should inconsistency be allowed, as it would give people greater powers over the artifacts contained on their PDAs?

We are now investigating these and other factors relevant to using PDAs as personal and public devices. We are considering how consistency is maintained, how to deal with devices that operate in both connected and disconnected fashions, and how to manage differing interfaces across PDAs and public displays. We are also extending this work to add remote capabilities to the system, and have implemented a new version where people can connect to the public display from their desktop and PDA even when they are separated by distance.


  1. Gutwin, C. and Greenberg, S. (1998) Design for Individuals, Design for Groups: Tradeoffs between Power and Workspace Awareness. Proceedings of the ACM CSCW '98 Conference on Computer Supported Cooperative Work..
  2. Myers, B., Stiel, H. and Gargiulo, R. (1998) Collaboration Using Multiple PDAs Connected to a PC. Proceedings of the ACM CSCW '98 Conference on Computer Supported Cooperative Work.
  3. Rekimoto, J. (1997) Pick-and-drop: a direct manipulation technique for multiple computer environments. Proceedings of the ACM UIST '97 Symposium on User Interface Software and Technology, p31-39..
  4. Roseman, M. and Greenberg, S. (1996). Building Real Time Groupware with GroupKit, A Groupware Toolkit. ACM Transactions on Computer Human Interaction, 3(1), p66-106, March.
  5. Tang J. C. (1991). Findings from observational studies of collaborative work. International Journal of Man Machine Studies, 34(2), p143-160, February.