application of shared window concepts to handheld computers
TRANSCRIPT
00-006 - 1 -
Application of Shared Window Concepts to Handheld
Computers
Technical Report TR00-006
Randal K. Whitehead
University of North Carolina
CB #3175, Sitterson Hall
Chapel Hill NC 27599-3175
Abstract
In this paper we first discuss briefly the role of technology requirements in the acceptance of a
Computer Supported Collaborative Work (CSCW) application and propose a new taxonomy for
classifying CSCW applications. We then introduce handheld computers and ongoing research in
Handheld CSCW (HCSCW), classifying these applications according to our new taxonomy.
Before applying handheld concepts to an existing CSCW application, we examine one such
application, shared windows, in some detail. Finally, we bring all of these concepts together in a
new research project: PShaW (Palmtop Shared Windows).
Introduction
As CSCW researchers we would like to know in advance how well the systems we develop will
be accepted by users. If we have some way to measure the “acceptability” of a system that can
help drive the process of deciding what kind of system to develop. The aspects of such a
measurement would include:
1. A classification scheme to quantify the relevant abstract qualities of a system.
2. Experience with existing systems that have been well accepted.
3. The classification of existing systems related to an area of interest to show gaps where new
systems might fit.
Given these guidelines a new application area might be found.
00-006 - 2 -
Technology Barriers
We begin with the following proposition:
Many of the common barriers to the acceptance of a CSCW application can be attributed to the
necessary introduction of new infrastructure, either hardware or software [Whitehead96]. These
barriers can result from monetary cost, disruption of current work practices (e.g., switching from
a preferred single-user application to a collaboration-aware application), or a disparity in
work/benefit for different users (e.g., extra cost and/or little benefit to early adopters).
If we accept this proposition, then it would be useful to be able to classify a CSCW application
based on these infrastructure issues, and thus gain insight into its potential for acceptance. To do
this, we can create a new taxonomy of CSCW applications, a “technology taxonomy,” as shown
in Figure 1.
Synchronous Asynchronous
High Tech Video Conferencing
Electronic Meeting Rooms
Rich E-Mail (MIME)
Collaborative Writing
Low Tech
Meeting Facilitation
Shared Windows
Meeting Scheduling
Workflow
Distributed Multimedia
Internet News
Text E-Mail
Figure 1 Technology Taxonomy
In this taxonomy, High-tech applications are those that require a level of technological
infrastructure that is not common even in a highly technical workplace. Teleconferencing and
dedicated electronic meeting rooms are examples of high-tech applications.
Low-tech applications are those that can be supported in a typical workplace - even those whose
main enterprise is not technical in nature. Electronic mail is a common example of an
asynchronous low-tech application. Shared windows is an example of a synchronous low-tech
application, even though the technical capabilities that go into creating such a system are
substantial.
An important aspect of this taxonomy is that an application classified as high-tech may, at a later
time, be classified as low-tech. This change may be due to a new approach to the application,
availability of new hardware or software to support the application, or wider use of an existing
hardware or software. The best example of this migration is distributed multimedia applications.
Prior to the introduction of the World Wide Web (WWW), such applications were difficult to
implement and rarely used. With the wider accessibility of the Internet and the WWW, such
applications have become nearly ubiquitous.
00-006 - 3 -
New Possibilities for Low-Tech Collaboration
This migration of applications from high-tech to low-tech can be a source of direction in finding
new application areas to pursue. An example of new or more widely available technology that
might result in such migration is the handheld computer, sometimes referred to as a personal
digital assistant (PDA). These devices’ portability and wide acceptance for storing personal
productivity data suggest that they might be useful for CSCW applications. Such applications
would fall into the category of handheld CSCW (HCSCW).
The Palm™ Personal Digital Assistant
One of the most popular handheld computers is the Palm PDA, made by 3Com, by IBM as the
WorkPad, and most recently by Handspring as the Visor.
The Palm PDA is a small, low-cost, highly portable device (see Figure 2). The front surface is
dominated by a touch sensitive bit-mapped gray scale display and several hardware buttons. User
interaction is primarily with a stylus on the display. The hardware buttons are dedicated to power
on/off, scrolling, and launching applications. It comes with a suite of productivity applications,
including phone/address database, calendar, to-do list, and memo pad, which are activated by
pressing hardware buttons on the front of the device. In addition, third party developers provide a
wide range of applications, including games, email, and alternatives to the standard productivity
applications. The Palm may be connected to a PC or to other Palms by means of a serial cable,
or, beginning with the PalmIII model in 1999, by an IrDA-compliant infrared port. A suite of
software for desktop use, mirroring the built-in applications, is provided so that the user can sync
PDA-based and desktop-based data through the serial port cradle. In addition, users can
exchange data by “beaming” over an infrared link.
Figure 2: The Palm PDA
Other palmtop devices, such as those running WindowsCE, offer similar features.
00-006 - 4 -
Current HCSCW Research
The increasing popularity and capability of handheld devices has led to an increase in research
into their use for collaborative work. The 1998 ACM Conference on Computer Supported
Cooperative Work (CSCW’98), included a workshop on HCSCW [Gellerson98]. The HCSCW
systems described at that workshop represent a cross-section of current HCSCW research in
these areas:
PDAs connected to shared display
PEBBLES [Myers98], Shared Notes [Greenberg98]
Synchronous/Asynchronous PDA use with syncing to common database
Shared Notes [Greenberg98], NotePals [Landay98], NETTO [Munch-Ellingsen98]
Messaging
Prairie Dog [Ayad98], SIMON [Bergquist98]
Group Awareness
Prairie Dog [Ayad98], Hummingbird [Holmquist98],NETTO [Munch-Ellingsen98]
00-006 - 5 -
Collaborative editing
XLibris [Schilit98]
Location-specific information
WorldBoard [Kirkley98]
Shared view of geographic data
QuickSet [McGee98]
Placing these applications into the technology classification, as in Figure 1, yields the mapping
shown in Figure 3.
Briefly, applications were put into this classification as follows:
PEBBLES (PDAs for Entry of Both Bytes and Locations from External Sources) makes use of
multiple Palm PDAs connected by serial cable to a central PC in a conference room. The Palms
are used to control a shared application, e.g., a drawing tool, on the shared display. This is a
synchronous application and is classified as moderately high-tech because it uses additional
networking infrastructure, but otherwise uses existing devices and applications.
NotePals allows multiple users to take personal notes on a PDA, e.g., during a class lecture, and
to later sync those notes to notes taken by others in a web-based database. This is an
Synchronous Asynchronous
High Tech Hummingbird
SIMON
Shared Notes
PEBBLES
XLibris
WorldBoard
SIMON
Low Tech
QuickSet NotePals
NETTO
Shared Notes
Prairie Dog
Figure 3 Technology classification of HCSCW applications.
00-006 - 6 -
asynchronous application and is classified as low-tech because it uses only existing devices and
infrastructure.
XLibris is a system of new handheld electronic books and software for editing documents on
these devices. It is an asynchronous application and classifies as high-tech because it requires
new devices and requires collaborators to abandon favored single-use editing applications to
access the collaborative capabilities.
Other applications are analyzed similarly.
Note that there appears to be a large gap in the synchronous, low-tech portion of the map,
suggesting that this would be a good area to explore for a new HCSCW application. Before
proceeding, though, we should consider what sort of collaboration we would like to support. A
common scenario for collaborative work, with or without the aid of computers, proceeds like so:
Person A is working alone on some task.
A wishes to enlist the aid of person B.
A and B begin to collaborate.
If computers are not involved, this scenario can be played out anywhere. That is, the ability to
collaborate is not location-dependent. Note also that in such a scenario, social protocols are often
used to control the collaboration. The question, for a CSCW researcher, is whether collaboration
using computers can be made as natural as that not involving computers.
Shared Windows as Low-Tech Collaboration
One example of an existing CSCW application that supports a natural collaboration in the given
scenario is shared desktop windows. Such an application qualifies as low-tech because it makes
use of existing infrastructure, hardware and software, to support collaboration. What is added is
the capability to share a view of an arbitrary running application between two or more displays.
Users remain in their same physical environments, make use of existing hardware, and share
their preferred single-user applications.
A typical shared widow system adds a proxy, sometimes referred to as a conference agent,
between one or more applications and the window system on each user’s computer (see Figure
4).
00-006 - 7 -
The conference agent is responsible for:
I/O Multiplexing The conference agent must multiplex the output streams from the
applications to each user’s window system, and demultiplex the input streams from each user
to a single input stream for the appropriate application. Thus, all users have the same view of
all windows associated with a shared application.
Floor Control The conference agent must handle each user’s input according to
whether that user is allowed to control the associated application. There must also be
mechanisms for changing who has the floor.
Workspace Management The conference agent controls the layout and grouping of shared
windows.
Dynamic Reconfiguration The conference agent must be able to add participants and handle
the departure of participants during a shared window session.
Secretarial Functions The conference agent must handle startup and shut down of a
session as well as logging of events during the session.
A shared window system may be implemented with a centralized architecture as shown in Figure
4, with one instance of each application and one instance of the conference agent, or may be
implemented with a fully replicated architecture (see Figure 5) with
many replicas of the applications and conference agent.
Window
system
Window
system
Conference
Agent
Application1 Application2
Figure 4: Shared window system with
centralized conference agent.
Figure 5: Shared window system with fully
replicated architecture
WS
CA1
A11
A21
WS
CA2
A12
A22
00-006 - 8 -
A replicated architecture has advantages in performance and flexibility, but also imposes much
greater costs for synchronization. As a result, a centralized architecture is more common.
Among the issues to be addressed by a shared window system [Lauwers90] are:
Spontaneous Interaction How can the system support spontaneous as opposed to
pre-planned meetings? How are latecomers supported? Three common strategies are:
Histories An event history is kept at the conference agent and replayed when a new
participant joins the conference. This can be centralized, with events replayed in the
window system of the new participant, or replicated, with events replayed in new
application replicas. Although this approach is straightforward it suffers from three
potential problems:
1. Errors in event logging due to state information external to the application.
2. High storage requirements.
3. Poor performance.
Direct state transfer The state vector of the replicated application (in a replicated
architecture) or window system (in a centralized architecture) is transferred directly to
new replicas. Unfortunately, this state transfer is not well supported in existing
applications or window systems. This approach can be implemented by having shared
window state information stored in the conference agent and then projecting this state
onto a new participant’s window system. (This is the method used by SharedX
[Garfinkel94].) This approach, however, also suffers from problems of performance and
storage costs.
Process Migration The entire process of a shared application, including connections to
external services, shared files, etc., is duplicated on the new participants machine.
Although these issues have been solved in some environments, such support is not
common.
An effective means of spontaneous interaction will require:
1. A centralized architecture, where possible. Although this reduces the potential flexibility
of the system, it allows for a more light-weight newcomer support, with each new
participant sharing an existing instance of the conference agent and each shared
application.
2. Greater support, within the window system, for state transfer. This support would include
better organization of state information and provision of set and query operations.
00-006 - 9 -
Workspace Management How are shared and private windows distinguished? How are
shared windows kept consistent? The workspace manager is similar to the window manager,
and some of its work may be delegated there, but there are requirements for workspace
management that cannot be delegated. These requirements include:
Allowing participant to distinguish shared windows from private windows, distinguish all
windows associated with the same conference, and associate a window with a conference.
Maintaining consistent appearance of the shared application, especially in cases where
resizing a shared window may obscure controls.
Maintaining consistent state in the shared application, for example when scrolling in
shared windows of different sizes results in an inconsistent view. This is most often an
issue with a replicated architecture.
These issues can be viewed as relating to the degree of coupling between the participants’
views of the shared application. A very tight coupling, or a What You See Is What I See
(WYSIWIS) view, solves problems of inconsistent appearance and inconsistent state, but
eliminates the possibility of concurrent operation. For example, two users of a shared editor
cannot edit different parts of the shared document at the same time.
One approach to this issue, as with the issue of process migration, would be to implement
more of the application sharing functionality directly within the window manager.
Floor Control How is the shared interaction moderated? Typically this is modeled as one
or more speakers holding the “floor.” The issues here include:
1. The number of floors.
2. The number of people holding a floor at one time.
3. How floor control is passed from one participant to another. Often, this will require some
communication channel (audio?) external to the shared application(s).
The issues can be seen as relating to the amount of concurrency allowed in the shared
interaction – more floors, or more participants holding the floor, suggesting greater potential
concurrency.
Most importantly, though, it should be noted that a flexible floor control policy would be
required to support the needs of a wide range of participant groups.
Annotation and Telepointing How are users made aware of others’ actions? How do the
users interact if audio or video connections are not available? The most common features are
annotation, overlaying text or graphics over the display of a shared application, and
telepointing, displaying a cursor controlled by the participants. These features are most easily
implemented in a transparent window overlaid over the shared display, if the window system
supports such a feature. It may also be implemented XORing the graphical elements into the
shared display.
00-006 - 10 -
Performance How can shared windows be made to perform as well as private windows?
PShaW
To take advantage of the low-tech collaboration possible with handheld devices and to build on
experience with an existing “low-tech” collaborative application, namely shared windows, this
project applies shared window concepts to the built-in applications on Palm PDAs. Such an
application qualifies as low-tech because it:
Uses popular devices, so no additional infrastructure is required.
Uses built-in infrared networking, so collaboration is location independent.
Uses existing applications, so work practices are not disrupted.
The usage scenario would have User A working on some task using the Palm. User B arrives,
also with a Palm, and they decide that they should collaborate on A’s task. In such a scenario,
external social protocols will be relied upon to control much of the collaboration.
The following discussion will be illustrated by screen captures of a small application, SmallApp
(see Figure 6). This application has a user-editable text field, and a numeric counter controlled
by three pushbuttons for incrementing, decrementing or resetting the counter.
Figure 6: SmallApp
PShaW Architecture
The architecture of the system places the conference agent between the application and the
PalmOS by intercepting user interface events before they are returned to the application’s main
event loop (See Figure 7). The conference agents on each device communicate by way of the
built-in infrared port.
00-006 - 11 -
The PShaW conference agent has these main functions:
Interception of UI events.
Receipt and handling of UI events from the remote device.
Display of UI elements for collaborative awareness.
Initiation and termination of a collaborative session.
Enforcement of floor control policies.
Once a UI event has been intercepted it may be:
Handled within the conference agent. This is the case with collaboration-specific menu items.
Deleted (perhaps as the result of floor control or coupling policies).
Transmitted to the conference agent on the remote device and/or passed on the operating
system.
A UI event received from the remote device is passed on to the application based on the floor
control and coupling policies in effect. Some such events would be used for collaborative
awareness, e.g., to draw a telepointer if the remote pen is down.
Some degree of replication in the architecture of the system is required because, unlike X
Windows, for example, there is no window server in the system to facilitate communication. A
fully replicated architecture is used to allow work on a more flexible coupling policy in the
future, even though a centralized architecture would simplify workspace management and floor
control issues. The fully replicated architecture also has advantages in reducing latency.
Ideally, the shared window components would be implemented completely separately from the
application, allowing any existing application to be used collaboratively. At this stage, though,
an existing application is modified to include collaborative features. This is done with as few
changes to the existing application as possible:
PalmOS
PShaW
Application
PshawGetEvent() UI events
EvtGetEvent()
PalmOS
PShaW
Application
IR Link
Figure 7: PShaW fully replicated architecture
00-006 - 12 -
Interception of calls to EvtGetEvent(), for getting an event from the event queue, to a
collaboration-aware version.
Addition of a new menu to the menu bar for the application. This new menu includes
commands for starting and stopping a collaborative session and for floor control (see Figure
8).
Figure 8: Collaboration Menu
Addition of alert dialogs, etc. and other resources related to the collaborative features.
Addition of code for the conference agent.
PShaW Event Model
Because user interaction with a Palm application is by use of the stylus on the touch sensitive
screen, by pressing hardware buttons, or by writing characters on the input area of the screen, the
lowest level of abstraction for these interactions is by pen events (penDown, penUp, or penMove)
or key press events (keyDown). Thus, it is tempting to use these events as the basis for shared
interaction, but some problems arise, most importantly that the PalmOS uses pen tracking and
will watch for pen events on the local device before deciding that a control has been selected.
Simply transmitting a penDown/penUp sequence will not suffice. If less general control-level
events are used for collaboration, then we must determine which events are necessary and
sufficient for interacting with each user interface element. These necessary events are considered
broadcast events and are transmitted to the remote device as well as being passed on to the
PalmOS. All other events are considered local events and are only passed on to the PalmOS. In
addition the event itself, the current focus of the window must also be known. This allows a
keyDown event to be associated with the correct control. At the remote device, the combination
of an event and the current focus trigger a call to an appropriate function associated with an
object type. Figure 9 gives examples of objects and their associated broadcast events.
User Interface Object Broadcast Events Function
Text Field FldEnter
keyDown
FldHandleEvent()
00-006 - 13 -
Push Button
Check Box
Radio Buttons
ctlSelect CtlHitControl()
Figure 9: UI Objects and Events
It should be noted that some of these calls have side effects and may, themselves, generate
events. For example, CtlHitControl() places a ctlSelect event in the event queue.
This can cause conflicts with a floor control policy, if floor control is implemented by blocking
certain events on a device which does not hold the floor, because a local ctlSelect event and one
generated as a side effect of CtlHitControl() cannot be distinguished. This is addressed by having
a remote ctlSelect event issue a “credit” to the corresponding control. A ctlSelect event in the
local event queue will only be applied if the number of credits available to the corresponding
control is non-zero. Thus, the local user cannot violate floor control unless a control has credit
available, but doing so will consume a credit for a remote event in the queue. Typically, the time
between a CtlHitControl() event and the corresponding ctlSelect event is extremely short, so the
changes of a user tapping the same control in that interval is extremely small.
In addition to these control-level events, opening a window triggers a frmOpenEvent event. This
event, in turn, triggers initialization of the conference agent. To date, PShaW has been applied to
only a simple application with a single form, but it is possible for more complex applications to
have many forms. It remains to be seen how this triggering mechanism can be scaled to such
systems.
Shared Window Issues in PShaW
Within the described architecture and event model, the general shared window issues raised
above are addressed as follows:
Spontaneous Interactions Social protocols and external communication are used to
simply have A save the current state and “beam” the necessary data to B’s Palm. Thus the
users begin the collaboration with synchronized data. In situations where verbal
communication was not possible (e.g., in a meeting) some other communication channel
would be required. Once the two users have synchronized states, the user who will be in the
role of client initiates a collaborative session by selecting Start IR from the HCSCW menu.
The user acting as server, receives an alert (see Figure 10) and has a choice of accepting the
connection or not. The client then receives a confirmation alert (see Figure 11), at which
point the collaboration session is established.
00-006 - 14 -
Figure 10: IR Session Request
Figure 11: IR Session Confirmation
Workspace Management In PalmOS applications, the screen is typically taken up by
a single window, so moving and resizing of windows is not a concern if the shared windows
are tightly coupled. If more concurrent operation were supported by future work then
synchronization by a workspace manager would be required.
Floor Control Again, social protocols may be relied upon to coordinate user actions, with
some additional communication channel (e.g., a chat tool) necessary if verbal communication
is not possible. Within the application, explicit floor control is used and only one user may
hold the floor at a time. The other user may request the floor by selecting the Request Floor
item from the HCSCW menu (see Figure 12). The user holding the floor may accept or reject
the request (see Figures 13 and 14). The user holding the floor may also pass it to the other
user at any time. The other user is alerted but does not have the option to reject the change
(see Figure 14). If a user does not hold the floor then their inputs are generally deleted
00-006 - 15 -
instead of being passed to the application or operating system. Exceptions to this rule are
inputs related to:
Exiting the application
Displaying menus
Switching to another application
Figure 12: Floor Requested
Figure 13: Floor Request Rejected
00-006 - 16 -
Figure 14: Floor Passed
Annotation and Telepointing The PalmOS provides a user interface element, a gadget,
which is, essentially, a transparent window that can be overlaid over another widow and used
for bitmap drawings, etc. This will be used to draw a telepointer. It could be used in the
future for annotations.
Performance Most of the work of window and workspace management will be
delegated to the PalmOS, so the mechanism of intercepting and filtering/distributing UI
events is fairly light-weight. However, the processors in these devices are not very powerful
and have proved to be very sensitive to additional processing costs, especially those related
to redrawing the display. Care will have to taken as additional features are implemented to
avoid performance problems.
Current Status and future work
Programming remains to be done in many of the areas described so far, and other features have
not yet been considered.
Work remains in these areas:
Architecture The PalmOS supports so-called “hacks” to allow system-level calls to be
intercepted. This could be used to separate the collaborative functionality from the existing
applications. Methods for augmenting an application’s menus dynamically must be
developed as well.
Event Model So far, only text fields and push-button style controls are supported. Other
interface objects, including tables, lists, and scroll bars, must also be supported. Also,
complex applications with multiple forms must be supported.
Floor Control Additional, more flexible, floor control policies, including an implicit
floor control policy allowing both users to give input simultaneously, should be explored.
00-006 - 17 -
Annotation and Telepointing Currently, a graphical animated telepointer is not
supported. Instead, a text field showing the remote pen’s x:y coordinates is displayed if the
remote pen is down (see Figure 15). Problems with animation in general, including screen
flicker and performance costs, must be solved.
Figure 15: Pen Position
Performance Any significant additional functionality will have to be implemented
carefully to avoid performance problems.
Networking The infrared networking built in to the Palm devices is attractive for
supporting low-tech collaboration, but has proved to be a disappointment. Its limited range,
narrow beam, and line-of-sight requirements make it impractical for real-world use. Some
other technology, perhaps one based on RF, such as Bluetooth [Bluetooth99], will be
required to make this practical.
In addition to completing the work begun so far, these new areas might also be explored:
Coupling The use of a replicated architecture and an event model focused at the control
level instead of the pen and key level, allows for the possibility of a more flexible coupling
policy.
Annotation Once problems with animation are solved in general, the same concepts
could be used to support graphical annotation of an application.
Chat Because social protocols are relied upon to control much of the collaboration, an
additional, non-verbal, communication channel would be helpful.
The most important work to be done, though, will be to compare the experiences in developing
this system to those in developing other shared window systems such as XTV [Abdel-Wahab94]
for X Windows. Particular areas for comparison might be:
Workspaces X Windows provides a very rich workspace, with multiple windows that
can be moved and resized independently, while PalmOS allows only a single window that
00-006 - 18 -
cannot be moved or resized. We’ve seen that this eliminates some workspace management
issues from PShaW, but does it also have some cost in terms of reducing collaborative
functionality?
Event Model X Windows typically has a very complex communications protocol of
requests, responses and events. For PShaW, we have used control-level events for shared
interaction. How does this compare to minimal protocols for shared X Windows [Chung93]?
Processing Power X Window systems typically run on high-power workstations, while
PalmOS applications run on small, low-power handheld PDAs. How does this restriction
affect what features can be provided and how does this affect the usability of a shared
window system?
Communications The inherent problems of infrared networking have already been
discussed, but even alternatives, such as RF-based Bluetooth will have limitations in
comparison to X Window systems which typically communicate over high-bandwidth
channels. How does this limited bandwidth affect the usability of a shared window system?
The results of these comparisons may apply beyond shared window systems for PalmOS or X
Windows, and perhaps beyond shared window systems in general.
Conclusion
By analyzing the technology costs of a new CSCW application and classifying it in a
“technology taxonomy,” we gain insight into the potential acceptance of the application. By
understanding how these technology costs can change over time we can see new avenues for
CSCW research and development. These changes can come about due to new approaches, new
hardware, or wider acceptance of existing hardware. An example of new hardware available in
recent years is the handheld computer, such as the Palm PDA. By applying the concepts of an
existing CSCW application, such as desktop shared windows, to these devices we find a new,
low-tech application area. The PShaW (Palmtop Shared Windows) project seeks to combine
these concepts into a new low-tech HCSCW application with a high chance of user acceptance.
Important aspects of this project include:
Application of shared window concepts to handheld computers.
Use of wireless networking capabilities for location-independent collaboration.
Use of control-level events instead of keystroke-level events for synchronous collaboration.
By comparing the experiences in developing this system to those in developing other shared
window systems, such as those based on X Windows, we may gain insights that apply more
generally to other shared window systems or to other applications.
Acknowledgements
This work was supported in part by NSF grant #IRI-9732577.
References
00-006 - 19 -
Abdel-Wahab91 Abdel-Wahab, H.M. and Feit, M.A., XTV: A Framework for Sharing X
Window Clients in Remote Synchronous Collaboration, Proceedings,
IEEE Conference on Communications Software: Communications for
Distributed Applications & Systems, Chapel Hill, NC, (April 1991).
Ayad98 Ayad, K., Day, M. and Foley, S., Pagers, Pilots and Prairie Dog: Recent
Work with Mobile Devices at Lotus Research. Workshop on Handheld
CSCW, ACM Conference on Computer Supported Cooperative Work,
November 14, 1998
Bergquist98 Bergquist, M., et al., Designing for Informal Mobile Collaboration,
Workshop on Handheld CSCW, ACM Conference on Computer Supported
Cooperative Work, November 14, 1998
Bluetooth99 For information on the emerging Bluetooth RF networking standard see
www.bluetooth.org
Garfinkel94 Garfinkle, D., et al., HP SharedX: A Tool for Real-Time Collaboration.
Hewlett-Packard Journal, April 1994, pp. 23-36.
Gellerson98 Gellerson, H. (Ed.), CSCW’98 Workshop on Handheld CSCW, Seattle,
USA, November 1998. (Also as http://www.teco.edu/hcscw/ )
Chung93 Chung, G., Jeffay, K., and Abdel-Wahab, H., Accommodating
Late-Comers in Shared Window Systems, IEEE Computer, Volume 26,
Number 1, (January 1993).
Greenberg98 Greenberg, S. and Boyle, M., Moving Between Personal Devices and
Public Displays. Workshop on Handheld CSCW, ACM Conference on
Computer Supported Cooperative Work, November 14, 1998
Holmquist98 Holmquist, L.E., Supporting Group Awareness with IPADs -
Inter-Personal Awareness Devices. Workshop on Handheld CSCW,
ACM Conference on Computer Supported Cooperative Work, November
14, 1998
Kirkley98 Kirkley, S., et al., WorldBoard: Supporting Collaboration with
Just-in-Place Information. Workshop on Handheld CSCW, ACM
Conference on Computer Supported Cooperative Work, November 14,
1998
Landay98 Landay, J., et al., NotePals: Sharing and Synchronizing Handwritten
Notes With Multimedia Documents. Workshop on Handheld CSCW,
ACM Conference on Computer Supported Cooperative Work, November
14, 1998
Lauwers90 Lauwers, J.C. and Lantz, K., Collaboration Awareness in Support of
Collaboration Transparency: Requirements for the Next Generation
of Shared Window Systems. In Proceedings, Conference on Human
Factors in Computer Systems, ACM (April, 1990)
McGee98 McGee, D. and Cohen, P., Exploring Handheld, Agent-based,
Multimodal Collaboration. Workshop on Handheld CSCW, ACM
Conference on Computer Supported Cooperative Work, November 14,
1998
Munch-Ellingsen98 Munch-Ellingsen, A., et al., Position Paper for CSCW’98 Workshop on
Handheld CSCW. Workshop on Handheld CSCW, ACM Conference on
Computer Supported Cooperative Work, November 14, 1998
00-006 - 20 -
Myers98 Myers, B., Collaboration Using Multiple PDAs Connected to a PC.
Workshop on Handheld CSCW, ACM Conference on Computer Supported
Cooperative Work, November 14, 1998
Schilit98 Schilit, B., Marshall, C. and Price, M., Collaborating Over Electronic
Books. Workshop on Handheld CSCW, ACM Conference on Computer
Supported Cooperative Work, November 14, 1998
Whitehead96 Whitehead, R., Technology as a Barrier to CSCW Acceptance, COMP
391-063 (“Collaboration Systems”), UNC, Spring 1996. (Unpublished)