addresses, and provides example application domains that could benefit from ... system with the goal of identifying advantages and disadvantages to using ... to interactions with these systems, but software companies focus their ... provides software authors with the ability to seamlessly support any number of generic input.
SINGLE DISPLAY PRIVACYWARE: AUGMENTING PUBLIC DISPLAYS WITH PRIVATE INFORMATION by Garth B. D. Shoemaker BSc.(Hons.), Queen's University, 1998 a thesis submitted in partial fulfillment of the requirements for the degree of Master of Science
in the School of Computing Science
c Garth B. D. Shoemaker 2000
SIMON FRASER UNIVERSITY November 2000
All rights reserved. This work may not be reproduced in whole or in part, by photocopy or other means, without the permission of the author.
APPROVAL Name:
Garth B. D. Shoemaker
Degree:
Master of Science
Title of thesis:
Single Display Privacyware: Augmenting Public Displays with Private Information
Examining Committee: Dr. Mark Drew Chair
Dr. Kori Inkpen, Senior Supervisor Dr. Tom Shermer, Supervisor Dr. Eric Schenk, SFU Examiner
Date Approved: ii
Abstract The traditional human-computer interaction model limits collaboration by restricting physical computer access to one user at a time. 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 useful 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 all users. Some researchers have addressed the privacy issue by developing techniques that allow small private displays to be networked with a large shared display. 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 private 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 ltering the output of the display. This interaction model can be used to address the screen real-estate problem and the awareness overload problem, and also, unlike other solutions, allows private information to be shown within the public context of the shared display. A description of a prototype implementation of an SDP system is given, along with results of a user study performed to investigate users interacting with the system. The signi cance of SDP and conclusions regarding future research in the area are discussed.
iii
For Amy Jo Johnson, without whom there would be no Pink Ranger.
iv
Contents Approval
ii
Abstract
iii
Dedication
iv
List of Tables
viii
List of Figures
ix
1 Introduction
1
1.1 1.2 1.3 1.4
Leveraging Existing User Skills . Augmenting User Skills . . . . . Contributions . . . . . . . . . . . Organization of the Dissertation
2 Background Literature
2.1 Single Display Groupware . . . . 2.1.1 Mouse Based PC Systems 2.1.2 PDA Based Systems . . . 2.1.3 Augmented Surfaces . . . 2.1.4 Control Rooms . . . . . . 2.2 Privacy and Awareness . . . . . . 2.2.1 Widgets . . . . . . . . . . 2.2.2 Mechanisms . . . . . . . . 2.2.3 Tradeo s . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . . v
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
. . . . . . . . . . . . .
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
3.1 Motivation . . . . . . . . . . . . . . . . . . . . . 3.1.1 Motivation for Single Display Groupware 3.1.2 Problems with Single Display Groupware 3.2 Concept . . . . . . . . . . . . . . . . . . . . . . . 3.3 Application Scenarios . . . . . . . . . . . . . . . 3.3.1 Privacy on the Desktop . . . . . . . . . . 3.3.2 Privacy on the Whiteboard . . . . . . . . 3.3.3 Control Rooms . . . . . . . . . . . . . . . 3.3.4 Competitive and Cooperative Gaming . . 3.3.5 A Fantastical Vision of the Future . . . .
4 Implementation
4.1 Hardware . . . . . . . . . . . . . . . 4.1.1 The Input Subsystem . . . . 4.1.2 The Output Subsystem . . . 4.2 Software . . . . . . . . . . . . . . . . 4.2.1 Technologies . . . . . . . . . 4.2.2 Task and Interface . . . . . . 4.2.3 Versions . . . . . . . . . . . . 4.2.4 Data Input and Data Output
5 Experiment
. . . . . . . .
. . . . . . . .
5.1 Overview . . . . . . . . . . . . . . . . . 5.2 Method . . . . . . . . . . . . . . . . . . 5.2.1 Participants . . . . . . . . . . . . 5.2.2 Sample Size . . . . . . . . . . . . 5.2.3 Software and Hardware Systems 5.2.4 Experimental Task . . . . . . . . 5.2.5 Experimental Design . . . . . . . 5.2.6 Data Analysis . . . . . . . . . . . 5.3 Results . . . . . . . . . . . . . . . . . . . vi
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . .
13
13 13 14 17 18 18 19 21 23 25
28
28 29 29 35 35 35 36 38
40
40 40 40 41 42 42 43 46 48
5.3.1 Preference . . . . . . . 5.3.2 Collaborative Strategy 5.3.3 User Behaviour . . . . 5.4 Discussion . . . . . . . . . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
48 49 51 54
6 Conclusions
56
A G-LEGO Input and Output Files
59
B Experiment Documents
62
6.1 Contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2 Future Directions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3 Final Thought . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58 A.1 Sample Instruction Sequence Input File . . . . . . . . . . . . . . . . . . . . . 60 A.2 Sample Log Output File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 B.1 B.2 B.3 B.4 B.5 B.6
Pre-Session Questionnaires Post-Session Questionnaires G-LEGO Tutorial . . . . . . Consent Form . . . . . . . . Information Sheet . . . . . Colour Blindness Test . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Bibliography
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
63 64 66 68 69 70
72
vii
List of Tables 4.1 Description of data collected in log les. . . . . . . . . . . . . . . . . . . . . . 39 5.1 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
viii
List of Figures 3.1 3.2 3.3 3.4 3.5 3.6 3.7
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. . . . . 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 o ensive player paths visible. . . . . . . . .
14 16 18 20 22 24 25
Principle components of a CRT monitor. . . . . . . . . . . . . . . . . . . . . . Con guration 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 connector on synch-doubling emitter and CrystalEyes wired glasses. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.7 Adapter cable used for attaching two pairs of wired CrystalEyes glasses to a synch-doubling emitter. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.8 Screenshot of G-LEGO prototype system. . . . . . . . . . . . . . . . . . . . .
30 31 32 33 34
5.1 5.2 5.3 5.4 5.5 5.6
41 46 47 49 50 51
4.1 4.2 4.3 4.4 4.5 4.6
Participant requirements for independent variables being controlled. . . . . . Video capture of two participants in the experiment. . . . . . . . . . . . . . . Layout of the experimental setting. . . . . . . . . . . . . . . . . . . . . . . . . User experience with private and public version. . . . . . . . . . . . . . . . . User response to private instructions, private menus, and private cursors. . . Percentage of time each pair spent looking at the same instruction sequence. ix
34 35 37
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 re ect 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, nancial analysis, Barbie dressup, and numerous other tasks. With computers solving many di erent problems in many di erent domains, it has become apparent that traditional computer interaction paradigms are not suitable for the completion of all tasks. A nancial analyst may be most comfortable sitting at a desk with a keyboard, mouse, and monitor, but this setup may not be most suitable for a girl playing virtual Barbie. This reality has prompted investigation into the di erent ways users can interact with computers, and the di erent ways computers can t into the lives of users. This work has already had an impact on the computer marketplace, with the surge in popularity of Palm Pilot style devices, console gaming systems, integrated cellphone/organizer devices, \smart appliances," tablet computing devices, and other computing devices with novel interaction paradigms suitable to certain speci c tasks. This thesis will present a new interaction technique for computers that allows them to support small 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 allows users to draw upon experience 1
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 re ned 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 computer 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 well-practised and e ective 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 eciency at which people work. Similarly, working in close proximity of collaborators, but in di erent workspaces, can likewise decrease the eciency at which people work.
1.2 Augmenting User Skills Another trend in human-computer interaction research is to develop computer 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 computer. For example, a portable computer could display the current time and position of the device to the user. Time measurement and position measurement are two things that computer systems can do much 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 still, however, a potentially useful technique for providing usable and useful computer interfaces. 2
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 employing a shared display environment, while providing 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 all see the same content on the display. Our technique \augments" the shared display, making it possible to display speci c private content to individual users. The technique can be used in several ways. First, di erent users can see entirely di erent content on the shared display. Second, \private areas" can be designated on the display. Within these areas each user sees di erent content. Third, public content and private content can arbitrarily be mixed on the display. This makes it possible for private information to co-exist within the context of public information.
1.4 Organization of the Dissertation This dissertation is organized into ve main chapters: Background Literature, Single Display Privacyware, Implementation, Experiment, and Conclusions. Chapter 2, Background Literature, discusses research in the area of SDG that holds relevance to the issues discussed in this thesis. Chapter 3, Single Display Privacyware, provides a discussion 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 bene t from the use of SDP systems. Chapter 4, Implementation, describes the hardware and software components of a prototype SDP system. Chapter 5, Experiment, discusses 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 signi cance of SDP as a new area of research.
3
Chapter 2
Background Literature In this thesis we are interested in a broad range of issues related to supporting collaborative computer-supported work. We are particularly interested in the use of di erent types of technology to address interface issues in di erent environments, especially that of Single Display Groupware. As such, we will analyze research related to di erent 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 di erent technologies. Research related to these issues, such as privacy and awareness, will also be discussed.
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 rst 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 signi cant interest in recent years. Researchers have been investigating SDG systems in di erent domains, such as education and business, and in relation to di erent categories of tasks, such as construction tasks and problem solving tasks. Since the SDG model does not dictate interaction styles, this is also of interest to researchers. Di erent types of interaction styles, such as mouse, PDA (Personal Digital Assistant), and tactile tabletop systems, are all being examined. This section will summarize recent research in SDG, as categorized by interaction style. 4
2.1.1 Mouse Based PC Systems Mouse based PC systems, usually consisting of a mouse, a keyboard, and a monitor, are the most widely used and recognized computer systems. Not only are users accustomed to interactions with these systems, but software companies focus their development e orts 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 SDG functionality, such as supporting multiple simultaneous input devices, which does not generally exist 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 framework in which multiple users could edit text documents and perform simple drawing tasks. Issues raised by the use of MMM include that of screen real-estate, in which information widgets for di erent users interfere with one another because of limited screen space. This issue has yet to be adequately addressed, and remains an important topic of research. Another contribution in this area is COLT [4, 5], 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 implementation 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 seamlessly 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]. All the toolkits mentioned in this section focus on supporting multiple input devices with a shared display. Other types of toolkits are possible for SDG development, but supporting input from multiple users is perceived as a large problem by researchers, and therefore has been the center of focus for early SDG research.
5
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 real-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 pairs 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 di erent turn-taking protocols [16, 14]. Additional research in this area found that providing pairs of users with two independent mice, as opposed to one mouse, signi cantly 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 e ectiveness 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 all, PDAs are exible devices. Custom software can be written so that the PDA can perform a wide variety of functions, from cursor control to image manipulation. Second, like mice, PDAs are inherently personal. It is uncommon 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 associated with the completion of tasks are visible to all participants, and hence are easily and naturally understood by 6
group members. This does not necessarily hold when users are manipulating devices such as mice and keyboards within a virtual 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 dicult for individual members to associate actions with corresponding group members. Rekimoto has addressed the problem caused by the use of remote manipulation devices by developing a system employing a novel pick-and-drop direct manipulation interaction metaphor applied to a system comprised of personal 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 \picking" the information by tapping it with a special stylus and \dropping" it onto the shared screen with a similar tapping action. The \pick-and-drop" 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 system 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 from 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 e ort involving the development of both toolkits for use by developers [23, 22], and applications for use by end users [24, 21]. 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 7
on the PC, making it available on a PDA. This project helps identify the role that PDAs can play in relation to shared screens.
2.1.3 Augmented Surfaces Tabletops and whiteboards a ord group interactions over a shared workspace. It is very natural for a group of people to gather around a table to analyze owcharts, 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 \augment" 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 di erent approaches researchers have taken towards augmenting the abilities of tabletops and whiteboards.
InfoTable and InfoWall Rekimoto has contributed to SDG research by introducing his technique of augmenting normal surfaces with digital content [27]. His augmented tabletop and wall projection system 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 ll 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, les, 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 Urp, developed by Underkoer [35]. Urp is an example of a system that narrows 8
the gap between the virtual and the physical. The system provides urban planners with a medium in which they can test the environmental e ects of di erent building layouts. The system is based on tangible media, all the tools used are physical objects which are placed or turned to yield desired results, just as in the physical world. Picking up and moving structures produce real-time changes in a simulation of air ow, as well as the position of shadows and re ections. A camera monitors the positions of the buildings and tools and a computer calculates the changes in air ow and lighting. The e ects are visualized through images projected on the tabletop by a projector. With this tool urban planners can easily experiment with di erent building arrangements. This is another example of a system that uses augmentation of physical surfaces to provide a powerful computing system 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 di erence is that, with a vertical rather than horizontal mounting, whiteboards provide a di erent kind of access to users. It is more dicult 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 di erent users. Early whiteboard related work includes the ClearBoard research of Ishii [18], and the development of the Tivoli system, discussed by Pederson [25]. More recent work that focuses speci cally on whiteboards as groupware systems is that of Mark [19, 20], who has analyzed group interactions around the DOLPHIN whiteboard system.
2.1.4 Control Rooms 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 workers who must process huge amounts of data being sent from di erent parts of the system being analyzed. Typically, the labour is divided among workers in order to accomodate the large amounts of data. Workers must still coordinate their work, however, and this is where a large shared screen displaying an overview of the system is useful. While the workers require an overview of the system, detailed information is also needed for individual workers performing speci c tasks. This 9
information is often di erent for di erent 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 speci c 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. Awareness, 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 di erent. 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 problems faced in SDG systems and distributed systems are di erent 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 signi cant 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 good discussion of awareness widgets is o ered by Gutwin and Greenberg [10], and Gutwin and Roseman[11]. Among the speci c awareness widgets discussed in the papers are telepointers, which indicate mouse positions of remote users, and multi-user scrollbars, which indicate scrolling position of remote users. Also discussed are a variety of di erent workspace views, which help users understand what part of the workspace remote users are working in. Other widget research that has been performed for single user systems can also have relevance for multi-user systems. Research on transparent tools, by Bier [3], Cox [6], and 10
Harrison [12], all deal with transparency and how it can be used in conjunction with tools and display layers. The use of transparency can have a deep impact on user awareness. Other widget research to consider is that of Bederson [1]. He investigated the concept of local tools, tools that can be picked up o 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 fall under a number of broad categories. First, an \informative" mechanism requires that users actively transmit awareness information to other users. Second, a \role restrictive" mechanism requires that individual users be categorized in some manner, and that speci c 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 feedback" mechanism, is superior. \Shared feedback" mechanisms cause awareness information to be collected passively from the environment. This information is then displayed to all users as part of the workspace.
2.2.3 Tradeo s There are often tradeo s to be made when deciding on how much awareness information is to be made available in a groupware application. Gutwin discusses these tradeo s [10], as well as other issues associated with awareness in groupware systems [9, 11]. 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 sacri ced for increased group awareness, or vice versa. An example tradeo given in the paper concerns workspace navigation, whether individual users are able to freely explore the workspace, independent of other users. Allowing this activity favours individual user control, while forcing users to work in the same space favours group awareness.
11
2.3 Privacy and Awareness in Single Display Groupware Systems 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 those technologies. Analyses into the requirements for successful SDG systems have largely been neglected. Nevertheless, several SDG research e orts have tangentially dealt with privacy issues. Rekimoto's pick-and-drop implementation, already described in Section 2.1.2, is probably the most intriguing SDG system supporting privacy. While intended to support intuitive physical manipulation of data by users, a side e ect 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 separation 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 their relationship. Other systems, both similar to that of Rekimoto's, are those of Myers [24] and Greenberg [8]. Both support di erent degrees of privacy by displaying information on a PDA. Greenberg's system is speci cally designed for privacy support, and allows 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 less 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 proposed by other researchers. The approach of this research, that of displaying private information within the public context of the shared display, has been brie y discussed in a previous paper [29], with a more in-depth discussion provided by [31].
12
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 rst 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 de ned and later re ned by Stewart [32, 33], SDG requires a shared user interface and provides shared feedback to users. It also couples navigation between users. The result of this de nition 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 people work collaboratively in the physical world, shared artifacts are frequently used. Skills that have been developed in the physical world can more easily be translated to work in the digital realm if shared artifacts are used there as well, instead 13
private
input
user 1 Monitor private input user 2 public output
private
input
user n
Figure 3.1: Input and output channels of Single Display Groupware systems. of duplicates of an artifact (di erent screens). These skills can include the ability to develop a shared understanding of the task by the users, and the ability to coordinate actions performed by the users. While de nitive proof of the advantages of using SDG 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 outcomes 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 o er. 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. Shrinking widgets has the desired e ect of freeing up space, but can result in widgets 14
that are dicult to see. Eliminating unnecessary widgets can also work, but it is not always possible 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 all use the same toolbar. This method can be very successful 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 users. With di erent users selecting di erent tools on a toolbar, or simultaneously selecting di erent items from a menu, the di erent paths of users can 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 becomes more dicult 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 contrast to distributed groupware systems, where awareness information is by default scarce, and must be provided explicitly. Existing privacy techniques are able to combat the problem of awareness overload. Several SDP systems exist [8, 24, 26], mostly employing private networked PDAs, that use remote private displays 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 \pollute" 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 makes it necessary for users to coordinate several displays, possibly creating signi cant cognitive overhead. It also makes it necessary for each user to possess a suitable PDA, and for these PDAs to be networked with the shared display. An alternative to the PDA approach to privacy would be for all information, whether meant for group awareness or personal feedback, to be displayed on the shared display. 15
The Privacy 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 from its context. A \you are here" arrow is useless if there is no context provided (see Figure 3.2). The Context Granville
The information removed from its context
Burrard
You Are Here
29th Ave.
1st Ave.
4th Street
Alma
Figure 3.2: The \You are here" arrow is useless once removed from 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 might want to view in a public context while keeping that information private. Cursors, for example, might be kept private to reduce screen clutter, but must exist within a public context or be rendered useless. Information used by workers in industrial control rooms is often speci c to each worker, but can be more meaningful 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 bene t 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 would be valuable. 16
3.2 Concept Single Display Privacyware is a class of collaborative computer systems that extends directly from SDG, and is meant to address demonstrated problems with SDG. An SDP system is de ned 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 all users. The private and public channels employ the same 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 all users (see Figure 3.1), SDP adds additional private output channels for each user (see Figure 3.3). This results in additional exibility being added to the SDG model. Most signi cantly, users need not share feedback. While all 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 speci c user. A result of this, which also loosens the SDG de nition, is that users of SDP systems are not restricted to coupled 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 all users was made private. Keeping navigation public would force coupled navigation, which would preserve some hypothesized bene ts of SDG systems. The SDP label does not imply any particular implementation of private and public channels. The only requirement in terms 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 speci c users. The means of achieving privacy is not speci ed. Systems might employ technologies such as shutter glasses, polarization lters, head-mounted displays, or any other system that achieves the same e ect.
17
private user 1
private
input output Monitor
private input user 2
private output
private
public output
output
private
input
user n
Figure 3.3: Input and output channels of Single Display Privacyware systems.
3.3 Application Scenarios One way of highlighting the bene ts of SDP systems is to give examples 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 bene ts that might be achieved by adopting SDP systems would most readily 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 real-estate and awareness overload, that have been identi ed by this body of research, can therefore be directly addressed by SDP.
Scenario 1: Garth is an apprentice computer animator at a large animation
rm. He is seated at his desk, struggling with getting the walk of a virtual bug to be just right. Getting frustrated, he calls over to his supervisor, \Iliana, can you help me with this bug? I can't get him to walk right." Iliana comes over and sits down beside Garth. With two users at the computer, the monitor now 18
displays two di erent 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, I'll show you." Accustomed 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 re ected both in the public image of the bug, and in his private animation timeline and feedback widgets. Iliana nishes her changes, and Garth then continues along, making more changes to the animation. Iliana comments on Garth's changes, and works alongside him, guiding his actions. Finally she is satisi ed with his approach, commenting \Yes, 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. Di erent users of computer systems have di erent 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 speci c 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 many of them customize the interfaces of their art packages, and become very ecient at operating those customized interfaces. Being forced to adapt to someone elses interface might slow a user down, or discourage them from getting involved in the rst place. This bene t of having privacy support is in addition to the bene ts that might be gained by reducing screen clutter and removing unwanted awareness information.
3.3.2 Privacy on the Whiteboard Digital whiteboards are of growing interest to SDG researchers, mostly because they naturally support group interactions. Digital whiteboards are also of interest because their non-digital counterparts are already widely used in meeting rooms and schools. This scenario describes a potential 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 surface" whiteboard, with added functionality provided by the digital nature and privacy support. 19
Scenario 2: Garth is an upcoming talent at a big architectural rm, and is
making a presentation to some clients and partners in the rm (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 oce tower being designed for the clients. As he talks, he uses his stylus to highlight and point out di erent 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 oce tower. He pulls up his notebook privately on the display and ips through it until he nds 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.
private output
public output
private private output output
Figure 3.4: Private and public information available to participants in a meeting.
20
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 this without bothering other participants, making his notes public only when he has found the appropriate information. Not only is he avoiding distracting 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 rooms 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 has lights showing system status for di erent components of the plant. As Garth and Homer lounge at their desks, one of the lights on the display starts ashing 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 ow information from node to node on the display. From this he is able to tell that the water ow to the problem point is normal. 21
\Water ow is normal Homer, problem must be yours." Homer, with his privacy glasses, sees similar ow information, only for him it is heat ow information. From the information on the display, he is able to determine that the heat ow 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 a ected by the problem. Armed with this information, he performs the operations necessary to avoid a disaster.
Private Information
Public Information
Private Information
Private Information
Private Information
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 ow values adjacent to their corresponding nodes, the two workers may have understood the situation more quickly than if all 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 workers switched from the shared display to their private displays. This might happen if it becomes necessary to perform additional tasks, such as 22
computations or information retrieval, that might not bene t from being shown on the shared screen.
3.3.4 Competitive and Cooperative Gaming In recent years, computer gaming has grown immensely in popularity all over the world. Multiplayer gaming is one aspect of games, 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 scenario considers a possible SDP system in use in a console gaming environment.
Scenario 4: Garth and Saddam are two feisty teenagers with a serious computer
gaming rivalry. One afternoon, Saddam arrives at Garth's house, they plug their console game system into the TV, put on their headsets, and insert their favourite American football game cartridge. 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 Saddam will not predict the aggressive and sneaky play. Saddam, shown a private set of o ensive play choices, chooses a simple passing play. Both Garth and Saddam see a public view of the playing eld with the players ready and lined up. Saddam sees the public view augmented 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 eld, but his private information shows the the paths his defensive players will take (see Figure 3.6). Among 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 pass. Garth instructs his safety to blast through Saddam's defensive line, leap through the air, and tackle Saddam's quarterback. Garth jumps in the air screaming, taunting Saddam in his glorious moment of victory. This scenario depicts two players in a very popular gaming environment, multiple players playing on a gaming console on a shared display. Present day console systems are typical SDG systems. They display all information publicly to all players. This can have an adverse a ect on gameplay if there is any element of subterfuge intended in the gameplay. 23
Figure 3.6: Screenshot of football game with defensive player paths visible. The system used in the scenario, however, uses privacy in two ways to support the secret aspects of the game, while maintaining the emotion of a shared gaming experience. First, the system can display two entirely di erent images to the two players. In the play selection phase, the two players in the scenario must perform two di erent operations. One picks a defensive play, the other picks an o ensive play. These picks are private, and knowledge of an opponent's pick would have a large e ect on strategy. The SDP system in the scenario makes the play selection phase of the game truly 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 action. In this scenario, each player sees the plan that will be carried out by their team, and both players share a view of the drama being acted out in the game.
24
Figure 3.7: Screenshot of football game with o ensive player paths visible.
3.3.5 A Fantastical Vision of the Future The scenarios presented previously describe SDP applications that could be implemented relatively easily using today's technology. It can also be useful, however, to consider more fanciful scenarios that might be implemented in the future when more advanced technologies and accompanying infrastructure are available.
Scenario 5: This scenario also involves Garth, who is now a weary business
traveller on his way from Vancouver to a meeting in Boston. He arrives at Vancouver International Airport and enters the terminal building. Upon entering the building the rst thing he sees is the large display with ight information. In large letters, lling the entire screen, it says \Hello Garth. Your ight leaves in 20 minutes from gate 23A. In the meantime, they have chocolate cucumber muns at the co ee shop to your left." Garth is now up to date on his ight information, and is on track to getting his favourite snack, chocolate cucumber 25
muns. He sees to his left a co ee shop. The sign indeed says \yes we have chocolate cucumber muns." After enjoying his snack he boards the plane. During the ight, 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 ight 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 o and arrives at his meeting safely. This scenario described several futuristic SDP applications that function 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 speci c for him. The system knows his ight 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 same displays must simultaneously show very di erent information for di erent observers. On the plane, SDP makes another appearance with the in ight 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 lm 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 nd his rental car quickly, quite possibly while other customers of the rental agency are being directed to their own cars, in di erent locations. What makes the examples in the scenario so interesting is that they highlight the usefulness of making private information contextually available in every aspect of our public world. While all 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 mun also contained implicit information detailing where the mun 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 ights Garth had no interest in were hidden to him, and 26
uninteresting specials at the co ee shop were not advertised to him. A large amount of the \cognitive garbage" normally associated with everyday life was ltered from view. The de nition of what constitutes \cognitive garbage" would, of course, need to be determined somehow, which raises questions of how much control a person has over what is visible and what is hidden. While this scenario possibly demonstrates the ultimate convergence of SDP with everyday life, certainly faces many technical obstacles. The problem of providing privacy for an arbitrary number 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 all technologies that might play a role in a solution. While such technologies are currently technologically infeasible as well as ethically questionable, it is possible that solutions to these problems will be arrived at in the future.
27
Chapter 4
Implementation A prototype system, 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 computer 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 necessary 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 G-LEGO system can be split into two subsystems, the input subsystem, and the output subsystem. The input subsystem consists of 2 USB mice, a USB hub, and a USB input on the computer. These are o the shelf components. The output subsystem consists of a standard monitor (1280x1024 @ 75Hz), a StereoGraphics synchdoubling emitter, two pairs of Stereographics wired CrystalEyes glasses, and an adapter to connect the two pairs of glasses to the synch-doubling emitter. Both pairs of CrystalEyes glasses and the adapter were customized for use with G-LEGO. All customization was performed by the author as a part of this thesis, with electrical engineering advice provided by Colin Swindells.
28
4.1.1 The Input Subsystem The input subsystem of G-LEGO provides each of two users with a mouse to interact with the computer. As with most Single Display Groupware, G-LEGO makes it possible for both users to interact simultaneously and independently with the system. The USB bus collects position displacement information from both mice 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. G-LEGO deactivates and hides the hardware cursor, and draws two software cursors 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 mice only works with particular con gurations 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 summary of CRT mechanics. The internals of a CRT (cathode ray tube) monitor include an electron \gun" 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 accelerates electrons which are targeted at speci c 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 line, it returns to the rst pixel in the rst scan line and starts all 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 \frame" in an animation. Between screen refreshes the contents of the video memory can change. What is drawn in each successive screen refresh is often di erent from the previous screen refresh. Given the 29
Axiometric View
Front View
Scan Lines
Electron Gun
Phosphor Surface Phospor Surface
Electron Gun
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 refresh" and \frame" described in this section is key in the functioning of the G-LEGO hardware.
The Synch-Doubling Emitter and Dongle The synch-doubling emitter and accompanying dongle serve to regulate the operation of the monitor as well as the CrystalEyes glasses. The dongle attaches in series between the monitor'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 activated, the synch-doubling emitter uses the dongle 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 (from 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 e ects is that alternate refresh frames show either the top or bottom half of the original display image. Every odd-numbered screen refresh shows a stretched version of the top half 30
Synch-Doubling Emitter
Monitor
Dongle
CPU Case
Figure 4.2: Con guration of the synch-doubling emitter and dongle. of the display image, while every even screen refresh shows a stretched version of the bottom half of the display image.
The CrystalEyes Glasses Two pairs of CrystalEyes glasses are used in conjunction with the synch-doubling emitter. Each pair of CrystalEyes 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 normally 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 lens is opaque and the other is transparent (see Figure 4.3). Any one refresh frame is viewed by either the left eye or right eye of a user. Consequently, each eye will see either every odd numbered refresh frame, or every even numbered refresh frame. If the display image is drawn such that even and odd numbered refresh frames show a slightly di erent perspective 31
of the same scene, adjusted appropriately for each eye, the user will perceive a stereo image of that scene.
Figure 4.3: Shuttering sequence of CrystalEyes glasses before customization. The G-LEGO prototype makes use of the shuttering capability of the CrystalEyes, but alters the shuttering operation in order to provide privacy for multiple users, rather than stereographic viewing for one user. First, two pairs of CrystalEyes were attached 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 di erent 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 numbered refresh frames. When two users wear these two pairs of CrystalEyes, they will be looking at di erent refresh frames. Images drawn on odd numbered 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 all refresh frames. The customization necessary to produce the desired shuttering behaviour in the CrystalEyes glasses was achieved by making minor modi cations to the circuit board controlling the glasses. The circuit board is accessed by removing the front plastic face of the CrystalEyes. Upon opening the glasses, the circuit board is visible. On the front of the board 32
Figure 4.4: Shuttering sequence of CrystalEyes glasses after customization. are three conductive pads; 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 lens1 .
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 pulses to wireless CrystalEyes (as the \emitter" name implies), and not to work in harmony with two pairs of wired CrystalEyes glasses. Wireless CrystalEyes could not be used for the system because they are dicult to customize. A solution was required that would allow the synch-doubling emitter to work with two pairs of wired CrystalEyes glasses. What the synch-doubling emitter does o er to help support wired CrystalEyes is a \feature connector" that outputs a variety of signals from the synch-doubling emitter (see Figure 4.6 (a)). These signals, along with an external power source, are all that the wired CrystalEyes need as input (see Figure 4.6 (b)). With an appropriate custom adapter cable 1 CrystalEyes speci cations and customization instructions provided by Tim Crane, courtesy of StereoGraphics.
33
Front of Board
Back of Board Wired for Right Eye
Back of Board Wire dfor Left Eye
Back of Board
Added connection
Left Eye
Added connection
cut trace
Right Eye
cut trace
Common
(a) Normal board
(b) Two versions of customized board
Figure 4.5: Circuit board in CrystalEyes wired glasses. and a Y-adapter (available from StereoGraphics), two pairs of wired CrystalEyes can run connected to a synch-doubling emitter. The construction of the adapter cable, including all pin connections, is shown in Figure 4.7. It should be noted that the power supply may need a voltage limiter in order to provide 5 VDC at 10 mA. A higher voltage may damage the CrystalEyes glasses. 8 pin mini-DIN, solder side
3-pin mini-DIN receptacle, face side Pin #
8
7
5
6
4
2
3
1
1 2 3 4 5 6 7 8
Function Left/Right out Pseudo select Master pulse out Remote bypass in NC NC NC Ground
(a) Feature Connector
3
2
Pin #
Function
1 2 3
+5 VDC Ground Stereo Sync.
1
(b) CrystalEyes Wired Connector
Figure 4.6: Pin layout of feature connector on synch-doubling emitter and CrystalEyes wired glasses.
34
3 Pin Mini-DIN (VESA) To "Y" Cable 8 Pin Mini-DIN (feature) 3 1 8 7 6 5 4 3 2 1
2
Female (solder side)
Male (solder side) 120 VAC Power Supply Input 120 VAC Output 5 VDC@10mA
Description Left/Right Signal Ground +5V Ground
From Pins 1 8 NC NC
To Pins 3 2 1 2
Figure 4.7: Adapter cable used for 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 prede ned 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 all 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 sub-API from 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 prede ned LEGO-like structures out of blocks. It was thought that this would be a suitable task, as SDG literature 35
often cites construction tasks as appropriate for collaborative computer environments [5, 15, 32]. LEGO is also an activity that is well understood 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 splits 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 users build structures. Both users 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 over 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 from 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. Di erent 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 \block" and \edit" 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 placed. 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 versions of the G-LEGO system were developed for use in user studies. The three versions are known as the \private version," the \public version," and the \practise version." The private version 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 his or her own cursor. When users are placing blocks or moving blocks around, those blocks are viewable to both users, but the cursor performing the actions are private. Secondly, contextual menus are private. When one user pops up a menu over the workspace, 36
Figure 4.8: Screenshot of G-LEGO prototype system. the other user sees the workspace as it was before, with no menu superimposed. Thirdly, instructions are private. The entire instructions area is independent for the two users. The two users can, if they desire, look at two di erent instruction sequences for two di erent structures. They can also, of course, look at the same instruction sequences, if they so desire. The public version of G-LEGO is the same as the private version except that it acts as a normal SDG system. All information is visible to both users at all times; there is no private information. Cursors are visible to both users, as are menus, although one user is unable to interact with the other user's menus. Also, instructions are public. A result of this is 37
that both the users must look at the same instruction sequence. If one user changes which instruction sequence is shown, this change is re ected in the other user's view as well. 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 di erence in the practise version is that it has only one instruction sequence. If a user clicks on the buttons to select a di erent 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 All three versions of G-LEGO read input les that specify the three instruction sequences shown to the users. Three text les are read by G-LEGO, each le specifying steps for one instruction sequence. Each le contains information for each block in each step, specifying position, orientation, and colour, for each block. Two di erent instruction sets of 3 input les were constructed for later use in a user study. Each input le in each set contained the instruction sequence specifying how one structure was to be built. A portion of an example input le is shown in Appendix A.1. The private and public versions of G-LEGO also produce output les containing information outlining user behaviour. Two output les are produced, one for each user. Each le is tagged with a timecode, an identi er to di erentiate between the two users, as well as information specifying which version of G-LEGO produced the output. The di erent kinds of behaviour information gathered is summarized in Table 4.1. This logging capability was added to G-LEGO for use in user studies. An example log is shown in Appendix A.2.
38
Table 4.1: Description of data collected in log les. Description of Data Value indicating from which of the two users this le originates. Possible values are 0 and 1. Date Timestamp. Values from left to right are: years, months, days, hours, minutes, seconds. Synched The amount of time (seconds) the two users spent looking at the same instruction sequence. Not Synched The amount of time (seconds) the two users spent looking at di erent 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 colour 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 up the place menu. Data Label User Index
39
Chapter 5
Experiment 5.1 Overview The G-LEGO prototype system was evaluated in an exploratory user study. Two versions of the G-LEGO prototype system were used. 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 lled out pre and post experiment questionnaires, computer logs recorded user actions within the system, and videotapes were made of interactions between users. Observational and statistical results were obtained from the di erent data sources.
5.2 Method 5.2.1 Participants Sixteen employees of Electronic Arts Canada (EAC) were recruited by e-mail sent to all 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 experiment. Second, it was a worry that exposing inexperienced computer users to novel technology might intimidate them, giving rise to results that would 40
be coloured by this intimidation. EAC employees are generally comfortable with computer technology, as revealed by the pre-session questionnaire, hopefully reducing the intimidation factor.
5.2.2 Sample Size Two within-subjects variables, and one between-subjects variable, were identi ed for investigation in this experiment. The within-subjects variables were the G-LEGO version presented and the instruction set attempted. Both of these variables were counterbalanced to reduce order and learning e ects. 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). All 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
Gender Male
Private
Public Female
Set A
Set B
Male Public
Private Female Male
Private Set B
Public Female
Set A
Male Public
Private Female
Figure 5.1: Participant requirements for independent variables being controlled. All 16 participants (8 pairs) completed the experiment successfully. Data from all the participants was analyzed. There were no signi cant problems due to equipment failure or data corruption. 41
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 version, the public version, and the private version. Two di erent sets of instruction sequences were also used.
5.2.4 Experimental Task Background As the G-LEGO prototype was used as the investigation tool in the experiment, the experimental task was derived from the functioning of that system. The G-LEGO system gives pairs of users the task of constructing three LEGO-like structures according to instructions shown on the screen. The speci c 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 di erent task, such as a spreadsheet, would require domain-speci c 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 intuitively 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 Task 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 system indicating success or failure at any point during the experiment. Participants had to judge for themselves whether or not they were placing blocks correctly. Participants were told that they were to organize how they worked. They could work cooperatively or independently as they desired. The relatively unstructured task and unspeci ed work relationship was meant to encourage natural interactions between the two participants. 42
It was hoped that the participants would structure their approach according to how they naturally wanted to work, rather than according to what the guidelines of the experiment allowed.
5.2.5 Experimental Design Independent Variables Game version To determine advantages and disadvantages to the use of systems supporting private information and public information as compared to systems only supporting public information, the use of the two versions of the G-LEGO system was identi ed as a within-subjects variable. This variable was counterbalanced between di erent subject pairs in order to reduce the e ects based on the order in which the versions were encountered. Possible values: fprivate version, public versiong
Instruction set As participants worked on two versions of the system (version order was withinsubjects), it was also desirable to eliminate learning e ects across conditions. Learning e ects were minimized through the use of two di erent instruction sets, each set with three instruction sequences. Each pair of users used a di erent instruction set with either of the two versions of the software. This variable was also counterbalanced between di erent subject pairs. Possible values: fInstruction Set A, Instruction Set Bg
Gender In an attempt to identify any gender e ects, gender was also considered. Possible values: fmale, femaleg The participants completed trials using both versions of the system (within subjects factor), with both instruction sets (within subjects factor). Also, considering gender (between subjects factor), the experiment was a 2 x 2 x 2 mixed design.
43
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. All 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 from each instruction set be of equal complexity of construction. One method used to keep complexity of the di erent structures similar was to specify the number of blocks added to the structure between each step of the sequence. For example, the rst step of the rst 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 rst two instruction sequences 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. Step # Number of Blocks Added 1 4 2 4 3 4 4 3 5 2 6 2 TOTAL: 19 The third structure of each instruction set was meant to be more dicult to build than the rst 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 fth step. This trick required that some previously placed blocks be removed before a new block could be placed. The third structure was made more dicult in order to challenge participants. Providing challenging instruction sets to users potentially results in more interesting observational results.
44
Table 5.2: Number of blocks added in each step for instruction sequence 3, for both instruction set A and B. Step # Number of Blocks Added 1 5 2 4 3 4 4 3 5 3 6 3 TOTAL: 22
Pilot Study Several informal pilot studies were performed using volunteers. This was done in order to determine if the instruction sets were suciently 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 Tools and Libraries department of Electronic 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 computer monitor was placed in the center of the desk, with the two mice placed 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 equal 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 availability, as employees at EAC tend to be very busy. The timeline for a typical session is shown in Table 5.3.
45
Figure 5.2: Video capture of two participants in the experiment.
5.2.6 Data Analysis Data Collection Techniques Three methods of data collection were used: questionnaires, videotapes, and computer logs. Questionnaires were administered both pre-session and post-session. Videotapes recorded user behaviour during the sessions. Computer logs recorded user actions within the GLEGO system. Refer to Appendix B.1 and Appendix B.2 for the pre-session and post-session questionnaires, and Appendix A.2 for an example log le.
Dependent Variables Preference Preference was measured using post-session questionnaires which were administered after both trials. Opinions regarding the private and public versions of the software, as well as particular features of the private version, were collected. Preference was determined by asking participants how much they liked a particular version or feature, 46
CPU Case
Monitor
Mouse
Keyboard
Camera
Chair Desk
Figure 5.3: Layout of the experimental setting. using a ve 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 comfortable) to 5 (very uncomfortable).
Collaborative Strategy 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 same instruction sequence, and how much time they were looking at di erent instruction sequences. These logs, along with observations from the videotapes, were used to determine collaborative strategies.
User Behaviour As the experiment was largely exploratory, it was thought that there might be dependent variables of interest that could not be identi ed prior to the experiment. These variables were placed under the general category of \user behaviour." Di erent aspects of user behaviour were collected using all three data collection techniques, questionnaires, videotapes, and computer logs. 47
Item # 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.
Table 5.3: Example experimental schedule. Activity Time (minutes) Participants Arrive 4 General Introduction 3 Information and Consent Forms 3 Colour Blindness Test 2 Background Questionnaire 4 Introduction to Training Condition 3 Training Conditions (once for each participant) 4 + 4 Introduction to First Experimental Condition 3 First Experimental Condition 10 Short Break 2 Introduction to Second Experimental Condition 3 Second Experimental Condition 10 Post-session Questionnaire 5 TOTAL: 60
5.3 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 speci c statements that they appreciated speci c features of the private condition, such as: \I prefer public, but we should have been allowed to look at di erent instructions." \I prefer the public as it allows more coordinat[ion], but the overlapping menus have to be resolved to prevent it from frustrating." \Public, except for the menus." Quantitative results from the post-session questionnaire, analyzed with a 2 related samples Wilcoxan test, indicated no signi cant di erence in comfort level between the private version and public version (Z = ,0:962; ns). These results measured user comfort on a ve 48
point scale (1=Very comfortable, 5=Very frustrated). The average score given by participants for the public version was 2.25, while 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.
Figure 5.4: User experience with private and public version (1 = Very comfortable, 5 = Very frustrated). The post-session questionnaire also asked participants to rank di erent features of the private version on a scale of one to ve (1=I liked it a lot, 5=I disliked it a lot). The data was analyzed using a one-sample Kolmogorov-Smirnov non-parametric test, and did not produce statistically signi cant results for either private menus (Z=1.185, p=ns) or private cursors (Z=0.871, p=ns). The responses concerning private instructions was marginally signi cant (Z=1.300, p=0.068). When rated on a scale from 1 to 5, as shown in Figure 5.5, participants appear to have had a fairly strong liking towards instructions being private and menus being private. The reaction towards private cursors was mixed.
5.3.2 Collaborative Strategy While 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 allow a mix of 49
Figure 5.5: User response to private instructions, private menus, and private cursors (1 = I liked it a lot, 5 = I disliked it a lot). collaborative and independent strategies. This was done by allowing users to look at di erent instruction sequences, which supports independent work, or the same instruction sequence, which supports collaborative work. Log les recorded the amount of time participants spent in these two states, giving an indication of collaborative strategies used in the trials. The data from the log les is summarized in Figure 5.6. Analyzing the data in Figure 5.6 it becomes 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 nal two pairs employed a hybrid strategy, sometimes looking at the same instruction sequence, sometimes looking at di erent instruction sequences. These pairs spent approximately 18% and 39% of their time looking at the same instruction set. Comments from the post-session questionnaire serve to reveal some of the reasoning behind the use of hybrid strategies: \Even though we were working on di erent parts we could still proof the other guy's work easily and quickly." 50
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 time because we could both work on di erent 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 di erent 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 insights can be used to suggest possible future directions of investigation.
51
Variation in Preference 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 all three aspects to be private, or all 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 remarks 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 di erence in preferences related 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 version, 6 out of 16 participants scored at least one aspect favourably, while scoring at least one other aspect neutrally or disfavourably. The other 10 participants were consistent in ranking all three aspects either favourably or neutrally/disfavourably.
E ectiveness 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 members of two di erent pairs did have signi cant trouble working in the private condition, but this was because of a basic diculty 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 also had diculty functioning in the public version. 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. 52
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 also 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 e ect was the same for both public and private versions, as users wore the glasses for both versions.
Activity Levels The level of user activity for each pair was found to be marginally signi cant 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 signi cantly higher in the private version (F (1; 7) = 3:668; p = 0:097; r2 = 0:344; power = 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 ecient, 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 signi cant di erence between the private and public versions (F (1; 7) = 2:344; p = ns; r2 = 0:251; power = 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 e ect size but low power of both activity level results indicates that this evaluation should be repeated with a larger sample size to fully explore the e ects on activity level. 53
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 scoring it as a 4 on a scale of 1 to 5 (1 = Very Comfortable, 5 = Very Uncomfortable). The conclusion that participants understood and accepted the system is also validated by the other results of the study. The evidence presented in Section 5.3.3 compares the e ectiveness of interaction of participants in both the private and public conditions. It was found that in general participants were able to function e ectively 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 generalized to cover all 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 di erent users preferred that di erent components 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 from being public to being private, and vice versa. Implementation of this, however, could exacerbate one problem that was identi ed, 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 dicult 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 allowed 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 able to contribute adequately to the work, 54
that user could move on and work on another structure. The experimental 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 exible interface that supports di erent types of collaboration (independent or collaborative). 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 possible directions for future work. These include the necessity to determine the generalizeability of the results, the necessity to investigate customizeability of privacy, the necessity to investigate privacy tagging, and the necessity to investigate the di erences in activity levels between private and public systems.
55
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 systems, however is that they do not provide a mechanism for displaying private information. We saw that existing approaches to allowing private information access with shared displays are e ective, yet have drawbacks of their own. This thesis presented a novel interaction model, Single Display Privacyware, that addresses the problems of privacy support on shared displays, without su ering from some of the drawbacks associated with other solutions. We have also presented a testbed SDP system that facilitates exploration of issues related to this interaction model. The experimental results showed that users were generally able to adapt to the use of an SDP system. This result in itself suggests that it may be valuable to provide users with an SDP alternative to traditional desktop or SDG systems. Observing when users choose SDP systems over traditional SDG systems will give further insight into the impact SDP systems can have in groupware environments. While the experimental results were not conclusive in determining whether or not SDP o ers signi cant advantages over SDG, the results do suggest that SDP could improve computer-supported collaboration. We have identi ed important directions of future investigation into SDP which will provide valuable insight into the role that SDP can play.
56
6.1 Contribution The most signi cant concept we hope to have brought forward is the realization 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 exibility to the interaction experience for all 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 directly to the de nition of Single Display Privacyware as a valuable interaction model for computer supported collaboration.
6.2 Future Directions The research 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 identi ed 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 identi ed by the research are as follows:
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 users, 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 di erences in behaviour when users are able to customize their environment as opposed to when they are unable to customize their environment. 57
Investigate how much users are able to understand what display components are private and what are public, and investigate ways of increasing users' ability to understand what is private and public.
Investigate how users with varying computer experience and di erent backgrounds adapt to the use of a novel interaction paradigm such as SDP.
Determine when and why activity levels di er with Single Display Privacyware systems as compared to Single Display Groupware systems.
Investigate Single Display Privacyware as applied to di erent tasks. The construction
task investigated in this thesis is only one of many possible. Tasks such as mathematical coordination, text editing, or game playing might be investigated.
The eciency 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 speci cally on whether SDP systems support more or less ecient 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 di erent problem domains. Ideally, tools that function on a particular problem in a speci c domain are designed so as to be used comfortably and eciently in that environment. It is thus desirable to address issues particular to a speci c environment when designing tools to be used in that environment. Computer systems are used in many di erent environments, and present di erent sets of design problems in each of these. This research shows that Single Display Privacyware systems can alleviate some of the problems with Single Display Groupware that have not been otherwise addressed by other systems.
58
Appendix A
G-LEGO Input and Output Files This appendix shows a sample input le required by G-LEGO, as well as a sample output le produced by G-LEGO. The input le contains orientation, position, and colour information for each block, in each step of one instruction sequence. Three input les are required for G-LEGO to run, one le for each of the three instruction sequences. The output le contains information identifying game version, user identi ers, timing information, and action counts. Two output les are created each time G-LEGO is run, one le for each player.
59
A.1 Sample Instruction Sequence Input File #NUMBER 1 x 2 y 0 z -3 o 0 c 0 n #Next block x -2 y 0 z -3 o 0 c 2 n #Next block x -3 y 0 z 0 o 1 c 1 n #Next block x -2 y 0 z 3 o 0 c 0 N #NUMBER 2 x 2 y 0 z -3 o 0 c 0 n #Next block x -2 y 0 z -3 o 0 c 2 n #Next block x -3 y 0 z 0 o 1 c 1 n #Next block x -2 y 0 z 3 o 0 c 0 n #NEW 222222222222 x 2 y 0 z 3 o 0
60
A.2 Sample Log Output File Private/A User Index:1 Date: 100 9 16 21 52 35 Synched:30.810000 Not Synched:59.700000 Instruction 0 time: 30.810000 Instruction 1 time: 59.700000 Instruction 2 time: 0.000000 DropBlock: 5 Red: 3 Blue: 2 Purple: 7 Rotate: 12 Delete: 3 Cancel: 1 EditMenu: 8 PlaceMenu: 9
61
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 di erent aspects of the G-LEGO system.
62
B.1 Pre-Session Questionnaire Pre-Experiment Questionnaire Name: _____________________ Gender:
Male
Female
(circle one)
Job Title at EA: ___________________ 1. How often do you use a computer? Never
A few times a month
(circle one) A few times a week
Every day
2. How often do you work with someone else on the same computer? Never
A few times a month
A few times a week
Every day
2. The THREE activities you perform most often on a computer are: E-mail
Spreadsheet
Word Processing
2-D Art
3-D Art
Other
3. In general, how do you feel working by yourself on a computer? Very comfortable 1
2
3
(circle one)
(circle THREE) Programming
(circle one number)
4
Very Frustrated 5
4. In general, how do you feel working with someone else on the same computer? Very comfortable 1
2
3
63
4
(circle one number)
Very frustrated 5
B.2 Post-Session Questionnaire Post-Experiment Questionnaire Name: _____________________
1. How did you feel about the fact you and your partner were working on the same screen? number) Very comfortable 1
2
3
2. How did you feel working in the “public” condition? Very comfortable 1
2
3
3. How did you feel working in the “private” condition? Very comfortable 1
2
3
Very frustrated 5
4
(circle one number) Very frustrated 5
4
(circle one number) Very frustrated 5
4
4. In the “public” condition, how encouraged did you feel to explore new possibilities? number) Very encouraged 1
2
3
2
3
2
3
(circle one number) I disliked it a lot 5
4
7. In the “private” condition, how did you feel about the instructions being private? I liked it a lot 1
2
3
2
3
(circle one number)
I disliked it a lot 5
4
8. In the “private” condition, how did you feel about the cursors being private? I liked it a lot 1
(circle one
Very discouraged 5
4
6. In the “private” condition, how did you feel about the menus being private? I liked it a lot 1
(circle one
Very discouraged 5
4
5. In the “private” condition, how encouraged did you feel to explore new possibilities? number) Very encouraged 1
(circle one
(circle one number) I disliked it a lot 5
4
64
9. What did you like about the “public” condition? _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________
10. What did you dislike about the “public” condition? _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________
11. What did you like about the “private” condition? _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________
12. What did you dislike about the “private” condition? _____________________________________________________________________________________ _____________________________________________________________________________________ _____________________________________________________________________________________
13. Do you have any other comments? _____________________________________________________________________________________ _____________________________________________________________________________________
65
B.3 G-LEGO Tutorial Lego Game Instructions The game you are about to play is a computer version of the popular LEGO brick building system. You will play the game over four trials.
The Warm-Up The first trial is a warm-up to allow you to get used to the controls. This trial will be played alone and it will last 5 minutes.
The Cooperative Trials The next three trials will be played with a partner. In each trial you and your partner will work together with the shared goal of building three LEGO structures as quickly and accurately as possible.
The Controls (refer to screenshot above) The Work Area: The large green square surface on the right is the work area where you place blocks in order to build your structures. The Instructions: On the left you see step-by-step instructions on how to build one of the structures. Each of the steps builds off of the last step. You can see instructions for one structure at a time. If you click one of the three buttons above the instructions you will see a different instruction set for a different structure (in the warm-up there is only one instruction set). All three structures are to be built in the work area.
66
The Rotate Buttons: Pressing either of the two “rotate” buttons at the bottom of the screen rotates the work space as well as the instructions. The Block Button: Pressing the “Block” button puts you in block placing mode. In this mode left-clicking in the work area drops a block. Right clicking brings up a menu with which you can change the properties of the block you will drop. With this menu you can rotate the block 90 degrees, or change it’s colour. The Edit Button: Pressing the “Edit” button puts you in editing mode. In this mode you change the properties of blocks that have already been placed. To do this place your cursor over the point on the green surface above which the block you wish to edit sits (NOT directly over the block). The block will be highlighted with white balls. Right clicking will bring up a menu with which you can delete the block (only if it is on top of the stack) or change it’s colour. The Quit Button: Press this button when you are done building all three structures and are confident that they are correct. Pressing this button ends the trial. The experimenter will also request that you press quit if you run out of time before you are done building the structures.
67
B.4 Consent Form SIMON FRASER UNIVERSITY INFORMED CONSENT BY SUBJECTS TO PARTICIPATE IN A RESEARCH PROJECT OR EXPERIMENT The University and those conducting this project subscribe to the ethical conduct of research and to the protection at all times of the interests, comfort, and safety of subjects. This form and the information it contains are given to you for your own protection and full understanding of the procedures. Your signature on this form will signify that you have received a document which describes the procedures, possible risks, and benefits of this research project, that you have received an adequate opportunity to consider the information in the document, and that you voluntarily agree to participate in the project. Any information that is obtained during this study will be kept confidential. Knowledge of your identity is not required. You will not be required to write your name or any other identifying information on the research materials. Materials will be held in a secure location and will be destroyed after the completion of the study. Having been asked by Garth Shoemaker of the School of Computing Science of Simon Fraser University to participate in a research project experiment, I have read the procedures specified in the document. I understand the procedures to be used in this experiment. I understand that I may withdraw my participation in this experiment at any time. I also understand that I may register any complaint I might have about the experiment with the researcher named above or with Dr. Ronald G. Marteniuk, the Dean of Applied Science of Science of Simon Fraser University. I may obtain copies of the results of this study, upon its completion, by contacting: Garth Shoemaker or Dr. Kori Inkpen, School of Computing Science, Simon Fraser University. I have been informed that the research material will be held confidential by the Principal Investigator unless my permission has been given as indicated below to use it for the presentation of research results. I understand that my supervisor or employer may require me to obtain his or her permission prior to my participation in a study such as this. I agree to participate by taking part in the study which requires me to work with a partner constructing virtual Lego brick structures on two different computer systems. Furthermore, I agree to fill in a background and a post session questionnaire, as described in the document referred to above, during the time period June 2000-July 2001 at the offices of Electronic Arts Canada.
I agree to participate in the experiment
YES
NO
(circle one)
I agree to be videotaped and audiotaped
YES
NO
(circle one)
I agree to let the videotapes and audiotapes be shown publicly when the Researcher presents this work
YES
NO
(circle one)
NAME (please type or print legibly): ______________________________________ ADDRESS:
__________________________________________________________
______________________________________________________________________ SIGNATURE: _______________________ WITNESS: ______________________
DATE:
68
B.5 Information Sheet Information Sheet to Participants Introduction In our 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 only one user, while hiding that information from other users who are looking at the same computer display. We are running a study to determine the usefulness of this display technique. The results of this study will provide us with quantitative and qualitative information that may validate the technique and/or provide us with a direction of investigation for future research. Procedure 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 will 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 able to interact with the computer with your own mouse and cursor. Before and after the experiment, you will be asked to fill in a questionnaire. The first 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 camera will record your physical actions and any verbal communication. You are allowed to withdrawal your participation in the experiment at any time if you so desire. Benefits Your participation in this study will 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 order to improve current human-computer interfaces. We hope to obtain statistically significant data from this experiment that will lead us towards this goal. Risks There are no personal risks for the subjects.
69
B.6 Colour Blindness Test
70
71
Bibliography [1] 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 UIST '96, pages 169{170. ACM 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, William Buxton, and Tony D. DeRose. Toolglass and magic lenses: The see-through interface. In Proceedings of SIGGRAPH '93, pages 73{80. ACM Press, 1993. [4] Lauren J. Bricker, Marla J. Bennett, Emi Fujioka, and Steven L. Tanimoto. Colt: A system for developing software that supports synchronous collaborative activities. In Proceedings of EdMedia '99, 1999. [5] Lauren J. Bricker, Steven L. Tanimoto, Alex I. Rothernberg, Danny C. Hutama, and Tina H. Wong. Multiplayer activities that develop mathematical coordination. In Proceedings of CSCL '95, pages 32{39, 1995. [6] Donald A. Cox, Jasdeep S. Chugh, Carl Gutwin, and Saul 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 Proceedings 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 public information personal. Personal Technologies, 3(1), 1999. [9] Carl Gutwin and Saul Greenberg. Design for individuals, design for groups: Tradeo s between power and workspace awareness. In Proceedings of CSCW '98, pages 207{216. ACM Press, 1998. [10] Carl Gutwin and Saul Greenberg. E ects of awareness support on groupware usability. In Proceedings of CHI '98, pages 511{518. ACM Press, 1998. 72
[11] Carl Gutwin and Mark Roseman. A usability study of awareness widgets in a shared workspace groupware system. In Proceedings of CSCW '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 evaluation of a display design to enhance focused and divided attention. In Proceedings 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 CS-TR-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 Proceedings 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 all best friends and we're all playing!": Supporting children's synchronous collaboration. In Proceedings of CSCL '99, 1999. [16] Kori M. Inkpen, Joanna McGrenere, Kellogg S. Booth, and Maria Klawe. The e ect of turn-taking protocols on children's learning in mouse-driven collaborative environments. In Proceedings of Graphics 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 computer-based education. Technical Report TR-94-5, Department of Computing Science, University of British Columbia, 1994. [18] Hiroshi Ishii and Minoru Kobayashi. Clearboard: A seamless medium for shared drawing and conversation with eye contact. In Proceedings 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 Proceedings of EuroCSCW '95, pages 197{213. Kluwer Academic Publishers, 1995. [20] Gloria Mark, Jorg M. Haake, and Norbert A. Streitz. Hypermedia structures and division of labour in meeting room collaboration. In Proceedings of CSCW '96, pages 170{179. ACM Press, 1996. [21] Brad Myers, Kin Pou (\Leo") Lie, and Bo-Chieh (\Jerry") Yang. Two-handed input using a PDA and a mouse. In Proceedings of CHI 2000, pages 41{48, 2000. [22] Brad A. Myers. The Amulet environment: New models for e ective user interface software development. IEEE Transactions on Software Engineering, 23(6):347{365, June 1997. 73
[23] Brad A. Myers. An implementation architecture to support single-display groupware. Technical Report CMU-CS-99-139, Carnegie Mellon University, 1999. [24] Brad A. Myers, Herb Stiehl, and Robert Gargiulo. Collaboration using multiple PDAs connected to a PC. In Proceedings of CSCW '98, pages 285{294. ACM Press, 1998. [25] Elin R. Pederson, Kim McCall, Thomas P. Moran, and Frank G. Halasz. Tivoli: An electronic whiteboard for informal workgroup meetings. In Proceedings of INTERCHI '93, pages 391{398. ACM Press, 1993. [26] Jun Rekimoto. A multiple device approach for supporting whiteboard-based interactions. In Proceedings of CHI '98, pages 18{23. ACM Press, 1998. [27] Jun Rekimoto and Masanori Saitoh. Augmented surfaces: A spatially continuous work space for hybrid computing environments. In Proceedings 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 collaborative interactions. In Proceedings of Graphics Interface 2000, pages 103{110, 2000. [29] Garth B. D. Shoemaker. Supporting private information on public displays. In CHI 2000 Extended Abstracts, 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. ftp://fas.sfu.ca/pub/cs/TR/2000/CMPT2000-01.pdf. [31] Garth B. D. Shoemaker and Kori M. Inkpen. Single Display Privacyware: Augmenting public displays with private information. In Proceedings of CHI 2001. ACM Press, 2001. [32] Jason Stewart, Benjamin B. Bederson, and Allison Druin. Single Display Groupware: A model for co-present collaboration. In Proceedings of CHI '99, pages 286{293. ACM Press, 1999. [33] Jason Stewart, Elaine M Raybourn, Ben Bederson, and Allison Druin. When two hands are better than one: Enhancing collaboration using single display groupware. In Proceedings of CHI '98, pages 287{288. ACM Press, 1998. [34] Masayuki Tani, Masato Horita, Kimiya Yamaashi, Koichiro Tanikoshi, and Masayasu Futakawa. Courtyard: Integrating shared overview on a large screen and per-user detail on individual screens. In Proceedings of CHI '94, pages 44{50. ACM Press, 1994. [35] John Underkoer and Hiroshi Ishii. Urp: A luminous-tangible workbench for urban planning and design. In Proceedings of CHI '99, pages 386{393. ACM Press, 1999. 74
