SINGLE DISPLAY PRIVACYWARE:
AUGMENTING PUBLIC DISPLAYS WITH PRIVATE
INFORMATION
Garth B. D. Shoernaker
BSc.(Hons.), Queen's University, 1998
A THESIS SUBMITTED
IN
PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTEROF SCIENCE
in the School
of
Computing Science
@ Garth B. D. Shoemaker 2000
SIMON FRASER UNIVERSITY
November 2000
Al1 rights reserved. This work may not be
reproduced in whole or in part, by photocopy
or other means, withaut the permission of the author.
The author has granteci a nonexclusive licence d o w h g the
National Li'brary of Canada to
l
reproduce, loan, distri'bute or d
copies of this thesis in rnicroform,
paper or electronic formats.
L'auteur a accordé une licence non
exclusive pexmettant à la
Biôliottièque nationale du Canada de
reproduire, prêter, distribuer ou
vendre des copies de cette thèse sous
la fmme de microfichelfilm, de
reproduction sur papier ou sur format
électronique.
L'auteur conserve la propriété du
The author reîains ownership of the
copyright in this thesis. Neither the
droit d'auteur qui protège cette thèse.
thesis nor substantial exiracis h m it Ni la thèse ni des extraits substantiels
may be prhted or othezwise
de celle-ci ne doivent être imprimés
reproduced without the author's
ou autrement reproduits sans son
permission.
autorisation.
Abstract
The traditional human-computer interaction model limits collaboration by restricting physical compter access to one user at a t h e . Single Display Groupware (SDG) research
confronts the standard interaction model by examining how to best support groups of users
interacting with a shared display. One problem that arises with the use of SDG systems is
that they often do not adequately support the display of private information. Having the
ability to keep information private can be usefui for addressing issues such as the "screen
real-estate" problem, and problems associated with awareness overload. With normal SDG
systems, any information that is to be kept private by a user cannot be displayed on the
shared display, as that display is visible to al1 users. Some researchers have addresed the
privacy issue by developing techniques that allow mal1 private displays to be networked
with a large shared dispiay. This technique is useful for many applications, but has limitations. For example, private information cannot be shown within the context of related public
information, and users are required to constantly shift attention from the p h t e display to
the shared display. This dissertation introduces Single Display Privacyware (SDP),a new
interaction model that extends the SDG model to include the display of private information
on a shared display. Not only is public information shown on the shared display, but private
information is also shown on the display, and is kept private by filtering the output of the
diiplay. This interaction model can be used to address the screen real-estate problem and
the awarenm overload problem, and a h , unlike other solutions, allows private information
to be shown within the public context of the shared diiplay. A description of a prototype
implementation of an SDP system is given, along with resuIts of a user study performed
to investigate users interacting with the system. The significance of SDP and conclusions
regarding future research in the area are discussed.
For Amy JO Johnson, whithout whom there uiould be no Pink Ranger.
Contents
Approval
..
Abstract
...
Dedication
iv
11
111
List of Tables
viii
List of Figures
ix
1 Introduction
1
Leveraging Existing User Skills . . . . . . . . . . . . . . . . . . . . . . . . . .
Augmenting User Skills . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1
1.2
1.3 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Organization of the Dissertation . . . . . . . . . . . . . . . . . . . . . . . . .
Background Literature
2.1 Single Display Groupware . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Mouse Based PC Systems . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 PDA Based Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Augrnented Surfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Control Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Privacy and Awareness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Widgets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.3 Tradeoffs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
2
3
3
4
4
5
6
8
9
10
10
11
11
2.3 Privacy and Awareness in Single Display Groupware Systems
.........
12
3 Single Display Privacyware
13
3.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.1.1 Motivation for Single Display Groupware . . . . . . . . . . . . . . . . 13
3.1.2 Problems with Single Display Groupware . . . . . . . . . . . . . . . . 14
3.2 Concept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.3 Application Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . i8
3.3.1 Privacy on the Desktop . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3.2 Privacy on the Whiteboard . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.3 Control Rooms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.4 Competitive and Cooperative Gaming . . . . . . . . . . . . . . . . . . 23
3.3.5 A Fantastical Vision of the Future . . . . . . . . . . . . . . . . . . . . 25
4 Implementation
28
4.1 Hardware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.1.1 The Input Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.2 The Output Subsystem . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.2 Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Task and Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.3 Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.4
Data Input and Data Output . . . . . . . . . . . . . . . . . . . . . . . 38
5 Experiment
40
5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2 Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.1 Participants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.2.2 SampleSize . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.2.3 Software and Hardware Systems . . . . . . . . . . . . . . . . . . . . . 42
5.2.4 Expetimentai Task . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.2.5 Experimentai Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.2.6 Data Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
..................................
5.3.1 Preference
48
5.3.2 Collaborative Strategy
49
5.3.3 User Behaviour . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
...........................
5.4 Discussion
6 Conclusions
......................................
54
58
6.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.3 Final Thought . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
50
A G-LEGO Input and Output Files
A.l Sample Instruction Sequence Input File . . . . . . . . . . . . . . . . . . . . . 60
A.2 Sample Log Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
B Experiment Documents
62
8.1 Pre-Session Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
8.2 Pmt-Session Questionnaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.3 G-LEGO Tutorial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
8.4 Consent Form . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
8.5 Information Sheet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
B.6 Colour Blindness Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Bibliography
72
List of Tables
4.1 Description of data collected in Iog files.
5.1
.....................
39
Number of blocks added in each step for instruction sequence 1 and 2. for
both instructions set A and
B . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
5.2 Number of blocks added in each step for instruction sequence 3. for both
instruction set A and B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
5.3 Example experimental schedule. . . . . . . . . . . . . . . . . . . . . . . . . . . 48
List of Figures
. . . . . . . . 14
. . . . . . . 16
Input and output channels of Single Display Groupware systems
The "You are here" arrow is useless once removed from its context
Input and output channels of Single Display Privacyware systems. . . . . .
Private and public information available to participants in a meeting . . . .
.
.
.
18
20
22
24
Private and public information available to two operators of a control room .
Screenshot of football game with defensive player paths visible. . . . . . . . .
Screenshot of football game with offensive player paths visible. . . . . . . . . 25
Principle components of a CRT monitor. . . . . . . . . . . . . . . . . . . . . . 30
Configuration of the synch-doubling emitter and dongle. . . . . . . . . . . . .
Shuttering sequence of CrystalEyes glasses before customization . . . . . . . .
Shuttering sequence of CrystalEyes glasses after customization . . . . . . . . .
Circuit board in CrystalEyes wired glasses. . . . . . . . . . . . . . . . . . . .
Pin layout of feature connecter on synch-doubling emitter and CrystalEyes
31
32
33
34
wiredglasses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
Adapter cable used for attaching two pairs of wired CrystalEyes glasses to a
synch-doubling emitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Screenshot of G-LEGO prototype system. . . . . . . . . . . . . . . . . . . . . 37
Participant requirements for independent variables being controlled. . . . . . 41
Video capture of two participants in the experiment. . . . . . . . . . . . . . . 46
Layout of the experimental setting. . . . . . . . . . . . . . . . . . . . . . . . . 47
User experience with private and pubIic version. . . . . . . . . . . . . . . . . 49
User response to private instructions, private menus, and private cursors. . . 50
Percentage of tirne each pair spent looking at the sarne instruction sequence. 51
Chapter 1
Introduction
As computers have evolved from special purpose computation devices to more general purpose tools, their role in society has also evolved to reflect their capabilities. Desktop computers are now common in the workplace, schools, and homes. Computer applications exist
for word processing, music composition, mathematical computation, game playing, financial
analysis, Barbie dressup, and numerous other tasks. With computers solving many different problerns in many diferent domains, it has become apparent that traditional computer
interaction paradigms are mot suitable for the completion of al1 tasks. A financial analyst
may be most cornfortable sitting at a desk with a keyboard, mouse, and monitor, but this
setup may not be most suitable for a girl playing virtuai Barbie. This reality has prompted
investigation into the diflerent ways users can interact with computers, and the different
ways cornputen can fit into the lives of users. This work has already had an impact on the
cornputer marketplace, with the surge in popularity of Palm Pilot style devices, console gaming systems, integrated cellphone/organizer devices, %rnart appliances," tablet computing
devices, and other computing devices with novel interaction paradigms suitable to certain
specific tasks. This thesis will present a new interaction technique for computers that allows
them to support smail group collaboration around a shared display while providing access
to both private and public information.
1.1 Leveraging Existing User Skills
One trend in human-computer interaction research is to develop computer systems that
employ metaphors drawn from the physical world. This aiiows users to draw upon experience
from the physical world when interacting with computers. Methods of interaction in the
physical world, both between people in a group, and between people and objects, have been
refined throughout the evolution of humankind. People are very skilled at these types of
interactions. It is therefore desirable to enable people to employ these skills when interacting
with cornputer systems. Leveraging existing skills and skills of users can increase the ease
of use of a computer system, as well as the power of that computer system.
Research that deals with groups of users working on shared displays, Single Display
Groupware (SDG),
attempts to leverage existing human skills that are weli-practised and
effective because of every-day interactions in the physical world. The primary motivation
behind the use of shared displays is that people are skilled at working in the same physical
location and on the same physical artifacts. This is generally how collaborative work is
performed in the physical world. In this kind of situation collaborators can talk naturally
back and forth, enhance their verbal communication with gestures, and can include the
workspace in the discussion. Working at a distance from collaborators may decrease the
eficiency at which people work. Similarly, working in close proximity of collaborators, but
in different workspaces, can likewise decrease the eficiency at which people work.
1.2 Augmenting User Skills
Another trend in human-cornputer interaction research is to develop cornputer systems that
augment human skills by providing extra functionality. Computers have abilities that often
contrast strongly with human abilities, and can be used to provide functionality that would
not be available otherwise. Beyond leveraging existing human abilities, these abilities can
be augmented by additional and complementary abilities provided by the cornputer. For
exarnple, a portable cornputer could display the current time and position of the device
to the user. Tirne measurement and position measurement are two things that computer
systems can do rnuch more accurately than humans.
Research in the area of augmented reality, portable computing, and wearable computers,
is focussed on augmenting existing user skills. In augmented reality, the computer superimposes images on the physical surroundings of a user in order to provide information that
would not otherwise be available. Augmented reality does not have any direct parallel in
the-physical world; it does not leverage an existing human ability. It is stiU, however, a
potentially useful technique for providing usable and useful computer interfaces.
1.3 Contributions
This thesis takes an approach that combines the concepts of leveraging existing user skills
and augmenting user skills to produce a new interaction technique. The purpose of this
technique is to make possible a system that can leverage natural user abilities by ernploying
a shared display environment, while ptoviding extra functionality through augmentation of
that shared display.
The technique presented in this thesis, known as Single Display Privacyware (SDP),
involves the ability to display private information on a shared display. Users gathered
around a shared computer display normally al1 see the same content on the display. Our
technique "augments" the shared display, making it possible to display specific private
content to individual usen. The technique can be used in several ways. First, different
users can see entirely different content on the shared display. Second, "private areas" can
be designated on the display. Within these areas each user sees different content. Third,
public content and private content can arbitrarily be mixed on the display. This rnakes it
possible for private information to CO-existwithin the context of public information.
1.4
Organization of the Dissertation
This dissertation is organized into five main chapters: Background Literature, Single Display Privacyware, Implementation, Expriment, and Condusions. Chapter 2, Background
Literature, discusses research in the areaof SDG that holds relevance to the issues discussed
in this thesis. Chapter 3, Single Display Privacyware, provides adiscussion of the motivation
behind the creation of SDP as a concept, discusses problems that the interaction technique
addresses, and provides example application domains that could benefit from the use oCSDP
systems. Chapter 4, Im plernentation, describes the hardware and software corn ponents of a
prototype SDP system. Chapter 5, Experiment, discumes a study that was performed using
the prototype system with the goal of identifying advantages and disadvantages to using
the system, as well as possible future research directions. Finally, in Chapter 6, conclusions
are drawn regarding the significance of SDP as a new area of research.
Chapter 2
Background Literat ure
In this thesis we are interested in a broad range of issues related to supporting collaborative
compter-supported work. We are particularly interested in the use of different types of
technology to address interface issues in different environments, especially that of Singie
Display Groupware. As such, we will analyze research related to different technologies that
are used to support group interactions. More fundamental, perhaps, than the technologies
themselves, are the underlying issues that are targetted by the use of different technologies.
Research related to these issues, such as p h c y and awareness, will also be discuçsed.
2.1 Single Display Groupware
Research in the area of Single Display Groupware (SDG) examines how to best support
the interactions of multiple users with a shared computer display. While SDG applications
have existed for some time, the concept of SDG as a class of computer applications was
first introduced by Stewart [33], and later given a more formalized treatment, again by
Stewart [32]. While research in the area of SDG is a relatively new phenomenon, there has
been significant interest in recent years. Researchers have been investigating SDG systems
in different domains, such as education and business, and in relation to different categories of
tasks, such as construction tasks and problem solving tasks. Since the SDG mode1 does not
dictate interaction styles, this is also of interest to researchers. Different types of interaction
styles, such as mouse, PDA (Personal Digital Assistant), and tactile tabietop systems, are
al1 being examined. This section WUsummarize recent research in SDG, as categorized by
interaction style.
2.1.1 Mouse Based PC Systems
Mouse based PC systems, usually consisting of a mouse, a keyboard, and a monitor, are
the rnost widely used and recognized computer systems. Not only are users accustomed
to interactions with these systems, but software companies focus their development efforts
towards these systems. Mouse based PC systems are truly pervasive in our modern society,
and thus are important platforms for SDG applications.
Toolkits
The development of toolkits is often necessary to facilitate experimental investigations into
SDG and advance the state of technology. These toolkits are often required in order to
provide SDC functionality, such as supporting multiple simultaneous input devices, which
does not generally e s s t in commercial computer systems.
Perhaps the earliest example of such a toolkit is MMM, developed by Bier and Freeman [2]. MMM was a desktop application frarnework in which multiple users could edit text
documents and perform simple drawing tasks. Issues raised by the use of MMM inciude
that of screen real-estate, in which information widgets for different users interfere with one
another because of limited screen space. This issue has yet to be adequately addressed, and
rernains an important topic of research. Another contribution in this area is COLT [4, 51,
developed by Bricker. COLT introduces the concept of Cooperatively Controlled Objects
(CCOs), objects that can be simultaneously manipulated by multiple users. The COLT
system and the accompanying concept of CCOs provides both a methodology and an architecture for the design and irnplementation of SDG systems. Another toolkit of note is
MID [13], developed by Hourcade. MID is a low level toolkit for Java development that
provides software authors with the ability to searnlessly support any number of generic input
devices (mice, tablets, motion sensors) in a Java application. An early SDG system built
using the MID toolkit is discussed by Shoemaker and Inkpen [30].
Ali the tooikits mentioned in this section focus on supporting multiple input devices with
a shared display. Other types of toolkits are possible for SDG devetopment, but supporting
input from multiple users is perceived as a large problem by researchers, and therefoce has
been the center of focus for early SDG research.
Inter-User Interactions
In an SDG environment users are often forced to share resources. For example, there may be
only one mouse to use between two users, or users may be forced to share screen red-estate.
When this happens it is important to understand the interactions between the users, as well
as between each individual user and the system.
Inkpen has investigated users in a variety of collaborative conditions. One study [17]
examined pain of children playing puzzle games in three conditions: solo play, parallel
play (2 children on two computers), and integrated play (2 children on one computer).
This research revealed that children were sometimes more motivated and more successful
when playing together on a single computer. Further investigations by Inkpen focused
on children's learning when faced with different turn-taking protocols [16, 141. Additional
researcli in this area found that providing pairs of users with two independent mice, as
oppased to one mouse, significantly increased the level of user engagement [15]. it was
also found that forcing users to interact sequentially decreased the amount of inter-user
communication, and decreased the effectiveness of the childrens' interactions [28]. Results
such as these highlight the importance of understanding how new technology can impact
inter-user interactions.
2.1.2
PDA Based Systems
The idea of using Personal Digital Assistants (PDAs) for interacting with a shared display in
an SDG environment has become popular with researchers. The use of PDAs is immediately
attractive for several reasons. First of dl, PDAs are flexible devices. Custom software can
be written so that the PDA can periorm a wide variety of functions, frorn cursor control
to image manipulation. Second, like mice, PDAs are inherently personal. tt is uncornmon
for users to gather around a shared PDA. Thus, it is easy to imagine a scenario in which
several users each use a PDA to interact with a larger shared screen. In this scenario the
PDAs act simultaneously as interaction devices and display devices. This section discusses
investigations into systems of this type.
Pick-And-Drop
In the physical world, the physical movements and actions associateci with the completion
of tasks are visible to aii participants, and hence are easily and naturally understood by
group members. This does not necessarily hold when users are manipulating devices such
as mice and keyboards within a virtuaI environment. Mice and keyboards are not direct
manipulation devices. The results of actions performed by users manifest themselves in
locations removed from where the actions were performed, making it more difficult for
individual members to associate actions with corresponding group members.
Rekimoto has addresseci the problem caused by the use of remote manipulation devices
by developing a systern employing a novel pick-and-drop direct manipulation interaction
rnetaphor applied to a system comprised of persona1 PDAs and a shared whiteboard [26].
The development of the system was prompted by the realization that manipulation techniques suited to single-user systems do not necessarily translate well into a multi-user whiteboard environment. His "pick-and-drop" system lets users transfer information from a PDA
to a shared screen by simply "pLkingn the information by tapping it with a special stylus
and "dropping" it ont0 the shared screen with a similar tapping action. The "pick-and-dropn
metaphor closely models physical world interactions.
PDAs, SDG, and Privacy
A recent paper by Greenberg has brought focus to the role of private information in SDG
systems [8]. He points out that there is a need for users of an SDG systern to be able to
refer to and modify private information, hidden from view of the other group members. It
is also desirable to be able to transfer information from this private space to the shared
public display. This separation of private frorn public is something that is easily supported
by the use of private PDAs networked with a shared public screen. Greenberg provides
a discussion of a prototype system that was developed for use in a meeting environment.
While the results are preliminary, they serve to highlight a largely ignored facet of SDG
research, that of privacy.
Pebbles
Research by Myers has been important in raising awareness to the possibilities of using
PDAs in conjunction with shared displays. His Pebbles project is a large effort involving
the development of both toolkits for use by developers [23, 221, and applications for use by
end users [24, 211, The project has produced many pieces of software for PDAs enabling
groups of users to interact with PCs. Much of the software emulates functionality available
on the PC, making it available on a PDA. This project helps identifi the role that PDAs
can play in relation to shared screens.
2.1.3
Augrnented Surfaces
Tabletops and whiteboards afford group interactions over a shared workspace. It is very
natural for a group of people to gather around a table to analyze flowcharts, CAD designs,
or other information. Indeed, many meeting rooms are equipped with both a large table
around which to gather, and a whiteboard on which to present information. It is because of
this that the use of digital tables and whiteboards has become a large area of investigation.
One major strategy employed by researchers to "augmentn the functionality of a whiteboard or tabletop is to project computer generated images directly on the physical surface
of the device. The functionality of the device is "augmented" by projecting content shown
on the device. This section describes several different approaches researchers have taken
towards augmenting the abilities of tabletops and whiteboards.
InfoTable and InfoWall
Rekirnoto has contributed to SDG research by introducing his technique of augmenting
normal surfaces with digital content [27]. His augmented tabletop and wall projection systern
is built by virtually splicing together the displays of laptop computers that are placed on the
surface of a table, as well as the area provided by an adjacent wall. An overhead projector
projects images that till in the gaps between the laptop displays, and another projector
displays content on the wall. The result is a physically seamless and continuous workspace
over which windows, files, and cursors can be dragged. When a new user arrives and places
a laptop on the desk, the laptop is added to the surface of the augmented desktop. This
technique makes it simple for groups of computer users to network their laptops in an
intuitive manner. The physical surfaces of the desk and wall serve the same role in the
virtual world as in the physical world, providing users with a medium in which information
can be shared.
Urp: Urban Planning
Another groupware system that employs augmented surfaces, and also involves tangible
media is Ucp, developed by Urtderkoffler [35]. Urp is an example of a system that narrows
the gap between the virtual and the physical. The system provides urban planners with a
medium in which they can test the environmentai effects oldifferent building layouts. The
system is baseci on tangible media, all the tools used are physical objets which are placed
or turned to yield desired results, just as in the physical world. Picking up and moving
structures produce red-time changes in a simulation of airûow, as weU as the position of
shadows and reflections. A camera monitoes the positions of the buildings and tools and a
computer calculates the changes in airflow and lighting. The effects are visualized through
images projected on the tabletop by a projector. With this tool urban planners can easily
experiment with different building arrangements. This is another example of a system that
uses augmentation of physical surfaces to provide a powerful computing systern suitable for
groups of users.
Whiteboards: ClearBoard, Tivoli, and DOLPHIN
Whiteboards can function similarly to tablotops, in that they are large workspaces that
invite interactions by groups of workers. The only diference is that, with a vertical rather
than horizontal mounting, whiteboards provide a different kind of access to users. lt is
more difficult for a group of users to gather around a whiteboard, but the surface is more
visible to users Far away, and orientation of information is consistent for different users. Early
whiteboard relateci work inclrides the ClearBoard research of ishii (181, and the developrnent
of the Tivoli system, discussed by Pederson [25]. More recent work that focuses specifically
on whiteboards as groupware systems is that of Mark [19, 201, who has analyzed group
interactions around the DOLPHIN whiteboard system.
2.1.4
Control Roams
Control rooms are an example of a present-day work environment that involve major use
of SDG computer systems. These rooms, which often serve such things as electrical grids
and industrial plants, are run by groups of worken who must pnicess huge arnounts of
data being sent from different parts of the system being analyzed. Typically, the labour is
divided among worken in order to accomodate the large amounts of data. Workers must
stiU coordinate their work, however, and tKs is whece a Large shared screen disptaying an
overview of the system is useful. Whiie the worken require an overview of the system,
detded information is dso needed for individual workers performing specific tasks. This
information is often different for different workers, making it undesirable for the information
to be shown on the shared screen. In many systems, private monitors are used to show
detailed information to specific workers. A discussion of such a system is provided by
Tani[34]. Among other things, Tani discusses the need to provide continuity between the
private space of the small displays and the shared space of the large screen.
2.2
Privacy and Awareness
One issue that is prevalent in the area of distributed groupware and is also relevant to SDG
research is the question of awareness. Awareneçs, the understanding of what other users
are doing, is important in distributed groupware because remotely located users have no
direct contact with each other. Users must be able to deduce the actions and intentions of
others through awareness widgets displayed on the screen, or through other media such as
audio or haptic feedback. Awareness is also an issue in the design of SDG systems, although
the problems are somewhat different. In the case of SDG, every user is provided with an
abundance of information concerning other users' actions, however, this information can
easily become overwhelming and confusing to a user. This problem can be addressed by
limiting the awareness information available to any particular user. The awareness problerns
faced in SDG systems and distributed systems are different but related, and research in one
area can easily be relevant to the other. This section will focus on research on privacy and
awareness in distributed groupware that is relevant to SDG research.
2.2.1
Widgets
Distributed groupware awareness research has focused significant attention towards how to
best display awareness information to users. Much of this research deals with "awareness
widgets," the name for onscreen components that convey awareness information. A goad
discussion of awareness widgets is offered by Gutwin and Greenberg [IO], and Gutwin and
Roseman[ll]. Among the specific awareness widgets discussed in the papen are telepointers,
which indicate mouse positions of remote users, and rnulti-user scrollbars, which indicate
scroiling position of remote users. Also diiussed are a variety of different workspace views,
which help users understand what part of the workspace remote users are working in.
Other widget research that has been pecionned for single user systems can also have
relevance for multi-user systems. Research on transparent tools, by Bier [3], Cox [6], and
Harrison [12], all deal with transparency and how it can be used in conjunction with tools
and display layen. The use of transparency can have a deep impact on user awareness.
Other widget research to consider is that of Bedemn [l]. He investigated the concept of
local tools, tools that can be picked up off the workspace, used directly, and then dropped
again on the workspace. These tools might have a role in increasing user awareness and
limiting screen clutter.
2.2.2
Mechanisms
In order for awareness information to be distributed among a group of users some mechanism
of transport must be employed. As discussed by Dourish and Belloti [7],these mechanisms
can fa11 under a number of broad categories. First, an &informativenmechanism requires that
users actively transmit awareness information to other users. Second, a "role restrictive"
mechanism requires that individual usen be categorized in some manner, and that specific
awareness information be broadcast to users according to their categorization. Dourish and
Belloti argue that neither of these mechanisms is ideal. They argue that a third mechanisms, the "shared feedbackn mechanism, is superior. "Shared feedbackn mechanisms cause
awareness information to be collecteci passively from the environment. This information is
then displayed to al1 users as part of the workspace.
2.2.3
Tradeoffs
There are often tradeoffs to be made when deciding on how much awareness information
is to be made available in a groupware application. Gutwin discusses these tradeoffs [IO],
as well as other issues associated with awareness in groupware systems [9, 111. He argues
that as more awareness information is made available, the power of individual users must
decrease to accomodate. In essence, the power of individual users must be sacrificed for
increased group awareness, or vice versa. An example tradeoff given in the paper concerns
workspace navigation, whether individual users are able to Freely explore the workspace,
independent of ot her users. Allowing this activity favours individual user control, while
forcing usen to work in the same space favours group awarenesç.
2.3 Privacy and Awareness in Single Display Groupware Sys-
tems
Limited research has been conducted concerning the role of privacy and awareness in SDG
systems. As evidenced by Section 2.1, most SDG research has involved the development of
new technologies, and the investigations into the implications of t hose technologies. Analyses
into the requirements for successful SDG systems have largely been neglected. Nevertheless,
several SDG research efforts have tangentially dealt with privacy issues.
Rekimoto's pick-and-drop implementation, already described in Section 2.1.2, is probably the m a t intriguing SDG system supporting privacy. While intended to support intuitive
physical manipulation of data by usen, a side effect of the implementation is that information moves naturally from private spaces to a shared public space. Users carry private
PDAs that hold their private information, while the shared display holds public information. While this sepatation of public and private spaces can be valuable, it can also pose
problems. It makes it impossible, for example, for private information to be shown in the
context of public information. Showing private information in a public context can be useful
if observing the two pieces of information in proximity results in a deeper understanding of
t heir relationship.
Other systems, both similar to that of Rekimoto's, are those of Myers [24 and Greenberg [8]. Both support different degrees of privacy by displaying information on a PDA,
Greenberg's system is specifically designed for privacy support, and aliows for a clear distinction between private and public. Information can be transferred between public and
private and can be displayed on the shared screen or private PDAs. Myers' system is somewhat l e s targeted to the support of privacy. It allows multiple users to perform simple
control operations such as scrolling and link browsing on their private PDAs, while actions
are carried out on the shared display.
The research presented in this dissertation addresses the problem of supporting private
information on a shared display, while overcoming some of the problems that are inherent
in solutions pmposed by other researchers. The approach of this research, that of displaying
private information within the public context of the shared display, has been briefly diicussed
in a previous paper [29], with a more in-depth discussion provided by [31].
Chapter 3
Single Display Privacyware
3.1 Motivation
The motivation for the creation of Single Display Privacyware (SDP) as a research area is
drawn directly from the motivation for Single Display Groupware (SDG) as a research area,
and the problems associated with SDG systems. As such, this section will first discuss the
motivation behind SDG, and will then discuss the problems with SDG that can be addressed
by SDP systems.
3.1.1 Motivation for Single Display Groupware
SDG encompasses computer systems that are meant to support groups of users collaborating
on a single computer display. As defined and later refined by Stewart [32, 331, SDG requires
a shared user interface and provides shared feedback to users. It also couples navigation
between users. The result of this definition is that SDG provides users with private input
channels and a shared public output channel (see Figure 3.1).
The motivation behind SDG research and development is that such systems provide a
richer and more natural environment in which to work, as compared to remote collaborative systems. Due to their proximity, -users are able to interact with each other using
verbal discussion and gestures. Users are also helped by the use of a shared artifact (the
shared screen). When peopke work collaborativeiy in the physical world, shared artifacts
are frequently used. Skiils that have ben developed in the physical world can more easiLy
be translated to work in the digital realm if shared artifacts are used there as weU, instead
-lot
Monitor
private input
user 2
8
8
m
public output
user n
Figure 3.1: Input and output channels of Single Display Groupware systems.
of duplicata of an artifact (different screens). These skills can include the ability to d e
velop a shared understanding of the task by the users, and the ability to coordinate actions
performed by the users, While definitive proof of the advantages of using $DG systems is
lacking, the proliferation of such systems in certain domains is an indication that they can
be useful.
3.1,2 Problems with Single Display Groupware
The Screen Real-Estate Problem
The screen real-estate problem is a serious problem that emerged early in the history of
SDG research. It concerns the use of limited display area that must be shared by several
users. Users of any computer system make use of a variety of on-screen input widgets to
perform actions. Feedback widgets provide users information specifying the outcornes of
those actions. In the case of groupware systems, awareness widgets inform users regarding
the actions of other users in the system. When multiple users work on a shared display,
all of their widgets must be shown on that one display. In many cases, the widgets require
more space than the display has to offer.
Several methods of combatting the screen real-estate problem can be employed. A
simple strategy is to either shrink widgets or to reduce the number of them that are shown.
Shrhking widgets has the desired effect of freeing up space, but can result in widgets
that are diîücult to see. Eliminating unnecessary widgets can also work, but it is not
always passible to remove widgets without compromising functionality of the system. A
more complex method of combatting the screen real-estate problem is to have users share
widgets. For example, users working in a paint application could al! use the same toolbar.
This method can be very succeçsful in reducing the amount of required display space, but
has problems of its own, primarily that sharing widgets, especially feedback widgets, can
cause a lot of confusion for usen. With different usen selecting different tools on a toolbar,
or simultaneously selecting different items from a menu, the different paths of users c m
cross, and the users may be confused as to what operations are being performed by whom.
The Awareness Overload Problem
The awareness overload problem in SDG is closely related to the screen real-estate problem.
The awareness overload problem exists because of the fact that as more information is
shown on the display it becornes more difficult for users to process the information and
determine what information is relevant. Each user has personal feedback widgets that
provide information concerning that user's actions. As they are visible to everyone, these
widgets also provide awareness information to the other users. SDG systems by default
have a large amount of awareness information that can be overwhelming to users. This is
in contrat to distributed groupware systems, wiaere awareness information is by dehult
scarce, and must be provided explicitly.
Existing privacy techniques are abIe to combat the problem of awareness overload. Sev-
eral SDP systems exist [8, 24, 261, mostly employing private networked P D h , that use
remote private diiplays to show some feedback information to users. Information that is
not desired as awareness information for the group can be shown on a private display so that
it does not Up~lluten
the shared display. There is, of course, a judgement that must be made
as to what information is useful as awareness information, and what information should be
kept private. While the use of PDAs serves its purpose, it rnakes it necessary for users to
coordinate several displays, possibly creating significant cognitive overhead. It ais0 makes
it necessary for each user to posseçs a suitable PDA, and for these PDAs to be networked
with the shared diipIay. An alternative to the PDA approach to privacy wouid be for al1
information, whether meant for group awareness or personal feedback, to be displayed on
the shared display.
The Privcicy in Context Problem
The value of information is often heightened if that information is shown within its context.
For example, a map of Alberta can be more valuable if it is shown with maps of surrounding
Provinces and Territories. Information can even be rendered useless if removed frorn its
context. A "you are here" arrow is useless if there is no context provided (see Figure 3.2).
nie Context
..
.
'*,
nie information
removed from its context
.
Figure 3.2: The "You are here" arrow is useless once rernoved frorn its context.
Existing SDG systems, even those with privacy support, are unable to show private information within a public context, as the context provided is on the shared display. Showing
private information in'its context would render that information public, while displaying
the information on a private device removes it from its context. There are many examples
of information that a user rnight want to view in a public context while keeping that information private. Cursors, for example, might be kept private to ceduce screen clutter, but
must exist within a public context or be rendered useles. Information used by workers in
industrial control rooms is often specific to each worker, but can be more rneaningful when
shown within the context of the general status of the system. Essentially, any inter-related
pieces of information, for example of a spatial or geographic nature, that users might access
independently from one another could benefit from being displayed privately within a public
context. if certain pieces are public while others are private, a display technique capable of
showing private information within a public context wouId be valuable.
3.2 Concept
Single Display Privacyware is a class of collaborative cornputer systems that extends directly
from SDG, and is meant to address demonstrated problems with SDG. An SDP system is
defined as being an SDG system that provides each user with a private output channel on
the shared display, in addition to the public output channel shared by al1 users. The private
and public channels employ the sarne physical area on the display; any point on the display
can be either public or private at any time. This makes it possible for private information
appropriate for each user to remain private while being shown in the context of the public
display.
While traditional SDG systems provide private input channels for each user and one
shared output channel for al1 users (see Figure 3.1), SDP adds additional private output
channels for each user (see Figure 3.3). This results in additional flexibility being added to
the SDG model. Most significantly, users need not share feedback. While al1 users of SDG
systems share feedback via the shared output channel, the private output channels of SDP
systems can override the shared output channels. in simpler terms, the private output can
cover up sections of the public output, replacing it with information tailored to a specific
user. A result of this, which also lomens the SDG definition, is that users of SDP systems
are not restcicted to coupied navigation. The private output channels make it possible for
individual users to navigate independently of one another. This would only happen, of
course, if the navigation for al1 users was made private. Keeping navigation public would
force coupled navigation, which would preserve some hypothesized benefits of SDG systerns.
The SDP label does not imply any particuIar implementation of private and public
channels. The only requirement in terrns of hardware is that users have some means of
private input, and that there be a display that is capable of showing an arbitrary mix of
public information targeted to the group and private information targeted to specific users.
The means of achieving privacy is not specified. Systems might employ technologies such
as shutter glasses, polarization filten, head-mounted displays, or any other system that
achieves the same effect.
Monitor
user n
Figure 3.3: Input and output channels of Single Display Privacyware systems.
3.3
Application Scenarios
One way of highlighting the benefits of SDP systems is to give exarnples of possible applications. This section gives possible scenarios and explanations of how SDP plays a role in
those scenarios.
3.3.1
Privacy on the Desktop
One of the areas in which the implementation and adoption of SDP could have the deepest
impact is that of desktop applications. Desktop PCs are pervasive in modern households
and businesses, and any benefits that might be achieved by adopting SDP systerns would
most readiiy be reaped in these environments. Desktop applications are also of considerable
interest because as a class they encompasses most of the systems that have been investigated
by SDG researchers. Privacy issues, such as screen reai-estate and awareness overload, that
have been identified by this body of research, can therefore be directly addresseci by SDP.
Scenario 1: Garth is an apprentice computer animator at a large animation
firm. He is seated at his desk, struggling with getting the walk of a virtual bug
to be just right. Getting frustrated, he cails over to his supervisor, "Iliana, can
you help me with this bug? 1 can't get him to waik rightSn iiiana cornes over
and sits down beside Garth. With two users at the cornputer, the monitor now
displays two difFerent images to the two artists. Both Garth and Iliana see the
wireframe of the bug, but privately they each see their own toolbar setup. Iliana
glances at the display. 'You have to set the keyframes at the right spots. Here,
1'11 show you." Accustorned to her own personal toolbar setup, Iliana easily gets
into the right mode, tweaking joints in individual keyframes of the animation.
Garth follows along, seeing the changes reflected both in the public image of
the bug, and in his private animation timeline and feedback widgets. Iliana
finishes her changes, and Garth then continues along, making more changes to
the animation. Iliana comments on Garth's changes, and works aiongside him,
guiding his actions. Finally she is satisified with his approach, commenting Tes,
that's it. You're putting the keyframes at the right spots now." Iliana leaves,
and Garth continues with his work.
This scenario depicts a normal type of interaction that might occur at any workplace.
Different users of computer systems have different skills, and they often share these skills
to help each other complete tasks. What is unique about this scenario, however, is that the
display the users work on is augmented with private information for each user. The specific
scenario given involves artists at an animation studio. The private aspect of their computer
system allows them to access their own private toolbar setups. Informal discussions with
artists at Electronic Arts revealed that rnany of them custornize the interfaces of their art
packages, and become very efficient at operating those custornized interfaces. Being forced to
adapt to someone elses interface might slow a user down, or discourage them from getting
involved in the first place. This benefit of having privacy support is in addition to the
benefits that might be gained by reducing screen clutter and removing unwanted awareness
information.
3.3.2
Privacy on the Whiteboard
Digitai whiteboards are of growing interest to SDG researchers, mostly because they naturaliy support group interactions. Digital whiteboards are also of interest because their
non-digital counterparts are dready widely used in meeting rooms and schools. This scenario describes a potentiai application for SDP that involves a whiteboard being used in a
business meeting much as it would be if it were a simple "ink and surfacen whiteboard, with
added functionality provided by the digital nature and pnvacy support.
Scenario 2: Garth is an upcoming talent at a big architectural firm, and is
making a presentation to some clients and partners in the firm (see Figure 3.4).
They gather in the meeting room, where everyone sits down around the large
meeting table. Garth goes to the front of the room and activates the large
electronic whiteboard. He pulls up the latest draft of the office tower being
designed for the clients. As he talks, he uses his stylus to highlight and point
out different features of the designs. One of the clients is puzzled, he can't
remember what one portion of the plans looked like before. Not wanting to
disrupt the meeting, he pulls up the previous version of the plans and displays
them privately on the whiteboard. He superimposes the old plans with the new
ones, and observes the changes that have been made. Meanwhile, another client
remembers an idea he had concerning the office tower. He pulls up his notebook
privately on the display and Aip through it until he Ends the right page. He
then grabs the page contents and makes them public. The clients and Garth
discuss the idea, make annotations, and make changes to the plans.
Figure 3.4: Private and public information available to participants in a meeting.
This scenario depicts a system that combats many of the problems found in SDG systems.
First, one client is able to access contextually sensitive information (the old plans) and
superimpose them on the new plans. Not only is he able to do this without bothering other
meeting members, but he is able to look at the private information in the context of the
information currently being discussed on the shared display. Second, another client is able
to browse his personal notebook, looking for the notes relevant to the discussion. He is able
to do thii without bothering othet participants, making his notes public only when he has
found the appropriate information. Not only is he avoiding diitracting others, but he is
keeping private other information in the book that he may not want them to see. Further,
when the meeting participants arrive at the annotation and editing stage of the meeting,
the tools necessary for doing the annotations and editing are kept private to each user. This
reduces the number of widgets on the screen, as well as the amount of awareness feedback
being shown to each user. The result is a better ability to manage screen real-estate and
a possible reduction in cognitive overhead for each participant. All these examples can be
supported in an
SDP system, but could not be easily supported by other SDG systems.
3.3.3 Control Rooms
One very important application for which
SDG is currently used is that of control room
operation. While operators of control moms often share a large screen showing overall
information of the system being controlled, detailed information or information relevant to
a particular worker is usually shown on a private display. This scenario gives an example of
how SDP could be used to move some of that information from the personal display to the
shared display.
Scenario 3: Garth and Homer are two technicians at a nuclear power plant (see
Figure 3.5). They sit at desks in a large room, at the front of which is a large
display with a diagram OF the power plant. The display h a s lights showing system
status for different components of the plant. As Garth and Homer lounge at their
desks, one of the lights on the àisplay starts flashing red and a buzzer sounds.
Roused out of their reveries, Garth and Homer examine the large board and
locate the red light, Garth, with his privacy glasses on sees much more than just
the red Light. He sees water flow idormation from node to node on the display.
From thii he îs able to teii that the water fiow to the problem point is normaI.
"Water flow is normal Homer, problem must be yours." Homer, with his privacy
glasses, sees similar flow information, only for him it is heat flow information.
From the information on the display, he is able to determine that the heat flow
from the problem node to a neighbouring node is abnormal. At this point he
accesses the private display at his desk to examine more detailed information
on the two nodes affected by the problem. Armed with this information, he
performs the operations necessary to avoid a disaster.
Figure 3.5: Private and public information available to two operators of a control room.
This scenario depicts a hybrid system that can show information both on the shared
display and on a private display. In a control room situation, it is often necessary for workers
to react very quickly to changes in status shown on the shared display. It is desirable for
information to be displayed in such a way that it is easy to comprehend for the workers. In
the scenario described, some private information was shown on the shared board. Because
the information was shown in its context, heat and water flow values adjacent to their
corresponding nodes, the two workers may have undentood the situation more quickly than
if d the private information was shown on private displays. The extra step of correlating
information on the shared display with information on the private display was skipped.
At a certain point, however, the worken switched from the shared diiplay to their private
displays. This might happen if it becomes necessary to perform additionai tasks, such as
cornputations or information retrieval, that might not benefit from being shown on the
shared screen.
3.3.4
Cornpetitive and Cooperative Gaming
In recent yean, computer gaming has grown immensely in popularity all over the world.
Multiplayer garning is one aspect of garnes, in particular, that has been focussed on recently
by the industry. Multiplayer gaming on the internet, over LANs, and on console systems
are all extremely popular. This çcenario considers a possible SDP system in use in a console
gaming environment.
Scenario 4: Garth and Saddam are two feisty teenagers with a serious cornputer
gaming rivalry. One afternoon, Saddarn arrives at Garth's house, they plug their
console gamesystem into the TV, put on their headsets, and insert their favourite
Arnerican football game cactridge. The game boots up, and they are shown the
play selection screen. Garth, on defence, is faced with a private screen showing
an array of defensive play choices that only he can see. He chooses the 4-3
safety blitz, knowing that Saddarn will not preàict the aggressive and sneaky
play. Saddam, shown a private set or offensive play choices, chooses a simple
passing play. Both Garth and Saddam see a puMic view of the playing fieid
with the playen ready and lined up. Saddam sees the public view augrnented
with private arrows indicating the routes his receivers will run (see Figure 3.7).
He looks over the paths, and readies for play to begin. Garth sees the same
public players laid out on the field, but his private information shows the the
paths his defensive players will take (see Figure 3.6). Arnong these, he sees the
aggressive and risky path his safety will take, directly for Saddam's quarterback.
Play begins, and Saddam uses his controller to guide his quarterback back for
the p a s . Garth instructs his safety to blast through Saddam's defensive Iine,
leap through the air, and tackle Saddam's quarterback. Gart h jumps in the air
screaming, taunting Saddam in hii glorious moment of victory.
This scenario depicts two players in a very popular gaming environment, multiple players
playing on a gaming consoIe on a shared diiplay. Present day console systerns are typicai
SDG systems. They display aU information publicly to ali players. This can have an
adverse affect on gamepIay if there is any dernent of subterfuge intended in the gameplay.
Figure 3.6: Screenshot of football game with defensive player paths visible.
phase, the two players in the scenario rnnst perform two different operations. One picks a
defensive play, the other picb an offensive play. These picks are private, and knowledge of
an opponent's pick would have a large eiێct on sttategy. The SDP system in the scenario
makes the play seleetion phase of the game twly private. Second, in the actual play portion
of the scenario, relevant private information is visible to each player in the context of the
public game ztion. in thia scenario, each player sees the plan that wiil be carried out by
their team, and both playea share a view of the dtama being acted out in the game.
3.3.5
A Eàntastical Vision of the Future
The scenarios presented previously describe SDP applications that could be implemented
relatively easily using today's technology. Et can also be useful, however, to consider more
fancihl scenarios that might be implemented in the future when more advanced technologies
and acwmpanying infrastructure are avaiiable.
Figure 3.7: Screenshot of football game with offensive playet paths visible.
Sesriario 6: This scenario aisa involves Garth, who is now a weary business
travder on hii way from Vancouver to a meeting in Boston. He arrives at
Vancouver International Airport and enters the terminal buMing. Upon entering
the building the first thing.he %ces ia the large display with ûight information.
In large letters, filling the entire screen, it says "HeUo Garth. Yonr Pight leaves
in 20 minutes from gate 23A. In the meantime, they have chocolate cucumber
muffins at the coffee shop to yout M."Garth is now up to date on his light
information, and is on track to getting hi favourite snack, chocohte cucumber
mdins. He sees to hk left a CO& shop. The sign indeed says "yes we have
chamlate cncumber muffins." Aftet enjoyûig his snack he buards the plane.
During the flight, the 2 metes HDTV mwie screea descencls fmm the ceiüng
at the front of the cabin and starts showing YSleepleas in Seattle." Fighting a
gag tesponse, Garth puahes a button on bis console and the movie switehes to
muffins. He sees to his left a coffee shop. The sign indeed says "yes we have
chocolate cucumber muffins." After enjoying his snack he boards the plane.
During the flight, the 2 meter HDTV movie screen descends from the ceiling
at the front of the cabin and starts showing "Sleepless in Seattle." Fighting a
gag response, Garth pushes a button on his console and the movie switches to
"Army of Darkness." After his relaxing fiight Garth steps down from the plane
and heads to the rental Company. Upon arriving in the parking lot a series of
projected arrows direct Garth to his car. He drives off and arrives at hjs meeting
safely.
This scenario described several futuristic SDP applications that hnction seamlessly
within our intrepid adventurer's daily life. The display screens in the airport are able to
determine that Garth is in proximity, and display private information specific for him. The
system knows his Bight information and his eating tastes (presumably from previous visits
to the airport), and direct him accordingly. Of course an airport is often very busy, and the
sarne displays must simultaneously show very different information for different observers.
On the plane, SDP makes another appearance with the in flight movie. The SDP nature of
the movie screen makes it possible for Garth to opt out of having to endure "Sleepless in
Seattle," instead he enjoys a film more suited to his tastes. Other passengers, of course, are
able to watch their own favourite movies at the same time, on the same display. Finally,
another SDP system makes it possible for Garth to find his rental car quickly, quite possibly
while other customers of the rental agency are being directed to their own cars, in different
locations,
What makes the examples in the scenario so interesting is that they highlight the us+
fulness of making private information contextually available in every aspect of our public
world. While ail the information in the scenario could be made available on a PDA, it
would not have the same impact, and would not be as useful. The arrows in the rental
agency related directly to the geography of the parking lot. The information about the
chocolate cucumber mufin also contained irnplicit information detailing where the muffin
could be obtained. Finally, the movie was certainly more satisfying being displayed on a
2 meter HDTV screen, as opposed to a PDA. Another advantage gained through the use
of SDP systems was that information not relevant to Garth was hidden to him. Information concerning the 99.99% of the tlights Garth had no interest in were hidden to him, and
uninteresting specials at the
CO&
shop were not advertised to him. A large amount of
the "cognitive garbage" normally associateci with everyday Ne was filtered €rom view. The
definition of what constitutes "cognitive garbagen would, of course, need to be deterrnined
somehow, which raises questions OP how much control a person has over what is visibie and
what is hidden.
While thii scenario possibly demonstrates the ultimate convergence of SDP with everyday Bfe, certainly faces many technicai olastacles. The problem of providing privacy for
an arbitrary nurnber of viewers on arbitrary displays in the natural surroundings is huge,
Displays capable of huge refresh rates, displays capable of directional beaming of light, occular implants, and universal person tracking are ail technologies that might play a role in a
solution. While such technologies are currently technologically infeasible as well as ethicaily
questionable, it is possible that solutions to these problerns will be arrived a t in the future.
Chapter 4
Implementation
A prototype systern, dubbed G-LEGO, was developed to demonstrate privacy on a shared
display. The system supports two users who work cooperatively to build LEGO-like structures in a virtual environment. The hardware for the system includes a standard Windows
98 based cornputer with monitor, two USB mice, and other customized hardware used to
provide privacy. The software for the system consists of an application that interfaces with
the necwsary hardware and produces visual feedback on the display to the users. The
following sections describe the details of the hardware and software implementations.
4.1 Hardware
The hardware components of the GLEGO system can be split into two subsystems, the
input subsystem, and the output suhsystem. The input subsystem consists of2 USB mice, a
USB hub, and a USB input on the cornputer. These are off t he shelf components. The output
subsystem consists of a standard monitor (1280x1024 @1 75Hz), a StereoGraphics synchdoubling emitter, two pairs of Stereographics wired CrystalEyes glasses, and an adapter to
connect the two pairs of gIasses to the synch-doubling emitter. Both pairs of CrystalEyes
glasses and the adapter were customized for use with GLEGO. Ali customization was
performed by the author as a part of this thesis, with electrical engineering advice provided
by Colin Swindells.
4.11 The Input Subsystern
The input subsystem of G-LEGO provides each of two users with a mouse to interact with
the computer. As with most Single Disptay Groupware, G-LEGO makes it possible for
both users to interact simultaneously and independently with the system. The USB bus
coliects position displacement information from both rnice and passes it to the operating
system. The operating system typically coalesces these Deltas and sets the position of the
hardware cursor (the cursor provided by the operating system). G-LEGO does not use
the hardware cursor, and instead polls the Delta information for each mouse directly from
the operating system, through the DirectX/DirectInput API, and uses it to keep track of
position information for each mouse. GLEGO deactivates and hides the hardware cursor,
and draws two software cucsors on the screen. The positions of these cursors correspond to
the positions calculated from the Delta information.
The method of interfacing with the hardware used to track multiple independent USB
rnice only works with particular configurations of system software. Microsoft Windows 98
is required, and DirectX 7.0a is suggested, although other versions of DirectX may work.
4.1.2
The Output Subsystem
The Monitor
In order to analyze the functioning of the output subsystem, an understanding of CRT
monitors is required. This section is a simple sumrnary of CRT mechanics. The internals
of a CRT (cathode ray tube) monitor include an electron "gunn and a surface coated with
phosphor. The gun is at the back of the CRT, and the phosphor surface is at the front,
visible to the user (Figure 4.1). The gun accelerateç electrons which are targeted at specific
positions in the phosphor. Each position in the phosphor is one pixel on the monitor. The
electron hitting the phosphor causes it to become excited, emitting light visible to the user.
The gun scans across the surface of the phosphor in horizontal scan lines, shooting electrons
at each pixel in the phosphor. When the gun has hit every pixel in every scan Iine, it returns
to the first pixel in the first scan line and starts dl over. Each of these scans of the monitor
surface is one "screen refresh."
Each screen refresh of the monitor can be considered to be one '%amen in an animation.
Between screen refreshes the contents of the video memory can change. What is drawn in
each successive screen refresh is often different from the previous screen refresh. Given the
Figure 4.1: Principle components of a CRT monitor.
high speed of the screen refresh, however, the user perceives the output as being a smooth
animation. The concept of "screen refreshn and "€ramen described in this section is key in
the functioning of the G-LEGO hardware.
The Synch-Doubling Emitter and Dongle
The synch-doubling ernitter and accompanying dongle serve to regulate the operation of
the rnonitor as well as the CrystalEyes glases. The dongle attaches in series between the
rnonitor's input cable and the video card of the computer, while the synch-doubling emitter
sits on top of the monitor and is attached to the dongle {Figure 4.2).
When activateci, the synch-doubling emitter uses thedongle to access and alter the signal
travelling to the monitor from the video card. The signal is altered so that the refresh of the
monitor is twice what it would normally be (Born 75Hz to 150Hz for our prototype). This
results in several changes to the video output. First, the vertical resolution of the display is
halved. While the dongle has caused the refresh rate to double, the rate at which lines are
scanned by the monitor remains constant, thus halving the vertical resolution. Second, the
image shown on the display is "stretched" vertically by a factor of two. The result of these
effects is that alternate refresh fiames show either the top or bottom hnlf of the original
display image. Every odd-numbered screen refresh shows a stretched version of the top half
Figure 4.2: Configuration of the synch-doubling emitter and dongle.
of the display image, while every even screen refresh shows a stretched version of the bottom
haif of the display image.
The CrystalEyes Glasses
Two pairs of CrystaiEyes glasses are used in conjunction with the synch-doubling emitter.
Each pair of CrystaiEyes has liquid crystal lenses that can alternate between opaque and
transparent states at a very high frequency. When provided with a timing pulse through
the wired inputs, the glasses synchronize the state change of the lenses with the pulse.
The timing pulse, which matches the refresh rate of the monitor, is provided by the synchdoubling emitter.
CrystalEyes glasses are not normaily used for displaying private information to two users.
The normal operation of the CrystalEyes glasses provides a stereographic view of an image,
typically for a single user. The glasses shutter such that at any moment in time one Iens
is opaque and the other is transparent (see Figure 4.3). Any one refresh frame is viewed
by either the Ieft eye or right eye of a user. Consequently, each eye wilL see either every
odd numbered refresh frame, or every even numbered refresh frame. tf the d'iplay image is
drawn such that even and odd numbered refresh frames show a slightly different perspective
of the same scene, adjusted appropriately for each eye, the user will perceive a stereo image
of that scene.
Frame #
Figure 4.3: Shuttering sequence of CrystalEyes glasses before custornization.
The G-LEGO prototype rnakes use of the shuttering capability of the CrystalEyes, but
aiters the shuttering operation in order to provide privacy for multiple users, rather than
stereographic viewing for one user. Firçt, two pairs of CrystalEyes were attacheri to the
synch-doubling emitter, so that each of them receives the appropriate timing signal. Then,
each of the CrystalEyes glasses were altered so that the two lenses within each pair are always
in the same state (opaque or transparent), but the two pairs are always in different states.
The lenses in one pair of glasses are transparent during even numbered refresh frames, and
the lenses in the other pair are transparent during odd nurnbered refresh €rames. When two
users Wear these two pairs of CrystalEyes, they will be looking at different refresh frames.
Images drawn on odd nurnbered refresh frames will be visible to one user, while images
drawn on even numbered refresh frames will be visible to the other user (see Figure 4.4).
Private information intended for only one of the users is displayed on either even or odd
numbered refresh frames, while public information intended for both users is displayed on
al1 refresh frarnes.
The customization necessary to produce the desired shuttering behaviour in the CrystalEyes gIasses was achieved by making minor modifications to the circuit board controlling
the glasses. The circuit board is xcessed by removing the front plastic face of the Crys
talEyes. Upon opening the glasses, the circuit board is visible. On the front of the board
Time
Figure 4.4: Shuttering sequence of CrystalEyes glasses after customization.
are three conductive paûs; on the back are traces connecting the pads to other circuitry (see
Figure 4.5 (a)). The two traces on the back of the board shown in the diagram are the two
traces carrying the signal that causes the left and right lens to change state between opaque
and transparent. Cutting either trace and making a connection, as shown in Figure 4.5 (b),
makes both lenses operate the same, both as a left lens or both as a right lensL.
The CrystalEyes Adapter Cable
So far, it has merely been said that the CrystalEyes glasses connect to, and receive a timing
pulse from, the synch-doubling emitter. Unfortunately, the synch-doubling emitter was
designed to emit infrared timing puises to wireless CrystalEyes (as the "emittern name
implies), and not to work in harmony with two pairs of wired CrystaiEyes glasses, Wireless
CrystalEyes could not be used for the system because they are difficult to customize. A
solution was required that would allow the synchdoubling emitter to work with two pairs
of wired CrystalEyes glasses.
What the synch-doubling emitter does ofFer to help support wired CrystaIEyes is a
"feature connector" that outputs a variety of signals from the synch-doubling emitter (see
Figure 4.6 (a)). These signais, dong with an external power source, are d that the wired
CrystalEyes need as input (see Figure 4.6 (b)). With an appropriate custom adapter cable
' ~ r ~ s t a l ~specBcations
~es
and customization instructions provided by
StemGraphics.
33
Tim Crane,
courtesy of
BackofBoard
Front of B
Back of Boprd
d
WmsOrMEyc
Back of Board
Wircd foc IIigbt Eyc
RightEye
Left Eye
Common
(a) Numai board
(bl Two versions of customizeà board
Figure 4.5: Circuit board in CrystalEyes wired glasses.
and a Y-adapter (available from StereoGraphics), two pairs of wired CrystalEyes can run
connecteci to a synch-doubling emitter. The construction of the adapter cable, including all
pin connections, is shown in Figure 4.7. It shoutd be noted that the power supply rnay need
a voltage limiter in order to provide 5 VDC at 10 rnA. A higher voltage rnay damage the
CrystalEyes glasses.
Figure 4.6: Pin layout of feature connector on synch-doubling emitter and CrystaiEyes wired
glasses.
Figure 4.7: Adapter cable used foc attaching two pairs of wired CrystalEyes glasses to a
synch-doubling emitter.
4.2
Software
The software side of the G-LEGO prototype system serves to both interface with the hardware, and provide an environment in which a pair of users can work. The environment
provided by G-LEGO is a collaborative LEGO-like construction environment in which the
pair of users works together to build a series of predefined structures out of blocks. Two
collaborative versions, one supporting privacy, the other not, were built for use in a user
study. A third single-user version was created for training users. The G-LEGO construction
task and al1 related G-LEGO software was developed by the author as a part of this thesis.
4.2.1
Technologies
G-LEGO was implemented in C++ in the Codewarrior development environment. The
DirectInput subAPI Frorn the DirectX API was used for interfacing with the USB mice.
OpenGL was used for graphical output, and GLUT was used For windowing and event
handling.
4.2.2
Task and Interface
The collaborative task given to users of G-LEGO was to construct predefined LEGO-like
structures out of blocks. It was thought that thii would be a suitable task, a s SDG literature
often cites construction tasks as appropriate for collaborative computer environments [5, 15,
321. LEGO is also an activity that is well undentood by many people, suggesting that users
might have an easier time learning a LEGO-themed game than a game using some lesser
known theme.
The G-LEGO interface sptits the screen into three distinct areas (see Figure 4.8). The
workspace, in the right portion of the screen, is the shared area in which usen build structures. Both usen can place and remove blocks, and change the properties of blocks that
have been placed or are about to be placed. Changing properties of blocks is done with
contextual menus that pop up ovet the block being edited. The instructions area, in the
left portion of the screen, displays the building instructions for the LEGO structures. Each
instruction sequence consists of six steps indicating how one structure is to be built. Each
step builds €rom the previous step, showing the same structure as the previous step with
a few changes. The instructions area can only display the six steps for one instructions
sequence at a time. Different instruction sequences are viewed by clicking on one of the
three appropriate buttons above the instructions area. Clicking on one of these buttons
removes the previous instruction sequence, and shows the new instruction sequence in its
place. The third area, at the bottom of the screen, holds control buttons. The "blockwand
"ditw buttons select the interaction mode for each user. Block mode allows a user to place
new blocks in the workspace, while edit mode allows users to edit blocks that have already
been plilceci. The rotate buttons allow users to rotate the workspace. As the workspace is
rotated, the instructions rotate as well so as to stay aligned. The quit button is used to exit
G-LEGO.
4.2.3
Versions
Three basic venions of the
GLEGO system were developed for use in user studies. The
three versions are known as the "private version," the "public version," and the "practise
venion."
The private venion of G-LEGO is the Single Display Privacyware version; it supports
the display of private information within the context of public information. There are three
components of the system that are kept private. First, cursors are private. Each user can
only see hii or her own cursor. When users are placing blocks or rnoving blocks around,
those blocks are viewable to both users, but the cunor performing the actions are private.
Secondly, contextua1 menus are private. When one user pops up a menu over the workspace,
Figure 4.8: Screenehot of GLEGO prototype system.
to interact with the other user's menus. Also, instructions are public. A result of this is
that both the users must look at the same instruction sequence. If one u e r changes which
instruction sequence is shown, thii change is retlected in the other user's view as well.
The practise version of the system was d to train users in the use of the GLEGO
interface. Clniilte the public version and private version, the practise version was meant
to be used by oniy one user at a tirne. The other main ciifference in the practise version
is that it has oniy one instruction sequence. if a user clicks on the buttons to select a
diierent instruction sequence, the same instruction sequence is stiii shown. This is because
the version is meant as a training tool; the accomplishment of building structures is not the
that both the users must look at the same instruction sequence. If one user changes which
instruction sequence is shown, thii change is reflected in the other user's view as weU.
The practise version of the system was used to train users in the use of the G-LEGO
interface. Unlike the public version and private version, the practise version was meant
to be used by only one user at a time. The other main difference in the practise version
is that it has only one instruction sequence. If a user clicks on the buttons to select a
different instruction sequence, the same instruction sequence is still shown. This is because
the version was meant as a training tool; the accomplishment of building structures is not
the main focus.
4.2.4 Data Input and Data Output
Ai1 three versions of GLEGO read input files that specify the three instruction sequences
shown to the usen. Three text files are read by G-LEGO, each file specifying steps for one
instruction sequence. Each file contains information for each block in each step, specifying
position, orientation, and colour, for each block. Two different instruction sets of 3 input
files were constructed for later use in a user study. Each input file in each set contained the
instruction sequence specifying how one structure was to be built. A portion of an example
input file is shown in Appendix A.1.
The private and public venions of G-LEGO also produce output files containing information outlining user behaviour. Two output files are produced, one for each user. Each
file is tagged with a timecode, an identifier to differentiatebetween the two users, as well as
information specifying which version of GLEGO produced the output. The different kinds
of behaviour information gathered is summarized in Table 4.1. This logging capability was
added to GLEGO for use in user studies. An example log is shown in Appendix A.2.
Table 4.1: Description of data collected in log files.
Description of Data
Value indicating from which of the two users this file originates.
1 Possible values are O and 1.
Date
1 Timestamp. Values from left to right are: yean, months, days,
hours, minutes, seconds.
The amount of time (seconds) the two users spent looking at the
Synched
same instruction sequence.
The amount of time (seconds) the two usen spent looking at
Not Synched
different instruction sets.
Instruction x time The amount of time the user spent looking at this particular
instruction sequence.
Drop Block
The number of times the user dropped a block in the workspace.
Red
The number of times the user changed a block's colour to red
Blue
The number of times the user changed a block's colour to blue.
Purple
The number of times the user changed a block's coiour to purple.
Rotate
The number of times the user rotated a block.
Delete
The number of times the user deleted a block that was already in
the workspace.
Cancel
The number of times the user cancelled a menu.
Edit Menu
The number of times the user called up the edit menu.
Place Menu
The number of times the user called UV the dace menu.
Data Label
User Index
1
1
Chapter 5
Experiment
5.1
Overview
The G-LEGO prototype system was e ~ i u a t e din an exploratory user study. Two versions
of the G-LEGO prototype system were uscd. One version supported the display of private
information, while the other did not. With this study, we attempted to gain initial insights
into the behaviour of users working with a Single Display Privacyware system. We also
attempted to discern any advantages and disadvantages to using SDP systems, as opposed
to using a more typical Single Display Groupware system. One main goal of the investigation was to determine possible future avenues of investigation into SDP. Participants in
the experiment filled out pre and post experirnent questionnaires, computer logs recorded
user actions within the system, and videotapes were made of interactions between users.
Observationai and statistical results were obtained from the different data sources.
5.2
5.2.1
Method
Participants
Sixteen ernployees of Electronic Arts Canada (EAC) were recruited by e-mail sent to al1
employees in the division. EAC employees were chosen as participants for two reasons.
First, the research (development and investigation) was being performed at EAC, making it
a convenient location for the expriment. Second, it was a worry that exposing inexperienced
computer users to novel technology might intimidate them, giving rise to results that would
be coloured by this intimidation. EAC employees are generally cornfortable with computer
technology, as revealed by the pre-çession questionnaire, hopefully reducing the intimidation
factor.
Two within-subjects variables, and one between-subjects variable, were identified for investigation in this experiment. The within-subjects variables were the G-LEGO version
presented and the instruction set attem pted. Both of these variables were counterbalanced
to reduce order and learning effects. The between-subjects variable was gender. One pair
of users was used for each of these combinations, resulting in 8 pairs of participants (see
Figure 5.1). Al1 participants had normal or corrected to normal vision and passed a colour
blindness test. They provided informed consent and were asked to receive consent from
their superiors to participate in the study, as participation was not a normal part of their
work duties.
Instruction Set
Version
Set B
- <
<
<Private
Set A-
Gender
Public
Maie
Female
Public -) Privatc
Rivate
SetB-)
SeiA
Public
4 Public
Femaie
<
Mde
Fcmale
Wvate
Female
Figure 5.1: Participant requirements for independent variables being controlled.
Ali 16 participants (8 pairs) compieted the ezcperiment successfuliy. Data from ali the
participants was analyzed. There were no significant problems due to equipment failure or
data corruption.
5.2.3 Software and Hardware Systems
The G-LEGO prototype system, described in Chapter 4, was used for the investigation.
Three versions of the prototype were used: the practise venion, the public version, and the
private venion. Two different sets of instruction sequences were also used.
5.2.4 Experimentd Task
Background
As the G-LEGO prototype was u d as the investigation tool in the experiment, the experimental task was derived €rom the functioning of that system. The G-LEGO system gives
pairs of usen the task of constructing three LEGO-Iike structures according to instructions
shown on the screen.
The specific task of construction was used for the G-LEGO system for several reasons.
First, construction is a task that has an analog in the physical world. People are skilled
at using their hands in construction tasks, and can transfer this skill to the digital world.
A different task, such as a spreadsheet, would require domain-specific knowledge that not
everyone would possess. Second, a construction task is well-suited to a collaborative environment. People often tackle construction tasks in groups, whereas it is more common to do
such things as writing and mathematics independently. Third, pairs of participants using
the system can intuitiveIy implement either divide-and-conquer strategies or cooperative
strategies, and can easily switch between these strategies during completion of the task, if
that is desired. It was thought that this capability would complement the abilities of the
system to display private as well as public information.
Description of the Tadlk
The task given to the participants was to build the three structures given by the system
as quickly and accurately as possible, with a time limit of ten minutes. There was no
feedback from the systern indicating success or fdure at any point during the experiment.
Participants had to judge for themselves whether or not they were placing blocks conectly.
Participants were told that they were to organize how they worked. They could work coop
eratively or independently as they desired. The relativeiy unstructured task and unspecified
work relationship was meant to encourage natural interactions between the two participants.
It was hoped that the participants would structure their approach according to how they
naturally wanted to work, rather than according to what the guideiines of the expriment
allowed.
5.2.5
Experimental Design
Independent Variablem
O
Game version
To determine advantages and disadvantages to the use of systems suppurting private
information and public information as compareci to systems only supporting public
information, the use of the two versions of the G-LEGO system was identified as a
within-subjects variable. This variable was counterbalanced between different su bject
pairs in order to reduce the effects based on the order in which the versions were
encountered. Possible values: {private version, public version)
Instruction set
As participants worked on two versions of the system (version order was within-
subjects), it was also desirable to eliminate learning effects across conditions. Learning
effects were minimized through the use of two different instruction sets, each set with
three instruction sequences. Each pair of users used a different instruction set with
either of the two venions of the software. This variable was also counterbalanced
between different subject pairs. Possible values: {Instruction Set A, Instruction Set
BI
O
Gender
In an attempt to identify any gender effects, gender was dso considered. Possible
values: {male, female)
The participants cornpieteci trials using both versions of the system (within subjects factor), with both instruction sets (within subjects factor). A b , considering gender (between
subjects factor), the experirnent was a 2 x 2 x 2 rnixed design.
Instruction Sets
Two instruction sets were created for the experiment, known as Instruction Set A and Instruction Set B. Both instruction sets contained three instruction sequences. iU1 instruction
sequences had six steps, and resulted in LEGO-like structures that had a random appearance to them. An attempt was made to have corresponding structures €rom each instruction
set be of q u a i complexity of construction.
One method used to keep complexity of the different structures similar was to specify the
number of blocks aùded to the structure between each step of the sequence. For example,
the first step of the first instruction sequence in both instruction sets involves placing 4
blocks, while the second step involves placing another 4 blocks in addition to the previous
4. The number of blocks placed between each corresponding step was the same for the iirst
two instruction çequences of both instruction sets (see Table 5.1). The number of blocks
placed was greater for the third instruction sequence in each instruction set, but was still
the same between instruction sets (see Table 5.2).
Table 5.1: Number of blocks added in each step for instruction sequence 1 and 2, for both
instructions set A and B.
1 Stev 8 1 Number of Blocks Added 1
I
1
1 TOTAL: 1
19
The third structure of each instruction set was meant to be more difficult to build than
the first two. Requiring that more blocks be placed was one way of achieving this. Also,
each of the third structures had a "trick" involved in completing the fifth step. This trick
required that some previously placed blocks be removed before a new block could be placed.
The third structure was made more difficult in order to challenge participants. Providing
chdenging instruction sets to users potentially results in more interesting observational
results.
Table 5.2: Number of blocks added in each step for instruction sequence 3, for both instruction set A and B.
Step # Mumber of Blocks Added
1
5
I
1 TOTAL: 1
I
1
22
Pilot Study
Several informat pilot studies were performed using volunteers. This was done in order
to determine if the instruction sets were suficiently challenging to complete. The pilot
studies also served to highlight interface issues with the G-LEGO system that needed to be
addressed before running the study.
Experimental Setting
The experiment was conducted in a cubicle in the Tooh and Libraries department of EIectronic Arts Canada, in August 2000. Normal work activities continued around the cubicle
while the experiment was run, but the walls of the cubicle served to isolate participants
from distractions. The cornputer rnonitor was placed in the center of the desk, with the two
mice pIaced directly in front of it, The CPU case and the keyboard were placed out of the
way of the users. Two chairs were placed in front of the desk so that each user would have
qua1 access to the display. The video camera was placed in front of, and to the left of, the
users. It was placed so as to capture their facial expressions and physical actions. A capture
of video data from the experiment is shown in Figure 5.2, and a diagram of the workspace
is shown in Figure 5.3.
Experimental Schedule
Participants were scheduled according to their avaiiabiiity, as employees at EAC tend to be
vecy busy. The timeline for a typical session is shown in Table 5.3.
Figure 5.2: Video capture of tnio participanta in the expriment.
5.2.6
Data Anaiysis
Data Collection Techniqueta
Three methods of data collection were used: questionnaires, videotapes, and compu ter logs.
administered both prewsion and pt--ion.
Videotapes recorded
user behaviour during the -ans.
Cornputer bjp recarded user actions within the G
LEGO syatem. Refer to Appendix 8.1 and Appendix 6.2 for the pr~aessionand post-session
questionnaires, and Appendix A.2 for an example log file.
Questionnaira were
Pteference
Prefetenœ waa measareci using pt-session questionnaires which wete administered
a€tetboth trials. O p i ~ o n sregarding the private and public versions of the software,
a s w d as particdar featnres of the p h t e version, were collectai. Preference was
deterrnined by asking participants how much they üked a particnlar version or feature,
\
\
L
\
\
\
&ta
1
,4
chair'
.-
Desk
Figure 5.3: Layout of the experimental setting.
using a five point scale. Users were also given space in which to state how they Felt
about particular versions or features. User comfort level was also gathered For the two
versions by asking users to rate their comfort on a scale from 1 (very cornfortable) to
5 (very uncomfortable).
Collaborative St rategy
Collaborative strategy, whether participants tended to collaborate or work independently, was measured by computer log. The system kept track of how much time
users were looking at the sarne instruction sequence, and how much time they were
looking at different instruction sequences. These logs, along with observations from
the videotapes, were used to determine collaborative strategies.
O
User Behaviour
As the experirnent was largely exploratory, it was thought that there might be dependent variables of interest that could not be identified prior to the experirnent.
These variabIes were placed under the general category of "user behaviour." Different
aspects of user behaviour were collecteci using al1 three data collection techniques,
questionnaires, videotapes, and cornputer logs.
Table 5.3: Example experimental scheduli
Time (minutes)
Item # Activity
Participants Arrive
1.
General Introduction
2.
Information and Consent Forms
3.
4.
Colour Blindness Test
Background Questionnaire
5.
Introduction to Training Condition
6.
7.
Training Conditions (once for each participant)
Introduction to First Experimental Condition
8.
9.
First Experimental Condition
Short Break
10.
11.
Introduction to Second Experimental Condition
Second Experimental Condition
12.
13.
Post-session Questionnaire
TOTAL:
Results
5.3.1
Preference
When asked to state a preference for either the public or private versions of the system,
and describe why they liked that version, 7 participants stated they preferred the public
condition, 6 participants stated they preferred the private condition, and 3 participants
stated they had no preference. It is interesting to note, however, that of the 7 participants
who wrote that they preferred the public condition, 3 made specific staternents tbat they
appreciated specific features of the private condition, such as:
"1 prefer public, but we should have been aliowed to look at different instruc-
tions."
"1 prefer the public as it allows more coordinat[ion], but the overiapping menus
have to be resolved to prevent it from frustrating."
"Pubiic, except for the menus."
Quantitative results from the pst-session questionnaire, analyzed with a 2 related samples Wilcoxan test, indicated no significant difference in comfort level between the private
version and public version (2= -0.962, ns). These results measured user comfort on a five
point scale (l=Very cornfortable, 5=Very ftustrated). The average score given by participants For the public version was 2.25, whiIe the average score given for the private version
was 1.94 (see Figure 5.4). Thirteen participants rated the private version as better than
neutral, while 9 participants rated the public version better than neutral.
n
Privata Version
iPublic Version
Figure 5.4: User experience with private and public version (1 = Very cornfortable, 5 =
Very frustrated).
The pst-sesion questionnaire also asked participants to rank different features of the
private version on a scale of one to five (1=I liked it a lot, 5=I disliked it a lot). The data
was anaiyzed using a onesample Kolmogorov-Smirnov non-parametric test, and did not
produce statistically significant resuIts for either private menus (Z=1.185, p=ns) or private
cursors (2=0.871,p=ns). The responses concerning private instructions was marginally
significant (Z=1.300, p=0.068). When rated on a scaie from 1 to 5, as shown in Figure 5.5,
participants appear to have had a fairly strong king towards instructions being private and
menus being private. The reaction towards private cumn was mixeci.
5.3.2
Collaborative Strategy
Whiie the public version of the system encouraged collaborative work, by requiring users
to look at the same instruction sequence, the private version was meant to aiiow a m k of
IInstnictions
Menus
Figure 5.5: User response to private instructions, private menus, and private cursors (1 = I
Iiked it a lot, 5 = 1 disliked it a lot).
coliaborative and independent strategies. This was done by allowing users to look at different
instruction sequences, which supports independent work, or the same instruction sequence,
which supports collaborative work. Log files recorded the amount of time participants spent
in these two states, giving an indication of coliaborative strategies used in the trials. The
data €rom the log files is summarized in Figure 5.6.
Analyzing the data in Figure 5.6 it becornes apparent that 4 pairs of users worked almost
entirely collaboratively, spending between 98% and 100% of their time looking at the same
instruction sequence. Two pairs worked almost entirely independently, spending 6% and
7% of their time looking at the same instruction sequence. The final two pairs employed a
hybrid strategy, sometimes looking at the same instruction sequence, sometimes looking at
different instruction sequences. These pairs spent approximately 18%and 39% of their time
looking at the same instruction set. Commentç from the post-session questionnaire serve to
reveal some of the reasoning behind the use of hybrid strategies:
"Even though we were working on diierent parts we could stiii proof the other
guy's work easily and quickiy."
1
2
3
4
5
6
7
8
Pair #
Figure 5.6: Percentage of time each pair spent looking at the same instruction sequence.
"Private condition rocked simply because it was easier to make better use of our
tirne because we could both work on different sets and then when we started
working on the same set we could still talk about what we were going to do."
"For the private sets we worked in parallel on different data sets and then worked
together on the third."
5.3.3
User Behaviour
This section describes general results that were obtained through a combination of informal
observations, analysis of the videotapes, and analysis of the logs and questionnaire results.
These results are mostly qualitative in nature. The results are valuable, in that they provide
early insights into users' interactions with a prototype SDP system. These hsights can be
used to suggest possible future directions of investigation.
Variation in Prefemnce for Private Features
Three aspects of the environment were kept private in the private condition: cursors, menus,
and instructions. While it may be assumed that users would either like al1 three aspects to
be private, or al1 three aspects to be public, this was not always the case. It was found that
users often liked one aspect of the environment to be private, while they preferred other
aspects to be public.
Observation and analysis of the videotape data revealed that participants wanted some
aspects of the work environment to be private and others to be public. For example, some
of the participants made positive rernarks concerning private aspects of the software while
they were working, such as ''This is great, our menus don't get in the way." They, however,
would then proceed and possibly express frustration at not being able to see their partner's
cursor. The source of the satisfaction and frustration was not predictable or consistent
between pairs, but it was common that pairs would express satisfaction towards one private
aspect while expressing frustration towards another.
The difference in preferences reiated to private functionality was also evident in participants' answers in the post-questionnaire. When ranking their like or dislike of the
three private aspects of the private venion, 6 out of 16 participants scored at least one
aspect favourably, while scoring at le& one other aspect neutraily or disfavourably. The
other 10 participants were consistent in ranking al1 three aspects either favourably or neutrally/disfavourably.
Effectiveness of the Private Condition
Through observations gathered during trials and analysis of videotape data it was found
that users were able to adapt well to the functionality of the private version of G-LEGO.
All users who were able to function properly in the public version were also able to function
in the private version. Individual membecs of two different pairs did have significant trouble
working in the prime condition, but thii was because of a basic difficulty in operating the
system, rather than confusion induced by the privacy functionality of the private version.
This was supported by the fact that the same participants aiso had difficulty functioning in
the public venion.
While the participants were able to function in the private condition, there was often an
adaptation period during which users gained an understanding of how the system operated.
Even though participants had received instruction on the functionality of the private version,
they were still often surprised when actually faced with operating in the environment. An
example of this surprise would be one participant gesturing to their partner with a private
cursor, saying "Here, look at this." The other user, not seeing the gesturing motion of the
private cursor, would get confused. The actions and resulting confusion are natural, as two
users working on a shared display expect to see exactly the same content. The confusion,
however, was typically short-lived, as participants developed an understanding of what was
private and what was public.
It is aiso interesting to note that some of the participants complained of eye soreness
after completing the trials. This is most likely due to the shuttering operation of the glasses.
The effect was the same for both public and private versions, as users wore the glasses for
both versions.
Act ivity hvels
The ievel of user activity for each pair was found to be marginaliy significant between the
two conditions. A repeated measures analysis found that the number of actions performed
by each pair (placing blocks, rotating blocks, changing colour of blocks) was found to be
marginally significantly higher in the private version (F(1,7)= 3.668,~= 0.097,r2 =
0.344, pmer = 0.380). Each pair of participants performed an average of 147.0 actions in
the public version, and an average of 223.5 actions in the private version.
The reason for the increased activity in the private condition could have been that
participants were more efficient, but it could also have meant that they were making more
errors, and correcting those errors. In an attempt to rule out one of these possibilities the
number of block placements, with the number of block deletions subtracted, was analyzed.
This value gives an indication of the number of blocks placed correctly by the pair. The
results of a repeated measures analysis show no significant difference between the private
and public venions (F(1,7)= 2.344, p = ns, rZ = 0.251, pozuer = 0.264), with participant
pairs placing an average of 28 blocks in the private version and an average of 23 blocks in
the public version.
The relatively large effect size but low power of both activity ievel results indicates that
this evduation should be repeated with a larger sample size to fuUy explore the effects on
activity level.
5.4
Discussion
The results of the study indicate that the SDP system investigated was generally well
understood and accepted by the participants. Only one of the sixteen subjects indicated
discomfort with the system, by scoting it as a 4 on a scale of 1 to 5 (1= Very Comfortable,
5 = Very Uncornfortable). The conclusion that participants undentood and accepted the
system is also validateci by the other resulîs of the study.
The evidence presented in Section 5.3.3 compares the effectivenessof interaction of participants in both the private and public conditions. It was found that in general participants
were able to function effectively in both conditions. This indicates that it is not daunting
for users to adapt to a system that supports privacy on a shared display. It is questionable,
however, whether this result can be generahed to cover al1 potential users. The participants
in the experiment were, without exception, experienced computer users. This experience
may have made it easier for them to adapt to new interaction paradigms. It would be
desirable to perform a similar experiment with a more general participant base in order to
determine how broadly these results can be applied.
The results concerning the variation in preferences, discussed in Section 5.3.3, also have
interesting implications. It was apparent that different users preferred that different cornponents be public or private. This suggests that it would be useful for SDP systems to
support customization of privacy support. It might be useful for users to choose what information is private, and what is public. Users could also switch information €rom being
public to being private, and vice versa. Implementation of this, however, could exacerbate
one problem that was identified, namely that users occasionally become confused as to what
information is public and what is private. To combat this problem, it would be desirable to
tag information to indicate whether it is private or public.
The results regarding activity levels of participants, discussed in Section 5.3.3, are harder
to analyze than the other results. What can be stated is that activity levels reinforce the
conclusion that users were able to interact with the private condition. A high action count
can be indicative of successful interaction. What is more difficult to explain is the reason
participants were more active in the private case as compared to the public case. One
possible explanation is that the less restrictive nature of the private system dowed users
to work so that they did not obstruct each other, For example, if two users were working
together on a structure and one user was not abIe to contribute adequately to the work,
that user could move on and work on another structure.
The expecimental results were useful in identifying strengths and weaknesses of the two
versions of the G-LEGO system. It was found that the private version was useful in providing
users with a flexible interface that supports different types of collaboration (independent
or coilaborative). It was also found that the reduction in screen clutter provided by the
private version was often appreciated. Finally, concerns were raised regarding the need to
distinguish private information from public information. From these results, we were able
to identify pmible directions for Future work. These include the necessity to determine the
generaiizeability of the results, the necessity to investigate customizeability of privacy, the
necessity to investigate privacy tagging, and the necessity to investigate the differences in
activity levels between private and public systems.
Chapter 6
Conclusions
Previous research in Single Display Groupware suggests that shared screen systems provide
a rich collaborative environment in which to work. One of the ongoing issues with SDG
systerns, however is that they do not provide a mechanism for displaying private information.
We saw that existing approaches to allowing private information xcess with shared displays
are effective, yet have drawbacks of their own. This thesis presented a novel interaction
model, Single Display Privacyware, that addresses the problerns of privacy support on shared
displays, without suffering from some of the drawbacks associateci with other solutions. We
have also presented a testbed SDP system that facilitates expioration of issues related to
t his interaction model.
The experimental results showed that users were generally able to adapt to the use of
an SDP system. This result in itseif suggests that it rnay be valuable to provide users with
an SDP alternative to traditional desktop or SDG systems. Observing when users choose
SDP systems over traditionai SDG systems will give further insight into the impact SDP
systems can have in groupware environments.
Whiie the experimentai results were not conclusive in determining whether or not SDP
offers significant advantages over SDG,the results do suggest that SDP could improve
computer-supported collaboration. We have identified important directions of future investigation into SDP which will provide vaiuabie insight into the rote that SDP can play.
6.1
Contribution
The m a t significant concept we hope to have brought forward is the realiiation that, in
shared display environments, it can be useful to display private information within the
public context of the shared display. The ability to show private information on a shared
display lends flexibility to the interaction experience for al1 users of the display, making it
possible to address a host of issues inherent in Single Display Groupware. This realization
concerning the role of private information leads dicectly to the definition of Single Display
Privacyware as a valuable interaction mode1 for computer supported collaboration.
6.2
Future Directions
The reçearch presented in this dissertation is the beginning of a long process of investigation
required to fully understand SDP and its implications to the user experience. Thus, one of
the main goals was to identify topics of interest that could be investigated in future, more
focussed, research. The implementation produced a successful prototype, however some
technical limitations were identified that must be addressed. Also, the experiment with the
prototype SDP system was useful in identifying interface issues that should be investigated
in future research. The main possible future investigations identified by the research are as
follows:
O
O
Investigate the feasability of extending the current shutter glasses display technology
to support more users or provide higher quality output.
Investigate new techniques/methods for implementation of SDP systems. These technologies might include the use of polarized glasses, head-mounted displays, or other
types of displays (LCD, tabletop, large-screen). These technologies might be used to
develop systems that support more than two userç, or systems that are less intrusive
to the users.
Investigate the value of allowing users to choose what display components are private
and what display components are public. Also, it would be useful to determine differences in behaviour when users are able to customize their environment as opposed to
when they are unable to customize their environment.
0
Investigate how much users are able to undentand what display components are private and what are public, and investigate ways of increasing users' ability to understand what is private and public.
0
Investigate how users with varying computer experience and different backgrounds
adapt to the use of a novel interaction paradigm such as SDP.
0
Determine when and why activity Ievels differ with Single Display Privacyware systems
as compared to Single Display Groupware systems.
0
Investigate Single Display Privacyware as applied to different tasks. The construction
task investigated in this thesis is only one of many possible. Tasks such as mathematical coordination, text editing, or game playing rnight be investigated.
0
The efficiency and performance of user interactions with the SDP system was not
studied in this thesis, It would be logical to perform a future study that focusses
specifically on whether SDP systems support more or less efficient interactions, as
compared to traditional SDG systems.
6.3 Final Thought
Computers as tools are capable of tackling a wide variety of problems in many different
problem domains. Ideally, tools that function on a particular problem in a specific domain
are designeci so as to be used comfortably and efiiciently in that environment. It is thus
desirable to address issues particular to a speci.fic environment when designing tools to be
used in that environment. Computer systems are used in many different environments,
and present different sets of design problems in each of these. This research shows that
Single Display Privacyware systerns can aileviate some of the problems with Single Display
Groupware that have not been othenvise addressed by other systems.
Appendix A
G-LEGO Input and Output Files
This appendix shows a sample input file required by G-LEGO, as well as a sample output file
produced by G-LEGO.The input .file contains orientation, position, and colour information
for each block, in each step of one instruction sequence. Three input files are required for
G-LEGO to run, one file for each of the three instruction sequences. The output file contains
information identifying game version, user identifien, timing information, and action counts.
Two output files are created each time G-LEGO is run, one file for each player.
Sample Instruction Sequence Input File
A.l
#=ER
x 2
Y 0
1
z -3
O
c O
n
O
l N e x t block
x -2
Y 0
z -3
O
O
c 2
n
# N a t block
x -3
Y 0
z 0
O
1
c l
n
UNext block
x -2
Y 0
2 3
O O
c O
x 2
Y 0
z -3
O
O
c O
n
# N e t block
-2
Y 0
Y
z -3
O
O
c 2
n
# N e x t block
x -3
Y 0
z O
1
c 1
O
n
# N a t block
x -2
Y 0
2 3
O O
c O
n
maw
x 2
Y 0
z 3
n
n
222222222222
A.2 Sample Log Output File
PrivateIA
User 1ndex:l
Date: 100 9 16 21 52 35
Synched:30.810000
N o t Synched:59.700000
Instruction O tirne: 30.810000
Instruction 1 time: 59.700000
Instruction 2 tirne: 0.000000
DropBlock: 5
Red: 3
Blue: 2
Purple: 7
Rotate: 12
Delete: 3
Cancel: 1
EditMenu: 8
PlaceMenu: 9
Appendix B
Experiment Documents
This appendix shows the documentation accompanying the experiment. It includes instruction and information sheets shown to participants, colour blindness cards used to test
participants, and pre and post-session questionnaires used to measure participants' reactions
to different aspects of the G-LEGO system.
B.1 Pre-Session Questionnaire
Pre-Experiment Questionnaire
Name:
Gender:
Male
Fernale (circie one)
lob Title at EA:
1. How often do you use a computer? (circle one)
Never
A few cimes a month
A few cimes a week
Every day
2. How oîlen do you work wiih somme elst on the same computer?
Never
A few u'mes a month
A few rimes a week
Every day
2. The THREE activities you perform most offen on acompuîer are:
E-mail
Spreadsheet
Word Rocessing
2-D Art
3-D Art
Oher
(circle one)
(cùcle THREE)
Programming
3. In general, how do you fa1 working by yourself m a cornputer? (circleone number)
Very cornfortable
1
Very Frustrated
2
3
4
5
4. In general, how do yw feel working with mecine else on the siune computer? (circle one number)
Very fnistrated
Very cornfortable
I
2
1
4
S
B .2 Post-Session Questionnaire
1. How did yw fcel abwt the fs* you and p r parmer wen working on ihe wnt screcn? (&le
number)
Very comfmble
I
2
3
L How did you fa1 waking in ihc 'public" condition?
Very comfmblc
1
2
3
3. How did yai fœl mxkinp in the "privnle"mditim?
Vcry comfmblc
1
4
Very fmmtcd
5
(circle mc numbcr)
4
V q Inuÿoted
5
( c h i c m e numkr)
Vtry hurmtcd
2
3
5
4
4. in l e 'public" condition. how eohiurpgcd did you lccl to m p k ncu pouibilitia?
numbrr)
Vcry ~ncoungcd
I
2
3
4
6. in l e "pfivnu"
2
3
4
tcircle ont
V a y dismumgcd
5
S. in l e "privnu"condition, how uiewrnged did yai fed to utplon acw pouibilitiu?
numba)
Veiy cncwmgcd
1
one
(cide aie
Vcry diiourpged
5
condition. how did yai fccl Pbait ihc menitr bcingpfiwu? (cirele one numkr)
I likcd it a lot
1
2
3
4
1 d i i i it a lot
5
1. in iht p i w u " condition, how did you fccl &out the inrmiaionr king privote? (ciitlc one numkr)
1likcd it a la
1
8.
2
3
1
1d i i i k a l it a lot
S
in the *privmte" condition. how did yai lcel abwt ihe m a b u 4 p h t e ? (ci& one numkr)
1 likcd ita lot
1
2
3
4
t didikcd it a lot
5
9. Whatdid you üLt about the "publie"oondition?
10. Whnt did you d i i l l e about ihc "public"condition?
I I . What did you likc about ihe "privnic" condition?
12. Whnt did you diille about the "privait" condition?
13. Do you have my oiher cornmenti?
The game you am about 10 play is a computet version of Ihe popular LEGû brick
building system Kou will play the gamc o n r four Ws.
The W m - U p
ï t fust
~ trial
~ is a warmup to allow you to gct used to ihe contmls. lhis trial will be
ptayed alom and it will last 5 minutes.
The Coopcrative Triais
Thc ncltt tbnt triais will be playai with a partna. In cpch trial you and your panner wiii
work togcthw wich ihe stiarcd goal ofbuildingk c LEGû s t m l u m as quickly and
anwately as possible.
The Wark A m : Tht large green square surfacc on t
h nght is the work m a wbere y u
place bkcks in d r t o hildyourstntctum.
Fbe ï&mdbm On the kft p u sa riep-by-stcp insiniaions on how to build one o f
ihe suuaiacs. Eacti of the stcps buildsoff of the lmstcp. You GUIset insmctions for
OIE structure at a t
h
.
If p u clickone of t
h ihnt bunons above h z instructions p u
wiü sce a dincrcni inst~ctionset for a diffemt maure (in Ihe wanrrup thm is only
one insauction set). AU ihiee stnic~unsan to be hiit in iht wotk area.
Tbt Wîe B u ü o ~ Ressing
:
eithet of the two 'htate" bunons iuthe bottom of the
scmn nitates the wo& space as weU as the h c t i o n s .
ï h e Bbdr Button: Pnssingt
h "Bbck"button puts you in block placing mde. In thii
mode left-cücking in the work arca drops a block. Right clicking brings up a m n u with
which you can change the pmpcriies of the block you will drop. With this mnu you can
rotate the bbck 90 degrees, or change it's
colour.
The Mt bu th^ Pressing t k "Edit" button puts you in editing rnodc. In ihis mode you
change the pmpertics olbbcks that have alrcady bccn placed, To do this place p u r
cursor ovcr the point on the green surface above which the block you wish to cdit sits
(NOTdirectly over t k bioek). The block will bc highlighicd with white balls. Right
ciicking wül king up a menu with which you can deletc the block (only if it is on top of
ihe stack) or change it's colour.
The Quit Buttan: Press this bumn when you are donc building d l t h m structures and
an confident ihat they arc comct. Pressing this button ends the trial. The experirnenter
will also rcquest that you press quit if you run out of time kfore you am done building
the stnictures.
B.4 Consent Form
SINW FRASER UNIVERSITY
DATE
B .5 Information Sheet
Information Sheet to Partici~ants
Introduction
in out research. we are exploring new ways of presenting information to multiple users who are working or
playing on the same computer display. Specifically, we have developed a display technique that allows
private information to be shown to mly oae user, while hiding that infonnation from other users who are
looking at the same computer display. We are nmning a study to determine the usefulness of this display
technique. The results of this snidy will provide us with quantitative and qualitative information that may
validate the technique a n d h provide us with a direction of investigation for future research.
In a user study that will take approximately 60 minutes to complete, you will be asked to use two different
programs on a personal computer. Each program presents a workspace in which Lego bricks can be placed
in order to construct structures. Your task wiU be to construct three separate structures in the workspace, as
quickly and accurately as possible. You will work with a partner on the construction task. Both of you will
work on the same computer, and will be aMe to interact with ihe computer with your own mouse and
cursor.
Before and aîler the expriment, you will be asked to fiIl in a questionnaire. The fint questionnaire will
help us determine how familiar you are working with computers in different collaborative environments.
The second questionnaire will indicate your preference for either of the programs. During the experiment,
the computer will record your mouse actions, and a video carnera will record your physical actions and any
verbai communication. You are ailowed to withdrawaI your participation in the experiment at any time if
you so desire.
Your participation in this study wiii help to contribute to the body of knowledge in this area of research, It
is very important that we be able to justify new ideas in orâer to improve current human-computer
interfaces, We h o p to obtain statisticaiiy significant data fiom this experhent that wiU lead us towards
this goal.
There are no personai risks for the subjects.
B.6 Colour Blindness Test
Bibliography
[II Benjamin B. Bederson, James D. Hollan, Allison Druin, Jason Stewart, David Rogers,
and David Proft. Local tools: An alternative to tool palettes. In Proceedings of W T
i96, pages 169-170. A C M Press, 1996.
[2] Eric A. Bier and Steve Freeman. MMM: A user interface architecture for shared editors
on a single screen. In Proceedings of UIST '91, pages 79-86. ACM Press, 1991.
[3] Eric A. Bier, Maureen C. Stone, Ken Pier, Wiiiiarn Buxton, and Tony D. DeRose.
Toolglass and ma& lenses: The e t h r o u g h interface. In Proceedlngs oJSiCCRAPH
'93, pages 73-80. ACM Press, 1993.
[4] Lauren J. Bricker, Marla J. Bennett, Emi Fujioka, and Steven L. Tanimoto. Colt: A
system for devetoping software that supports synchronous collaborative activities. In
Pmeedings of EMedia '99, 1999.
[5] Lauren J. Bîicker, Steven L. Tanimoto, Alex 1. Rothernberg, Danny C. Hutama, and
Tina H. Wong. Multiplayer activities that develop mathematical coordination. In
Pmeedings of CSCL '95, pages 32-39,1995.
[6] Donald A. Cox, Jasdeep S. Chugh, Car1 Gutwin, and S a d Greenberg. The usability
of transparent overview layers. in Proceedings of CHI '98, pages 301-302. ACM Press,
1998.
[7] Paul Dourish and Victoria Belloti. Awareness and coordination in shared workspaces.
In Pmeedings of CSCW '92, pages 107-114. ACM Press, 1992.
[8] Saul Greenberg, Michael Boyle, and Jason LaBerge. PDAs and shared public displays: Making personal information public, and pubiic information personal. Persona1
Technologies, 3jl), 1999.
[9] Car1 Gutwin and Saul Greenberg. Design for individu&, design for groups: Tradeoffs
between power and workspace awareness. in Pmeedings of CSCW '98, pages 207-216.
ACM Press,1998.
[lO] Cari Gutwin and Saul Greenberg. Effects of awareness support on groupware usability.
In Pmeedings of CHI '98, pages 511-518. -4CM Press, 1998.
[Il] Carl Gutwin and Mark Roseman. A usabiity study of awareness widgets in a shared
workspace groupware system. In Pmeedings of CSC W '96, pages 258-267. ACM Press,
1996.
[12] Beverly L. Harrison, Hiroshi Ishii, Kim J. Vicente, and William A. S. Buxton. Transparent layered user interfaces: An evaluati~nof a display design to enhance focused
and divided attention. In Pmeedings of CHI '95, pages 317-324. ACM Press, 1995.
[13] Juan-Pablo Hourcade and Benjamin B. Bederson. Architecture and implementation
of a Java package for multiple input devices (MID). Technical Report CSTR-4018,
University of Maryland, May 1999.
[14] Kori M. Inkpen, Kellogg S. Booth, Steven D. Gribble, and Maria Klawe. Give and take:
Children collaborating on one computer. In Pmeedings of CHI '95, pages 258-259.
ACM press, 1995.
[15] Kori M. inkpen, Wai-ling Ho-Ching, Oliver Kuederle, Stacey D. Scott, and Garth B. D.
Shoemaker. "This is fun. we're al1 best friends and we'rc al1 playing!": Supporting
children's synchronous collaboration, In Pmeedings of CSCL '99, 1999.
[16] Kori M. Inkpen, Joanna McGrenere, Kellogg S. Booth, and Maria Klawe. The effect
of turn-taking protocols on children's learning in mouse-driven collaborative environments. In Proceedings of Graphies Interface '97, pages 138-145, 1997.
[17] Kori M. Inkpen, Rena Upitis, Kellogg Booth, and Maria Klawe. Cooperative learning
in the classroom: The importance of a collaborative environment for cornputer-based
education. Technical Report TR-94-5, Department of Computing Science, University
of British Columbia, 1994,
1181 Hiroslii lshii and Minoru Kobayashi. Clearboard: A seamless medium for shared drawing and conversation with eye contact. In Pmeedings of CHI '92, pages 525-532. ACM
Press, 1992.
[19] Gloria Mark, Jorg M. Haake, and Norbert A. Streitz. The use of hypermedia in group
problem solving: An evaluation of the DOLPHIN electronic meeting room environment.
In Pmeedings of EuroCSCW '95, pages 197-213. KIuwer Academic Publishers, 1995.
[20] Gloria Mark, Jorg M. Haake, and Norbert A. Streitz. Hypermedia structures and
division of labour in meeting room collaboration. In Pmeedings of CSCW 36, pages
170-179. ACM Press, 1996.
[21] Brad Myers, Kin Pou ("Leon) Lie, and Bo-Chieh ("Jerry") Yang. Two-handed input
using a PDA and a mouse. In Pmeedings of CHI 2000, pages 4148,2000[22] Brad A. Myers. The Amulet environment: New models for effective user interface
software development. IEEE Tmnsactions on Software Engineering, 23(6):347-365,
June 1997.
[23] Brad A. Myen. An implementation architecture to support singledisplay groupware.
Technical Report CMU-CS-94139, Carnegie Mellon University, 1999.
1241 Brad A. Myers, Herb Stiehl, and b b e r t Gargiulo. Collaboration using multiple PDAs
connected to a PC. In Proeeedings of CSCW '98, pages 285294. ACM Press, 1998.
[25] Elin R. Pederson, Kim McCall, Thomas P. Moran, and Frank G. Halasz. Tivoli: An
elect ronic white board for informal workgroup meetings. In Pmceedings oj lNTERCHI
'98, pages 391-398. ACM Press, 1993.
[26] Jun Rekimoto. A multiple device approach for supporting whiteboard-based interactions. In P m e d i n g s of CHI '98, pages 1ô-23. ACM Press, 1998.
[27] Jun Rekimoto and Masanori Saitoh. Augmented surfaces: A spatially continuous work
space for hybrid computing environments. in Pmeedings of CHI '99, pages 378-385.
ACM Press, 1999.
[28] Stacey D. Scott, Garth B. D. Shoemaker, and Kori M, Inkpen. Towards seamless
support of natural colIaborative interactions. In Pmeedings of Gmphics Interface
2000, pages 103-110,2000.
[29] Garth B. D. Shoemaker. Supporting private information on public displays. In CHI
2000 Eztended Abstmcts, pages 349-350. ACM Press, 2000.
[30] Garth B. D. Shoemaker and Kori M. Inkpen.
MIDDesktop: An application framework for single display groupware investigations.
Technical Report TR 2000-01, School of Computing Science, Simon Fraser University, 2000.
ft p://fas.sfu.ca/pu b / c s / T R / 2 0 0 0 / C M P T 2 ~
[31] Garth B. D. Shoemaker and Kori M. Inkpen. Single Display Privacyware: Augmenting
public displays with private information. In Pmeedings of CHI 2001. ACM Press,
2001.
[32] Jason Stewart, Benjamin B. Bederson, and Allison Druin. Single Display Groupware:
A modei for CO-presentcollaboration. In Pmedings of CHI '99, pages 286.293. ACM
Press, 1999.
[33] Jason Stewart, Elaine M Raybourn, Ben Bederson, and AHison Druin. When two
hands are better than one: Enhancing colIaboration using single dispIay groupware. In
Proceedings oi CHI '98, pages 287-288. ACM Press, 1998.
[34] Masayuki Tani, hrlasato Horita, Kimiya Yamaashi, Koichiro Tanikoshi, and Masayasu
Futakawa. Courtyard: lntegrating shared overview on a large screen and per-user detaii
on individual screens. In Pmeedings oj CHI '94, pages 44-50. ACM Press, 1994.
[35] John Underkofler and Hiroshi Ishü. Urp: A luminous-tangible workbench for urban
planning and design. In Pmeedings of CHI '99, pages 38ô-393. ACM Press, 1999.