Open Collections

UBC Theses and Dissertations

UBC Theses Logo

UBC Theses and Dissertations

A collaborative planning support system for a multi-touch tabletop : the effect of number of touch inputs… Fernquist, Jennifer Ellen 2010

Your browser doesn't seem to have a PDF viewer, please download the PDF to view this item.

Item Metadata

Download

Media
24-ubc_2010_fall_fernquist_jennifer.pdf [ 6.09MB ]
Metadata
JSON: 24-1.0051956.json
JSON-LD: 24-1.0051956-ld.json
RDF/XML (Pretty): 24-1.0051956-rdf.xml
RDF/JSON: 24-1.0051956-rdf.json
Turtle: 24-1.0051956-turtle.txt
N-Triples: 24-1.0051956-rdf-ntriples.txt
Original Record: 24-1.0051956-source.json
Full Text
24-1.0051956-fulltext.txt
Citation
24-1.0051956.ris

Full Text

A Collaborative Planning Support System for a Multi-Touch Tabletop The Effect of Number of Touch Inputs on Collaboration and Output Quality by Jennifer Ellen Fernquist  B.Sc. (Honours), Simon Fraser University, 2007  A THESIS SUBMITTED IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE in The Faculty of Graduate Studies (Computer Science)  THE UNIVERSITY OF BRITISH COLUMBIA (Vancouver) August 2010 c Jennifer Ellen Fernquist 2010  Abstract This thesis describes the design and evaluation of a collaborative urban planning support system for an interactive multi-touch tabletop display. The system facilitates the design of spatial patterns of proposed development in a co-located collaborative manner. We worked closely with faculty in the School of Architecture and Landscape Architecture at the University of British Columbia and employed an iterative, user-centered development process to create a tabletop system to support landscape architect’s primary urban planning steps. The prototype system is designed for use by urban planners, stakeholders, or private citizens: users with a variety of backgrounds and expertise. The collaborative urban planning support system was designed for use on a multi-touch tabletop following lessons learned about considerations for planning support systems, tabletop applications, and encouraging collaboration. The system contains a limited yet adequate set of functions for arranging various building types on a development site map. It has an intuitive and highly interactive interface and uses input data that comes directly from the elementsLAB team. A primary focus of the pattern creation application is ensuring equity of collaboration among users. Urban planners believe that it is important that all members of a group contribute equally to produce a neighbourhood that meets predefined quantitative and qualitative targets. We conducted a controlled experiment that investigated how varying the number of simultaneous touch inputs in the application affects collaboration and output quality. We tested hypotheses that users would (i) collaborate more, (ii) produce higher quality output, and (iii) complete their task faster with a multi-touch application than with a single-touch application. We also tested the hypothesis that (iv) multi-touch interactions with application elements will be preferred over traditional single-touch interactions. The number of touches accepted did not affect the amount of collaboration, output quality, or time. However, participants perceived the multitouch tasks to be faster and to produce neighbourhood patterns of higher quality. Participants seemed to be more cognitively absorbed in the multiii  Abstract touch tasks and they significantly preferred the multi-touch application over the single-touch application. In addition, all multi-touch interactions were significantly preferred over single-touch interactions.  iii  Table of Contents Abstract  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ii  Table of Contents . . . . . . . . . . . . . . . . . . . . . . . . . . . .  iv  List of Tables  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . vii  List of Figures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . . .  ix  Statement of Co-Authorship . . . . . . . . . . . . . . . . . . . . .  x  1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  1  2 Related Work . . . . . . . . . . . . . . . . . . . . . . 2.1 Multi-Touch Tables and Collaborative Work . . . 2.2 Planning Support Systems: Single-User Systems . 2.2.1 UrbanSim . . . . . . . . . . . . . . . . . . 2.2.2 CommunityViz . . . . . . . . . . . . . . . . 2.2.3 What If? . . . . . . . . . . . . . . . . . . . 2.2.4 MetroQuest . . . . . . . . . . . . . . . . . 2.3 Planning Support Systems: Collaborative Systems 2.3.1 Futura . . . . . . . . . . . . . . . . . . . . 2.3.2 Urp . . . . . . . . . . . . . . . . . . . . . . 2.3.3 Luminous Table . . . . . . . . . . . . . . . 2.3.4 MR-Tent . . . . . . . . . . . . . . . . . . . 2.3.5 Virtual Environment . . . . . . . . . . . .  . . . . . . . . . . . . .  . . . . . . . . . . . . .  . . . . . . . . . . . . .  . . . . . . . . . . . . .  . . . . . . . . . . . . .  . . . . . . . . . . . . .  4 4 6 7 8 8 9 9 9 10 10 11 12  3 System Design . . . . . . . . . . . . . . . . . . . 3.1 ElementsLAB . . . . . . . . . . . . . . . . . 3.2 ElementsLAB Public Engagement Process . 3.3 Support Tool Design . . . . . . . . . . . . . . 3.3.1 Iterative, User-Centered Development  . . . . .  . . . . .  . . . . .  . . . . .  . . . . .  . . . . .  14 14 15 17 17  . . . . .  . . . . .  . . . . .  iv  Table of Contents 3.3.2  System Design Discussion . . . . . . . . . . . . . . . .  4 Prototype Implementation . . . . . . . . . . 4.1 Hardware . . . . . . . . . . . . . . . . . . . 4.2 Software . . . . . . . . . . . . . . . . . . . 4.2.1 Building Menu . . . . . . . . . . . . 4.2.2 Map . . . . . . . . . . . . . . . . . . 4.2.3 Charts . . . . . . . . . . . . . . . . 4.2.4 Saved Patterns . . . . . . . . . . . . 4.2.5 Single-Touch Interaction Techniques 4.2.6 Multi-Touch Interaction Techniques 4.2.7 Multi-User Parallelism . . . . . . . 4.2.8 Summary . . . . . . . . . . . . . . .  18  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  . . . . . . . . . . .  21 21 21 22 27 29 30 32 32 32 33  . . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  . . . . . . .  34 34 34 35 36 36 37  6 Results & Discussion . . . . . . . . . . . . . . . . . . . . . 6.1 Demographics . . . . . . . . . . . . . . . . . . . . . . . 6.2 Experimental Task Completion Time . . . . . . . . . . 6.3 Quality of Patterns . . . . . . . . . . . . . . . . . . . . 6.4 Number of Interactions on Building Pieces . . . . . . . 6.5 Collaboration . . . . . . . . . . . . . . . . . . . . . . . . 6.5.1 Amount of Talking . . . . . . . . . . . . . . . . 6.5.2 Distribution of Actions Among Group Members 6.5.3 Re-orientation of Objects . . . . . . . . . . . . . 6.5.4 Task Outcome . . . . . . . . . . . . . . . . . . . 6.5.5 Time . . . . . . . . . . . . . . . . . . . . . . . . 6.5.6 Self Reports . . . . . . . . . . . . . . . . . . . . 6.5.7 Composite Collaboration Scores . . . . . . . . . 6.5.8 Strategy Type . . . . . . . . . . . . . . . . . . .  . . . . . . . . . . . . . .  . . . . . . . . . . . . . .  . . . . . . . . . . . . . .  45 46 46 51 54 57 57 57 58 58 58 59 59 62  7 Conclusions & Future Work . . . . . . . . . . . . . . . . . . . 7.1 Experimental Findings . . . . . . . . . . . . . . . . . . . . . 7.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . .  67 67 67  5 Experiment . . . . . . . . . . . . . 5.1 Overview . . . . . . . . . . . . 5.2 Hypotheses . . . . . . . . . . . 5.3 Method . . . . . . . . . . . . . 5.3.1 Participants . . . . . . 5.3.2 Software, Hardware, and 5.3.3 Procedure . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Materials . . . . . .  . . . . .  v  Table of Contents . . . .  68 69 69 71  Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  72  7.2  7.1.2 Implications . . . . . . Future Work . . . . . . . . . . 7.2.1 Interface Enhancements 7.2.2 Functionality . . . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  . . . .  Appendices A Pre-Session Questionnaire  . . . . . . . . . . . . . . . . . . . .  77  . . . . . . . . . . . . . . . . . . . . .  79  C Post-Session Questionnaire . . . . . . . . . . . . . . . . . . . .  82  D Sunset Neighbourhood Background Information . . . . . .  85  E Task Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . .  90  F Ethics Approval Certificate  94  B Post-Task Questionnaire  . . . . . . . . . . . . . . . . . . .  vi  List of Tables 4.1  Outline of the colours used to represent buildings in the pattern creation application. . . . . . . . . . . . . . . . . . . . .  23  5.1 5.2  Outline of the three experimental tasks. . . . . . . . . . . . . Outline of the four experimental treatments. . . . . . . . . . .  38 39  6.1  One-way ANOVA results comparing effects of touch condition, experimental task, and trial number on pattern alternative completion. . . . . . . . . . . . . . . . . . . . . . . . . . . One-way ANOVA results comparing effects of touch condition, experimental task, and trial number on pattern alternative completion. . . . . . . . . . . . . . . . . . . . . . . . . . . One-way ANOVA results comparing effects of condition, task, and trial on pattern task completion. . . . . . . . . . . . . . . Repeated-measures ANOVA results comparing effects of condition, task, and trial on normalized expert scores. . . . . . . One-way ANOVA results comparing effects of degree level on pattern alternative scores from experts. . . . . . . . . . . . . Repeated-measures ANOVA results comparing effects of condition, task, and trial on total translation in the X and Y directions (in pixels) and total rotation (in degrees). . . . . . Normalized scores for each of the six quantified collaborative properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pearson correlation results analysing the correlation between the individual collaboration score components and pattern scores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  6.2  6.3 6.4 6.5 6.6  6.7 6.8  47  49 49 54 54  56 60  62  vii  List of Figures 3.1  The collaborative design process employed by the elementsLAB. 16  4.1 4.2 4.3 4.4  Screenshot of the pattern creation application. . . . . . . . . Building menu in the pattern creation application. . . . . . . Pull tab feature for low density residential buildings . . . . . Map image of the Sunset neighbourhood used in the pattern creation application. . . . . . . . . . . . . . . . . . . . . . . . Chart area of the application. . . . . . . . . . . . . . . . . . . Saved patterns interactions (restore, delete, no action) . . . .  22 25 26  Paper map for the paper-based condition of the user study. . The 6 sustainability principles . . . . . . . . . . . . . . . . . . Overhead view of the experimental setup. . . . . . . . . . . . Still image from video camera 1 used during the experiment in the paper-based training task. . . . . . . . . . . . . . . . . Still image from video camera 1 used during the experiment in a table condition. . . . . . . . . . . . . . . . . . . . . . . . Still image from video camera 2 used during the experiment in the paper-based training task. . . . . . . . . . . . . . . . . Still image from video camera 2 used during the experiment in a table condition. . . . . . . . . . . . . . . . . . . . . . . .  37 40 42  Graph showing the pattern alternative completion times. . . . Correlation of expert scores for each pattern. . . . . . . . . . Correlation of expert scores for each pattern. . . . . . . . . .  51 53 61  4.5 4.6 5.1 5.2 5.3 5.4 5.5 5.6 5.7  6.1 6.2 6.3  28 29 31  43 43 44 44  viii  Acknowledgements First and foremost I would like to thank my supervisors, Kellogg S. Booth and Alan K. Mackworth, for their continued support, guidance, critique, and praise. I feel grateful to have had the unique privilege of being supervised by such excellent professors from such different disciplines. I still can’t believe my luck; I learned a great deal from them both. I am grateful to my second reader, William Evans, for taking the time to review this thesis. I have been given a great deal of support, advice, and wisdom during my time at UBC. I would like to thank Brad Swerdfeger for his ceaseless support and companionship. This journey was amazing and joyful in large part because he took it with me. I’m grateful for the new friendships I have formed, particularly my “thoroughly investigated” buddy Thomas Hazelton. I would like to thank Tony Tang, Garth Shoemaker, and Kirstie Hawkey for their guidance. A huge thanks to Ronald Kellett, Cynthia Girling, and the elementsLAB team in the School of Architecture and Landscape Architecture for collaborating with me and making this whole work possible. They were an absolute pleasure to work with. I would also like to thank my ladies Elisabeth Babbel, Colleen Stevenson, and Jessica Peters, and my boy Tim Kim for continuing to be there for me. I would not be here without the support of all of my parents, Marcie Fernquist and Fred Grosser, Duane Fernquist and Debbie Cole. Thank you all for your love and encouragement. The research reported in this thesis was supported by the Natural Sciences and Engineering Research Council of Canada through two Discovery grants, a Strategic Project grant, and a Research Tools and Instrumentation grant, by the Networks of Centres of Excellence program through the GRAND NCE Shared Display project, by the Canada Foundation for Innovation through a New Initiatives award to the Institute for Computing, Information and Cognitive Systems, by The University of British Columbia through a University Graduate Fellowship, and by SMART Technologies of Calgary, Alberta. ix  Statement of Co-Authorship Sections 3.1 and 3.2 were co-authored by a colleague, Cynthia Girling, from the elementsLAB in the School of Architecture and Landscape Architecture at the University of British Columbia. Section 3.1 and the first half of section 3.2 were first written by Cynthia Girling and then modified as necessary by the author. All work described in this thesis was performed under the supervision of Kellogg S. Booth and Alan K. Mackworth with regular consultation from Ronald Kellett and Cynthia Girling from the elementsLAB. William Evans was the second reader for the thesis.  x  Chapter 1  Introduction This thesis describes research on the design and evaluation of a collaborative urban planning support system for an interactive multi-touch tabletop display. The system facilitates the creation of spatial patterns of proposed development in a co-located collaborative manner. We worked closely with members of the elementsLAB team in the School of Architecture and Landscape Architecture at the University of British Columbia to obtain application requirements and objectives. Our prototype system is designed for use by urban planners, stakeholders, or private citizens; users with a variety of backgrounds and expertise. Many jurisdictions have adopted participatory, consensus-based urban planning processes involving a heterogeneous group of stakeholders. Such processes are commonly used to define the goals and policies for new neighbourhoods and carry out collaborative design. The elementsLAB researches tools that can help educate and facilitate communication between groups involved in these processes. Such tools must present visualizations of proposed development alternatives, allow for comparison of alternatives, and present measurements and calculations of the alternatives’ adherence to the goals and policies. The tools must also not be overly complex and must be usable by groups with varying expertise. Existing support tools for urban planning process carried out by the elementsLAB team are primarily paper-based. Designs are created with a large paper map of the neighbourhood and pieces of paper, representing buildings and parks, are arranged on the map to form a development pattern. The patterns are manually measured to calculate their adherence to the predefined goals. While this paper-based method is highly visual and accessible, it is difficult to compare alternative designs and it is tedious to conduct the calculations. The elementsLAB seeks a tool that maintains the positive visual and collaborative affordances of their current method while providing additional functionality to help facilitate the process. We investigated a series of existing urban development system solutions, called planning support systems (PSS), that are used in future planning scenarios. The traditional PSSs are highly complex systems that take land 1  Chapter 1. Introduction use and transportation models as input and output predictions for a region based on the input. While these systems have a large amount of functionality, they are designed for experts and do not facilitate collaboration. A different class of PSSs are design to be collaborative. They often involve tabletop displays and tangibles; 3D building models that can be arranged on the table and be tracked by the system. These systems are highly visual, interactive, and facilitate discussions. However, they lack in functionality and do not offer methods to easily compare design alternatives. We investigated existing literature on multi-touch applications and design considerations for co-located collaborative systems. Multi-touch tabletops have excellent affordances for collaboration due to their large, horizontal form factor and their ability to accept touch inputs from multiple users simultaneously. Currently there do not exist any system-enforced methods that effectively encourage collaboration, but groups of users cannot necessarily rely on social protocols alone. We created a collaborative PSS designed for use on a multi-touch tabletop. It was informed by examples drawn from the literature on collaborative and single-user PSSs, tabletop applications, and encouraging collaboration. We conducted an iterative, user-centered development process to produce a system that facilitates the elementsLAB team’s primary urban planning steps. The system contains a limited yet adequate set of functionality for arranging various building types on a development site and for comparing alternative designs. It has an intuitive and highly interactive interface and uses input data that comes directly from the elementsLAB team. A primary focus of the collaborative PSS is the equity of participation of users. It is important that all members of a group of users feel comfortable using the tabletop device and contribute as much as their partners. It is also important that the application output be of as high quality as possible. That is, the users should create a feasible neighbourhood that meets predefined quantitative and qualitative targets. We conducted a controlled experiment that investigated how varying the number of accepted touch inputs in the application affects collaboration and quality of output. We tested hypotheses that users would (i) collaborate more, (ii) produce higher quality output, and (iii) complete their task faster with a multi-touch application than in a single-touch application. We also tested the hypothesis that (iv) multi-touch interactions with the building objects will be preferred over more traditional single-touch interactions. In addition, we analysed the turn-taking mechanisms that participants employed during the study. The remainder of this thesis is organized into six chapters. Chapter 2, Related Work, discusses research in the area of multi-touch tables for col2  Chapter 1. Introduction laborative work as well as a variety of planning support systems. Chapter 3, System Design, provides a discussion of the motivation behind the design of our prototype multi-touch planning support system. Chapter 4, Prototype Implementation, describes the hardware, software, and functionality of the prototype system in detail. Chapter 5, Experiment, describes a user study conducted with the prototype system to identify the effects of restricting the number of touch interactions on collaboration for a co-located urban planning task. Chapter 6, Results & Discussion, describes the quantitative and qualitative results of our study and discusses our findings. Chapter 7, Conclusions & Future Work, summarizes the findings from the study and presents areas for future work.  3  Chapter 2  Related Work In this chapter we describe a variety of previous and current work related both to multi-touch tabletops and to decision support systems for urban planning. We first consider prior research on multi-touch tables and findings related to co-located collaborative work. We then discuss two types of planning support systems designed to assist urban planners and stakeholders: analytical systems, which enable expert users to create complex city or regional models and calculate future predictions; and interactive systems, which typically focus on urban design at smaller scales and encourage collaboration between users who have a variety of backgrounds and experience.  2.1  Multi-Touch Tables and Collaborative Work  There has been a great deal of research studying co-located collaborative work with single display groupware and multi-touch tables. Researchers have investigated the affordances of the tabletop form factor for collaborative tasks and used these to inform general application design guidelines, studied how social protocols are affected by simultaneous user interactions to suggest methods for encouraging collaboration, and conducted comparisons of single and multi-input systems. Stewart et al. [32] defined single display groupware (SDG) to be “computer programs that enable co-present users to collaborate via a shared computer with a single shared display and simultaneous use of multiple input devices.” For multi-touch tables, the single display is a horizontal projected image and the multiple input devices are the users’ fingertips. Stewart et al. indicate two positive aspects of SDG for collaboration: the ability to work in parallel and the elimination of turn taking. Touch inputs have been said to lead to more ‘natural’ collaboration because people find interactive surfaces inviting and they feel comfortable exploring them with their fingers, and they can learn how to use the surface applications without feeling embarrassed [30]. People’s comfort level with a device affects their willingness to participate in a collaborative task. People seem more willing to interact with multi-touch tabletops as opposed to 4  2.1. Multi-Touch Tables and Collaborative Work interactive wall displays in the presence of others even though their actions are highly visible [12]. The horizontal form factor of tabletop displays offers a number of advantages compared to vertical wall displays. Sitting at a tabletop for lengthy periods is more comfortable than standing at a wall display. Tabletops allow face-to-face collaboration among a small group of co-located individuals. Marshall et al. [22] and Rogers et al. [28] both discovered that tabletop interfaces are more equitable compared to a whiteboard or wall display in terms of digital interactions. They suspect it is because vertical displays can be intimidating to use in front of a group of people. The displays can easily be dominated by one or two individuals, whose physical presence may block others from interacting with the display, greatly reducing collaboration. This is a problem. Equality is essential for tasks where it is important that all parties feel that their contribution is important and their ideas are heard [2]. It is possible to encourage collaboration through multi-user coordination policies or cooperative gestures, such as those implemented by Morris et al. [24]. A multi-user coordination policy may dictates the course of action when two people attempt to grab the same digital object such as a picture or document; for example, the application may tear the object in half or duplicate the object so each user has a copy. A cooperative gesture prevents a single person from performing a global action without the consent of the rest of the group. For example, a global gesture implemented by Morris et al. to exit the application requires all group members to hold hands and one person to touch the ‘exit’ command. Such coordination policies and cooperative gestures are not ideal solutions since they may not reflect realworld occurrences, they can be accidentally invoked, they can be tedious for frequently used system commands, or, if touching other group members is involved, they may overstep personal boundaries. Scott et al. [29] described several design considerations for multi-touch table applications for co-located collaborative work. Three of the most relevant to our work: support for interpersonal interaction, consideration for the appropriate arrangement of users, and support for simultaneous user actions. Pinelle et al. [27] proposed a set of small-scale actions and interactions, called the mechanics of collaboration, that must be supported for a group to accomplish a task collaboratively. These actions include communication, coordination, planning, monitoring and protection. There has also been research that investigates social protocols and how people coordinate amongst themselves during collaborative work using a tabletop device. Morris et al. [25] discussed conflicts that arise in a single5  2.2. Planning Support Systems: Single-User Systems display, direct-manipulation environment. They argued that relying on users to follow social protocols is not sufficient and emphasized the need for software-enforced coordination policies. These observations came from the development of several tabletop applications, including Table-for-N [31] and the Magnetic Poetry Table [31]. Greenberg and Marwood [13] observed that while social protocols are generally sufficient for preventing conflicts, there are many types of conflicts that cannot be resolved solely by social protocols. For example, conflicts caused by accident or confusion, unanticipated side effects of a user’s action, and interruptions are not easily resolved. Research has also explored the use of personal and global space on tabletops; however, areas of personal space are not always appropriate or necessary for collaborative tasks where all members are working towards the same single common goal. In a comparison of single- vs. multi-touch systems, research conducted by Marshall et al. [22] varied the number (one or all participants could act) and types of input (touch or mouse) and its effect on equity of participation (verbal and interaction) in a co-located collaborative task. Participants worked in groups of three to design a seating plan for a new computing department building. They found that equity of interaction increased with the use of both touch inputs and simultaneous touch inputs. Participants’ equity of verbal participation and perception of equity were not significantly different across conditions. Some participants indicated that dominant people would take over more in the single input conditions, but that quieter people, who normally did not contribute as much, contributed more in the touch conditions than they normally did because they felt less self-conscious about their actions. In summary, it is clear that there is not a single ideal solution for encouraging or ensuring equity of collaboration for multi-touch tabletop applications. To a certain degree users can be expected to develop or use their own social protocols, but application-enforced protocols may offer support for collaboration and to promote an equal amount of participants from all users.  2.2  Planning Support Systems: Single-User Systems  A planning support system (PSS), described by Klosterman as a “fully integrated, flexible, and user-friendly system” assists urban planners in testing 6  2.2. Planning Support Systems: Single-User Systems a variety of projection and impact models, displaying outputs both visually and numerically [16]. A PSS uses a spatial pattern of proposed development as input and either computes a future prediction or estimates the current impact of the development pattern. Typically results will be presented both visually, with 2D or 3D graphics, and quantitatively as tabular data or summary statistics. All of the systems described in this section are for use by a single person on a single PC or Macintosh computer with a single mouse and keyboard input. Collaborative systems are discussed in the next section.  2.2.1  UrbanSim  UrbanSim [35], created by Waddell [38] [39] and Borning et al. [4] [3], is a sophisticated PSS that uses transportation, land use, and environment data along with policy choices and real estate market forces as input, runs a complex set of algorithms, and then outputs a future prediction model for the region. The input data may be current or hypothesized land use information (type and location) and transportation models, along with policy choices related to zoning, urban growth boundaries, taxes, and incentives. The algorithms that compute the output model use a dynamic disequilibrium approach [39] that can run different processes at different time rates. The output of the prediction model is displayed both graphically as GIS data and numerically as estimates of land use distribution and other measures. UrbanSim works at the regional scale. It does not focus on growth or development at the individual block or neighbourhood scales. The UrbanSim system allows users to generate a variety of scenarios for a single region by varying the input parameters, which can then be compared. UrbanSim’s intended users are city stakeholders, non-governmental organizations, researchers, and planning experts. While the software is open source and freely available on the Internet, its steep learning curve and presumption of urban planning knowledge make it difficult to use by private citizens who wish to be involved in development projects in their neighbourhood. It also does not support collaborative, parallel use and cannot easily be used simultaneously by groups of stakeholders who might take part in a collaborative urban planning session. UrbanSim is typically used by individual experts to test various transportation or land use policies, run predictions, and present results to city stakeholders for deliberation.  7  2.2. Planning Support Systems: Single-User Systems  2.2.2  CommunityViz  Similar to UrbanSim, CommunityViz, created by Kwartler and Bernard [20], is a large and complex series of ArcGIS extensions that take as input land use models and user-defined policies. It computes a predictive model and outputs both 2D and 3D graphical data as well as numerics. The system has two components: Scenario 360, a highly interactive analysis framework that uses a multi-agent simulation model to conduct analyses on user-specified development models, and Scenario 3D, a visualization tool that creates 3D scenes from the output data from Scenario 360. Graphical representations of output data are visible at a variety of scales with extensive visualization functionalities. CommunityViz is intended to be a collaborative tool, but one in which different members of a collaborative group interact at different steps in the modelling process. One or more members may create input data sets for the system. Other members may generate the predictive models or create visualizations or numerical reports, while other groups may inspect the reports and make development decisions. The complexity of the system, like UrbanSim, requires that users have training and education in ArcGIS as well as in urban planning in order to use it effectively.  2.2.3  What If ?  The What If? system created by Klosterman [17] is a collaborative GISbased PSS that also accepts land use models and policies as input and produces prediction models as output. Unlike the more complex UrbanSim and CommunityViz systems, it is intended for use by a wide range of people with different educations and backgrounds, including private citizens. Users can select from a list of predefined models and policy choices to compute future projections with both visual and numerical results. The What If? application has a limited feature set, which makes it more accessible to non-experts but less sophisticated in its functionality. Information is only viewable and calculable at the regional scale; users cannot zoom in to inspect what’s happening at the neighbourhood scale. In addition, the What If? application is intended for use by a single user and does not have collaborative affordances. Private citizens may be able to generate prediction models of their city, but they would not necessarily be able to use What If? to discuss their findings with stakeholders.  8  2.3. Planning Support Systems: Collaborative Systems  2.2.4  MetroQuest  MetroQuest [23] is a PSS designed for use by municipalities and planning agencies to specify policy choices and produce prediction models. The models can then be communicated to non-expert audiences. Non-experts can also use the system either online, in a workshop, or at one of several kiosks distributed in a variety of public locations. Like the What If? system, MetroQuest has a smaller set of functionality; however, the development team actively organizes public engagements to use the scenario visualization tool. Citizens may be invited to use the online or kiosk systems and list their development priorities or to attend a collaborative workshop and discuss their priorities in person. While single-user planning support models are very useful for computing accurate predictive models of future land use scenarios, their complexity, learning curve, and overall design limit their use to a single expert user. They are not well suited to collaborative urban design involving discussions and alternative comparisons, especially at smaller, neighbourhood scales.  2.3  Planning Support Systems: Collaborative Systems  Systems described in this section are not true PSS systems as defined by Klosterman, but they are highly interactive and generally collaborative systems that support some aspects of urban design.  2.3.1  Futura  Futura, the Sustainable Futures Game created by Tanenbaum et al. [33], is a collaborative learning tool that teaches users about sustainability. It was designed to explore the use of collaborative, multi-touch tabletop games for learning. The game presents a static, generic, undeveloped neighbourhood to which users can add icons that represent residential, service, or industrial buildings. The buildings all have an impact on the area’s population, energy use, and environmental health. The building images are of the same fixed size and orientation, and the region cannot be scaled. The game is useful for demonstrating the impact of development choices on the sustainability of a region, but Futura’s very limited scope and restricted interactions limit its usefulness to an educational tool.  9  2.3. Planning Support Systems: Collaborative Systems  2.3.2  Urp  Urp, created by Underkoffler and Ishii [34], is a tangible interactive system that allows users to manipulate scale model buildings on a table while Urp projects information onto the table based on the buildings’ positions. Urp utilizes a camera and projector to recognize the models and project a variety of information, including building shadows at arbitrary times of day, pedestrian-level wind patterns, and reflections of glass surfaces from buildings onto other objects such as roads. The system has good collaborative affordances because more than one person can interact simultaneously with the models and their tangible nature invites exploration. However, the Urp prototype has very limited functionality: data is only generated at the building or block scale.  2.3.3  Luminous Table  Ishii et al. made significant extensions to the Urp concept and expanded it into a collaborative urban planning workbench that uses tangibles, paper, and digital elements [15]. It integrates physical capabilities (paper drawings and physical building models) and digital capabilities (digital building models, computational simulation and analysis) into a single PSS centered around a 4.0m x 1.4m Luminous Table. This extends Urp’s functionality to include sun-shade computations with dynamic latitude, traffic simulation, architecture geometries, and saving/loading of designs. The Luminous Table was used in an urban design class at the MIT School of Architecture and Planning where groups of students carried out a collaborative design task over a semester. After analysing observational video and questionnaire results Ishii et al. came to several conclusions: using a conventional representation provides useful affordances; merging simulation data with the physical models is favourable; tracking the physical models was difficult; and a large table facilitates collaboration and communication because many people can sit around it and interact with the Luminous Table simultaneously. The Luminous Table appears to be excellent for an iterative and collaborative urban planning process. However, it is limited to a single scale because the physical building models are a fixed size; thus it lacks the ability to zoom out to a neighbourhood or regional scale. In addition, the vision tracking is at times poor. Students in the study were forced to manually set the position of the models using a computer mouse. Finally, the system considered only a small set of criteria for evaluating a proposal and did not  10  2.3. Planning Support Systems: Collaborative Systems include more complex measures such as sustainability, which are not easily quantifiable.  2.3.4  MR-Tent  Wagner et al. [40] have worked for several years on the Mixed-Reality Tent (MR-Tent), an urban design environment that combines physical models with multiple digital displays to support collaborative site development. Their focus is on bringing together a heterogeneous group of people with different perspectives, backgrounds, and expectations to discuss development projects. They recognize the constraints of PSSs that carry out complex predictive analyses as well as their non-participatory nature. The MR-Tent consists of a ColourTable [21] and two vertical projections. The ColourTable is the interactive area. It projects a top-down view of a development site. On the table are coloured tokens that can be moved about and oriented while a computer vision system tracks their positions, shapes, and colours. The shape and colour represent the object type. The vertical projections display a pedestrian-level street view of the site. The colour and transparency of the virtual representation of the objects can be changed by using cards with barcodes that serve as command tokens. A recent participatory workshop conducted with the MR-Tent studied the 13-hectare site Caserne Brossut in the city of Pontoise, France. The old military area was to be re-developed with 2000 residential homes, a commercial zone, some service buildings, and a public square. The researchers brought in a diverse group of people with interests in and ideas for the site to take part in a workshop discussing it. They underwent a ‘participatory interview’ (from which the researchers derived two development scenarios), a two-hour training session, and a tutorial. The participants then developed their vision of the site using the MR-Tent. During the tutorial and development session they could add buildings and roads, allocate land use, and freehand sketch on the digital site through interactions with tangibles. As with the Luminous Table, the use of tangibles defined the scale of the area, although participants had two sets of tokens for two different scales. The tangibles were simple, uni-coloured geometric objects and were not representative of their real-world counterparts. Tokens placed on the ColourTable became associated with digital objects. Users could “change” the colour or transparency of the projected versions of objects using barcode cards, but then the digital colour differed from the real colour of the object. Wagner et al. conjecture that the use of non-real world tokens does not favour experts and places all participants on equal footing; however, 11  2.3. Planning Support Systems: Collaborative Systems it requires long training sessions and tutorials to become familiar with the system.  2.3.5  Virtual Environment  The Virtual Environment (VE) system by Drettakis et al. [7] was, in large part, designed to demonstrate a real-world research task that may benefit from virtual reality technology. The researchers chose the domains of architecture and urban planning for this purpose and underwent an iterative, user-centered development process. The VE was designed to facilitate a Tramway construction project in Nice, France. It displays high quality graphics of the 200m x 200m city square, offers three view types (2D top-down, 3D ground-level, 3D balcony-level), and a limited number of interactive digital elements (benches, umbrellas, trees, and crowds) that users can add to, remove from, or move within a scene. Users navigate the system using a game controller with four active buttons and a joystick. Drettakis et al. conducted a controlled lab study and a field deployment study. In the field study stakeholders used the VE to decide where to place trees and ground elements around the Tramway, and ultimately presented several different scenarios to high-ranking officials who took turns viewing them. The iterative and user-centered methodology proved very effective in designing a system that was considered to be useful by its intended participants. Functionality was added or modified during the development process and a functional and complete system was delivered. All studies of the VE were conducted with real users as participants. One downside of the system is its lack of control over most of the environment; it cannot be used to create and compare alternative designs of the Tramway location or building configurations, only a small set of dynamic elements around the fixed development model are available. While this functionality was likely suitable for the needs of the end users in this situation, it limits the VE’s extensibility to other more complex urban planning projects. Another downside of the VE is its inability to conduct collaborative research easily. It has a single input controller and the immersive 3D perspective involves head tracking and stereo glasses. Similar to the prediction model PSS systems described above, it is best suited for individuals creating alternative designs and presenting them to stakeholders to analyse independently. Existing collaborative planning support systems tend to present visual and immersive results but offer a limited set of functionality. While the 12  2.3. Planning Support Systems: Collaborative Systems use of tangibles in some of the collaborative systems is desirable, they can be difficult to accurately track, limit the scale of the working area, make comparisons of alternate designs difficult, and may have different properties than their digital counterparts. The design of our collaborative planning support system we developed builds upon the ideas and lessons surveyed in the literature. We developed a system that encourages co-located collaboration on a multi-touch tabletop enabling users to follow social protocols. We offer an adequate amount of functionality for conducting neighbourhood design, present both numerical and visual outputs, and offer the ability to easily compare neighbourhood design alternatives. The next chapter discusses the details of the system design for which this chapter has provided the background rationale.  13  Chapter 3  System Design In this chapter we describe the work of the elementsLAB [10], a research group within the School of Architecture and Landscape Architecture (SALA) at the University of British Columbia (UBC), along with the member’s motivation, research goals, and the current types of tools that they use in their research. We also describe the iterative design and development process we employed in order to develop a prototype design tool to help facilitate a portion of their collaborative design process.  3.1  ElementsLAB  In British Columbia, Canada and many other jurisdictions, governments have adopted policies to mitigate the environmental impacts of urbanized areas [11]. To achieve these policies, communities make difficult choices about growth and land use, often involving increasing the density and types of land uses. While the professional community believes this may improve the quality of the urban environment, the general public can be often skeptical. Many jurisdictions have adopted participatory, consensus-based planning processes such as visioning sessions, public workshops, and design charrettes to work through decision-making about land use planning. A charrette is a collaborative design session that engages a variety of stakeholders or citizens in an urban planning project. Such planning processes are commonly used to define public policies, design new neighbourhoods, or renew existing neighbourhoods. Current processes often involves presenting professionally prepared plans and receiving public input on those plans. Decisions made in this manner may impact individual quality of life, access to housing, or property values as well as issues related to community livability, climate and air quality, or impacts on water supply. The elementsLAB [10] is an urban form and environment research group in SALA at UBC. Professors Ronald Kellett and Cynthia Girling are principal investigators. The research conducted by the elementsLAB works to educate and facilitate communication between professionals and stakeholders 14  3.2. ElementsLAB Public Engagement Process who are responsible for generating and evaluating future land use scenarios, often through the use of appropriate tools. The elementsLAB team designs and evaluates tools through which all participants can meaningfully engage in complex and information-intensive discussions. Such tools are designed to enable participants to visualize, analyze, measure, and compare different scenarios while communicating with each other. The tools must be adaptable to each project and participant group and present sufficient information to inform decisions. The information they present must also be comprehensible by a homogeneous group of people with a variety of expertise. The tools that the elementsLAB team develops, particularly elementsdb [8], are highly visual yet grounded in quantitative methods to model and evaluate performance against indicators of sustainable development. Elementsdb is a reference database providing examples of field-measured buildings to aid in the development of sustainable urban plans [9]. When linked to land use maps, elementsdb helps groups visualize, measure and compare competing alternatives with respect to land use diversity, transportation, environmental quality, infrastructure and cost.  3.2  ElementsLAB Public Engagement Process  Most engagement processes conducted by the elementsLAB team follow a similar sequence as outlined in Figure 3.1. First, information about policies and planning issues is gathered, cross-referenced, and shared. Then alternative arrangements of land use are generated and compared, typically with public consultation. Eventually a preferred alternative emerges and it is refined until it can be approved and developed. Existing tools for supporting public engagement during these processes are typically paper-based. The neighbourhood is designed by placing pieces of paper representing buildings on a large paper map of the neighbourhood. A variety of paper-based techniques are also used to solicit feedback. Such techniques include filling out survey forms to acquire preferences and goals, brainstorming to generate issues and concepts, design techniques for generating alternatives, and drawing, mapping and physical modeling techniques for visualizing the alternatives.  15  3.2. ElementsLAB Public Engagement Process  Figure 3.1: The collaborative design process employed by the elementsLAB team. They begin by consulting with city planners and stakeholders, defining goals and objectives. They then generate and visualize neighbourhood design alternatives, measure and evaluate them, and then finally develop the preferred alternatives that best meet the predefined objectives.  The quality and integrity of these processes depends in large part on the level of understanding, communication and consensus among the people involved. The effectiveness of decisions made often depends on the rigor and timeliness of evaluations during the iterative process. Specifically, techniques and tools are needed to equitably measure and compare the alternatives and therefore educate participants about the many implications embedded in the decisions that they make. Analyis-oriented tools, such as the PSS prediction models described in Section 2.2, can also be used to create urban design alternatives. They are capable of linking multiple performance variables, such as land use, transportation and air quality. However, they are ill-suited to public planning processes because they are very complex, have a high learning curve, require experts to operate them, and are usually designed for a single user. They are too coarse for the neighbourhood level but are best used to model at a regional scale. They do not link the interaction between the quantitative data and the development pattern layout. The five most important bottlenecks of existing PSS prediction systems as identified by Vonk et al. [37] are: 1. Experience within the organization. Stakeholders, or other users of PSS software, should have ample experience with it in order to fully comprehend it and use it appropriately. Unfortunately, many city planners are not even aware of the existence of most PSSs. 16  3.3. Support Tool Design 2. User friendliness of the system. The software should have an intuitive interface, adequate training materials and documentation, or require little instruction to begin using it. 3. Awareness of the full potential of the system. Stakeholders and planners should be aware of and understand all of the system’s capabilities. 4. Quality of the input data. The data that the PSS uses should be accurate, accessible, and relevant to its users. 5. Accessibility of the system. Some planners have a difficult time finding and using PSSs, potentially finding no value in them and rejecting them after an attempted use. The elementsLAB, along with other urban planners and sustainability researchers, are in need of tools that combine as many as possible of the positive aspects of both design- and analysis-based planning tools while enabling effective, inclusive collaboration. This is the goal of our research.  3.3  Support Tool Design  In this section we describe the application design process we carried out in order to build an initial prototype of a collaborative urban planning tool for the elementsLAB. We created an application for a multi-touch tabletop keeping in mind the considerations related to multi-touch tabletop applications and collaborative tasks raised in Section 2.1 while also attempting to mitigate the PSS pitfalls described in this chapter.  3.3.1  Iterative, User-Centered Development  We employed an iterative and user-centered software development process, engaging the members of the elementsLAB in each step of the application design to ensure it met their needs as closely as possible. We began by conducting a user observation session in which six members of the elementsLAB carried out two simulated design scenarios for the Sunset neighbourhood in Vancouver, BC, an area they had previously studied. The neighbourhood is bounded on the north by 45th Avenue, on the south by 57th Avenue, on the west by St. George Street, and on the east by Argyle Street. The elementsLAB members used the same materials they had used previously in a real design session, including a large paper map of the area 17  3.3. Support Tool Design and small pieces of paper that represented buildings. The paper building pieces each contained information about a building, including its population, number of jobs created that will be housed in the building, number of floors, and floor-to-area ratio. The group began the design process by discussing its goals: add 550 people to the population, add an undefined number of jobs, add commercial services, and add a 1 hectare park. The goals were written on a large whiteboard to the left of the group members, who sat in a U-shape around the table. The goals were referenced often throughout the session. The paper building pieces were pseudo-sorted by land use type, messily laid on the left side of the map, and were accessible to only two of the group members. Group members first discussed the overall design and general layout. They then discussed and agreed on the placement of specific buildings, after which one of the members closest to the building pieces would hand them to another member who would tape them to the map. Periodically, the group would stop the process and a member would tally the quantitative data; that is, see how close they were to reaching their population, job, and density targets. They used a pen, paper, and calculator for this purpose. A ruler was used to help calculate the density target; this was time consuming. They checked their totals against the whiteboard, discussed their next steps, and then continued. The process repeated itself until all goals were met. For their second scenario, they set new targets on the whiteboard, peeled the taped building pieces off of the map, and carried out the same design process again. After the observation session we generated a set of functional and technical requirements. The elementsLAB team gave us digital copies of the building images that were printed on paper, along with their specifications, and a digital map of the Sunset neighbourhood in Vancouver. With this data we were able to develop the first version of our prototype planning system. We underwent several iterations over the next several weeks, presenting the latest version of the system to the elementsLAB and obtaining feedback for enhancements or modifications. Ultimately, our system contains functions that actively help users achieve quantitative goals (population and job targets) and contains affordances that passively help users achieve quantitative, sustainability goals.  3.3.2  System Design Discussion  In addition to the feedback from the elementsLAB, we considered other aspects of PSS systems, SDG, and the urban planning process in general in 18  3.3. Support Tool Design our application design approach. To enable collaboration, we decided to use a multi-touch table as the basis of the support tool because it offers excellent affordances. Its size allows up to six people to be standing or seated at the table at once. Its ability to handle multiple simultaneous input points offers not only complex gesture interactions from single users, but also allows many users to interact with it at once. Because inputs come from fingers, users get the hands-on design experience that they’re used to with classic charrette methods. Also, as discussed in Section 2.1, touch input supports equality of collaboration. Unlike the digital/physical augmented systems described in Section 2.3, we decided for several reasons to use an entirely digital system. First, data can be viewed at a variety of scales because the digital map can be zoomed, a feature that we know from prior research is important. If tangibles were involved, the scale would be fixed because physical models cannot change size. Even if tangibles of varying size were used, the scale would still be very limited. Additionally, a digital design pattern is versatile: it can easily be saved, restored, altered, sent to distributed stakeholders, and viewed in its original form on a different device. Indeed, our prototype can be emulated on a PC so it can be used by individuals or projected on a wall display for viewing or for an alternative collaborative experience. The digital representation also enables easy comparison of design alternatives. Within a single instance of the application alternatives can be compared, or the data can be output to a file and compared offline. Finally, because the application runs on a single standalone device, the tabletop could be easily be transported to a design workshop offsite with no additional tools or equipment needed. We concluded that a complex computational PSS like those in Section 2.2 would not be appropriate for a collaborative design tool that would be used by many different stakeholders or citizens, with a variety of expertises, in hands-on workshops. A system with a smaller scope and a limited set of robust functionality with real-time output of key data was considered most appropriate. Our system addresses each of the PSS bottlenecks: 1. Experience within the organization. Our system is not so complex that years of urban planning education are required to use it. In addition, it requires very little training to begin using it effectively. 2. User friendliness of the system. The interface is intended to be intuitive and needs little or no supplementary documentation. The hands-on nature of the system is natural and interactive. 3. Awareness of the full potential of the system. The limited 19  3.3. Support Tool Design complexity of the system is a feature; it is easy to quickly understand all functionality of the system. 4. Quality of the input data. The data comes directly from the elementsLAB so it is expected to be accurate and relevant to their needs. 5. Accessibility of the system. Our system is designed to be easy to use and understand.  20  Chapter 4  Prototype Implementation In this chapter we describe the hardware used and software created for our prototype collaborative planning support system, which we call the ‘pattern creation application’. The system enables urban planners, stakeholders, and private citizens to design spatial patterns of proposed neighbourhood development, or patterns. The system is based on multi-touch technology and its design follows lessons learned in the previous chapters.  4.1  Hardware  We used a SMART Table for our prototype, a proprietary multi-touch table created by SMART Technologies. The table is 91.5 cm x 74 cm x 65.4 cm (length x width x height) and the screen is 57.2cm x 42.9cm with a 1024 x 768 resolution. The table recognizes touch inputs using SMART’s proprietary Digital Vision Touch (DViT) technology, which is based on frustrated total internal reflection (FTIR) [14]. At a 20◦ viewing angle from the horizontal the screen’s perceived brightness is 50% of that for a 90◦ (vertical) viewing angle.  4.2  Software  The application was developed with an object-oriented approach entirely in C# using the SMART Table SDK. The code base consists of 15 classes, 135 methods, and 4795 lines of code (including comments). The user display consists of a main central map area for neighbourhood designs and three surrounding working areas: the building menu, the data chart area, and the overview and saved pattern area. A screenshot of the pattern creation application on start up is shown in Figure 4.1.  21  4.2. Software  Figure 4.1: Screenshot of the pattern creation application on start up. The application has a central map and three surrounding working areas; (A) the building menu on the left; (B) the overview and saved pattern area on the bottom; and (C) the data chart area on the right.  4.2.1  Building Menu  The building menu is designed to aid users in their selection of buildings to arrange in the map, both by presenting all buildings in a meaningful way and by providing affordances. Such affordances help users identify building type diversity and which building types may or may not be good candidates for selection. There are 12 building types to choose from, including 9 residential, 2 mixed use, and 1 commercial. They are arranged in that order ‘vertically’ relative to the map so that the commercial building type is south from the residential building types. Because there is text in the building menu it must be oriented appropriately. There are two parts to the building menu: the scroll bar and building 22  4.2. Software details (see Figure 4.2). The scroll bar is used to navigate through the building details. It consists of 12 solid coloured rectangles, where each rectangle represents a building and its colour represents the land use type and density. We maintained the building colour scheme established by the elementsLAB, an overview of which is shown in Table 4.1. Residential buildings are yellow, mixed use orange, and commercial buildings are red. Residential buildings have one of three different density types, low, medium and high, which are represented by the saturation of colour. The darker the colour, the higher the density. We defined colours to differentiate the three dwelling types: stacked, attached, and detached (blue, purple, and pink, respectively). Stacked buildings have four or more stories (and a medium or high density) while attached and detached buildings are single-family residential homes. The dwelling types are visible in the building details section of the menu. There is also a chart in the chart area that indicates the distribution of dwelling types. In the data we obtained from the elementsLAB, there are no building types of medium or low density for mixed-use or commercial buildings.  Density High Med. Low  Building Type Residential Mixed Use Commercial -  -  Dwelling Type Stacked Stacked Attached/Detached  Table 4.1: Outline of the colour scheme established by the elementsLAB that is used to represent buildings. We defined the colours that differentiate stacked, attached, and detached dwelling types. There are no building types of medium or low density for mixed-use or commercial buildings.  A user can interact with the scroll bar to navigate the building details by dragging a black rectangle, or scroll window, or by tapping on a rectangle (which represents a building type) to center the scroll window, and the building details, on that building type. The area inside the scroll window represents the buildings that are visible in the building details section of the menu. The building details section displays information about each building, including: its image; the dwelling type (detached, attached, stacked); the number of people it houses (e.g. 78p, A in Figure 4.2); the number of 23  4.2. Software jobs it creates (e.g. 0j, B in Figure 4.2); and how many instances of that building type are currently in the map. The latter can be used to help users ensure a diversity of housing types. Adjacent to the population and job values are numbers in parentheses that indicate how many of that building could be placed in the map before the respective target value is reached (e.g. (17), A in Figure 4.2). If that number is highlighted in blue, then 5 or less of that building type can be placed before the target is reached. This affordance notifies users that they are close to reaching a target value and thus a building type with highlighted parameters may or may not be a good candidate for selection.  24  4.2. Software  Figure 4.2: The building menu, with scroll bar and building detail section. The scroll window is used for navigation. The number next to A indicates the number of people a building houses and the number next to B indicates the number of jobs that building creates.  The low density residential buildings also have a pull tab icon attached to them. These pull tabs can be dragged out in order to obtain a group of adjacent buildings that can be interacted with as if it were a single building. 25  4.2. Software This makes it easier to translate and rotate smaller buildings, which are typically arranged together in larger groups. As the pull tab is extended, a multiplier representing the current number of buildings in the block is visible just above the finger. In addition, the details of the building are updated to reflect the size of the block. For example, in Figure 4.3a, the pull tab is not extended so the population and job numbers values are unchanged. When the pull tab is extended to (for example) 3 times the length of the building several things occur: the block contains 3 buildings; the population and job values are both multiplied by 3; and the numbers in parentheses (representing the number of instances of that building type that could be placed in the map before a target value is reached) are divided by 3 (Figure 4.3b). The maximum length of a group of buildings that can be pulled is the maximum street block length in the map.  (a) Pull tab not extended  (b) Pull tab extended to 3  Figure 4.3: Example of the pull tabs for low density residential buildings. The pull tab shown in (a) can be extended, as shown in (b), to create a block of a particular building type that is interacted with as a single object. The building details in the map are updated accordingly and a block multiplier is visible just above the finger. Buildings are placed in the map area simply by dragging their images 26  4.2. Software from the detailed menu onto the map. When the finger is dragged off of a building image in the menu, a copy of it is made and placed underneath the user’s finger. The building copy is automatically scaled to match the current map zoom level.  4.2.2  Map  The map image shows an area of the Sunset neighbourhood in Vancouver, BC near Knight St. and 49th Ave. The map area of the application is 710 x 625 pixels and the interactive map image is 5000 x 5000 pixels. The map image is from VanMap [36], a web-based map system for Vancouver. It has been modified by a member of the elementsLAB so that the area to be developed is highlighted. The blocks to be developed are outlined and coloured according to their current land use type: yellow for residential, orange for mixed use, and red for commercial. A zoomed and cropped version of the map image showing just the development area is shown in Figure 4.4.  27  4.2. Software  Figure 4.4: A zoomed and cropped version of the map used in the pattern creation application. The intersection at Knight Street and 49th Avenue. is in the top right (circled). The image, from the web-based VanMap system, has been modified by a member of the elementsLAB to highlight the existing land usage.  28  4.2. Software  4.2.3  Charts  There are four charts that display quantitative pattern data in the chart area: Population, Jobs, Land Use, and Dwelling Types. The Population and Jobs charts help users track the quantitative targets for their neighbourhood design. These charts have a dashed line to indicate the target value so users can track how close they are to reaching the targets. There is a small buffer area above the dashed line so that if one of the values goes above the target, users have a visual aid to see how far above the target they are. The current population or job count is displayed in the bar. The Land Use and Dwelling Type charts show ratios of building distributions to help users achieve a diverse range of housing types, a qualitative target. The Land Use chart shows the distribution (percentage, based on size) of residential, mixed use, and commercial buildings. The Dwelling Types charts shows the distribution of detached (pink), attached (purple), and stacked (blue) buildings. All charts can show up to four bars. The leftmost bar of each chart shows the values and distributions for the current building arrangement in the map area. This column of bars is denoted by the letter C, for ‘current’. The remaining three bars show Figure 4.5: The chart area the values and distributions for up to three with two saved patterns. The saved patterns. Once a pattern is saved, its population and job targets are chart data is saved and its column of bars is 1200 and 400, respectively. given an ID (either 1, 2, or 3). An example of a chart area with two saved patterns is shown in Figure 4.5. The chart data is updated automatically any time one or more buildings are added to or removed from the map. Users cannot interact with the chart directly; it is for display purposes only. 29  4.2. Software  4.2.4  Saved Patterns  This feature supports the iterative design process employed by the elementsLAB. By default, the saved pattern area shows a small icon, labelled C, which is an overview of the current pattern in the map area. This 108 x 108 pixel icon is correlated with the data in the leftmost column of bars in the chart area, which is also labelled C. Each time a building is added to or moved in the map, the icon is updated along with the chart data. A pattern in the map can be saved at any time by touching the Save Pattern button in the lower right corner. Once the button is pressed, a new icon representation is saved in the appropriate area, assigned an ID (1, 2, or 3), and its chart data is saved in the appropriate column in the chart area with the same ID. We chose to automatically assign IDs to the saved patterns rather than allow users to specify names to keep the interactions with the system as simple as possible. To support custom names, either a digital touch keyboard would have to be implemented or a USB keyboard would have to be used. For the purposes of this prototype we chose to automatically assign the IDs. Up to 3 patterns can be saved at one time, which is sufficient as per the elementsLAB team and their needs. The saved pattern icons have 35% opacity to help distinguish it from the current pattern icon, which is fully opaque. A saved pattern can be restored or deleted by dragging its icon. As the icon is dragged, it is represented by a colored hollow square. If the square is green, the finger dragging it is in the map area, so if it were released the pattern would be restored to the map, deleting the map’s current contents. If the square is red, the finger is in the chart area to the right of the map, so the pattern (its icon and chart data) would be deleted. If the square is blue, the finger is in a neutral area and no action will occur if it is released. These three cases are shown in Fig 4.6.  30  4.2. Software  (a) Restore pattern  (b) Delete pattern  (c) No action  Figure 4.6: Example of the three actions that can be performed on a saved pattern icon: (a) a green square means restore a saved pattern to the map 31 area; (b) a red square means delete a saved pattern; (c) a blue square means take no action.  4.2. Software  4.2.5  Single-Touch Interaction Techniques  The building pieces, once in the map area, can be translated and rotated using one or more fingers. For single-touch, we used the SMART Table SDK’s built-in RNT behaviour. RNT, or Rotate N’ Translate as desribed by Kruger et al. [19], allows users to simultaneously rotate and translate building objects by touching them near any edge and dragging. Translation only (with no rotation) can be performed by touching and dragging an object near its center. Panning of the map is performed by touching one finger on the map and dragging. We implemented a scroll bar, placed in the upper right portion of the map, for single-touch zooming of the map. The scroll bar is dragged down to zoom out and up to zoom in. Because we implemented the singletouch zoom feature ourselves, we were able to set reasonable scale limits for the map. The maximum scale for single-touch zooming is 2x (making the map image 10000px x 10000px) and the minimum scale is 0.1x (making the map image 500px x 500px).  4.2.6  Multi-Touch Interaction Techniques  Translation and rotation of building pieces in the map area can also be performed with multiple fingers. When two or more fingers are placed on a building piece, it is rotated or translated based on their movement. The behaviour of the building pieces on the tabletop display when dragged by multiple fingers is much like the behaviour of pieces of paper on a regular table that are dragged by multiple fingers. The map can be scaled with two fingers using the common “pinch-zoom” technique that first appeared in the VideoPlace system developed by Krueger et al. [18]. Pinch-zoom is performed by placing two fingers on the map and moving them away from each other to zoom in, or moving them closer together to zoom out. The pinch-zoom can be done with fingers on the same or opposite hands. We did not have sufficient control over the SMART Table SDK to limit the scale for multi-touch zoom feature.  4.2.7  Multi-User Parallelism  The multi-touch nature of the application not only permits complex gestures for building and map manipulation, but it also enables multiple people to interact with the application simultaneously. Users could potentially use the application in parallel to conduct neighbourhood design, simultaneously accessing the menu and manipulating building pieces. 32  4.2. Software  4.2.8  Summary  This chapter discussed the details of our prototype collaborative planning support system. The following chapter describes the design of our experiment which investigates the effect of single-touch and multi-touch instances of the prototype on collaboration and output quality.  33  Chapter 5  Experiment 5.1  Overview  We conducted a laboratory study to compare single-touch and multi-touch modes in the collaborative task of urban planning conducted on a multitouch table. Simultaneous touch inputs permit not only multiple users to interact with a device at the same time, but also allow for more complex gestures involving multiple input points. We compared differences in the quality of output, amount of collaboration, task completion time, and user preferences when participants created neighbourhood patterns in single-touch and multi-touch versions of the pattern creation application described in Chapter 4. Three informal pilot studies were conducted with Computer Science graduate student colleagues and a formal pilot study was conducted with compensated graduate students from SALA. The pilot studies were carried out to test the functionality of the system. They brought forth issues with the interface that were subsequently addressed in the iterative development process. They also served to test the feasibility of the neighbourhood design tasks that were used in the laboratory study to ensure they were of appropriate difficulty and could be completed in a reasonable amount of time.  5.2  Hypotheses  Because users could simultaneously interact with the application in the multi-touch version, each user having the opportunity to actively participate in the design process, this could potentially lead to more collaboration. However, it might be the case that users would collaborate more in the single-touch condition because it might force them to engage in turn taking and be more aware of each other’s actions.  34  5.3. Method H1: Collaboration. Users will collaborate more in the multi-touch condition than in the single-touch condition. The increase in collaboration postulated in H1 may tend to produce better results. H2: Quality of patterns. The quality of the neighbourhood patterns created in the multi-touch condition will be higher than the quality of the patterns created in the single-touch condition. Because users could potentially work in parallel in the multi-touch condition, we anticipate that patterns will be created faster in that condition. H3: Task completion time. Sessions in the multi-touch condition will take less time than sessions in the single-touch condition. Because urban planners are familiar with paper-based methods of neighbourhood design where they manipulate paper building pieces with their hands, they may find the multi-touch interactions with digital building pieces easier and more intuitive. H4: Building interactions. Multi-touch interactions with the building pieces will be preferred over more traditional single-touch interactions.  5.3  Method  Our within-subjects study had 3 interaction conditions, 3 neighbourhood design tasks, and 3 trials. One interaction condition (paper-based) and neighbourhood design task (training, with a simpler set of quantitative targets) were always used together in the first trial. They were for training purposes and were not part of our analyses. The two touch conditions and two more difficult experimental tasks were fully counter-balanced for the latter two trials to reduce learning effects. The touch conditions were a singletouch version of the table application and a multi-touch version. They were identical except in the number of simultaneous contact points recognized. Participants worked in pairs to complete the three neighbourhood design tasks by selecting buildings and arranging them in a map such that specified quantitative and qualitative targets were met as closely as possible. The tasks differed in their quantitative targets and the number of design 35  5.3. Method alternatives pairs were asked to create for a given set of targets. The training task asked participants to create a single design alternative and the two experimental tasks asked participants to create two design alternatives for the set of targets. There were four possible experimental treatments (see Table 5.2). Participants worked in pairs. Sessions were expected to take approximately one hour. Participants were given four pages of written background material, including a description of the qualitative targets, 24 hours before their session. The background information briefly described and illustrated the Sunset neighbourhood of Vancouver, the area that they would be re-designing in the tasks. During their session participants were given additional copies of the materials. They were each given a written description of the quantitative targets on a piece of paper before each task. The target values were also visible in the chart area of the tabletop application.  5.3.1  Participants  Eight pairs of participants aged 23 to 43 (µ=28), 7 female and 9 male, took part in our study. All eighteen participants were recruited via email sent by our colleagues in the elementsLAB to graduate and undergraduate students in SALA as well as to graduate students in the School of Community And Regional Planning (SCARP). All participants were current or former UBC students from SALA, SCARP, the Department of Geography, or the Faculty of Forestry. Participants were compensated with $10 gift cards from Starbucks.  5.3.2  Software, Hardware, and Materials  The pattern creation system, described in Chapter 4, was used in the experimental tasks. In the training task, an 80cm x 80cm laminated paper map of the Sunset neighbourhood in Vancouver printed at a 1:1000 scale was used along with paper cut-outs that represented buildings. This was approximately the same size as the display, which was 91.5cm x 74cm. An image of the paper map is shown in Figure 5.1. The cut-outs were printed in colour on 100 pound paper stock and were 3.3cm x 6.0cm, on average, also at a 1:1000 scale. In addition, for the paper-based condition, participants were provided with blank paper, pens, and a calculator to aid them in calculating the population and job sums.  36  5.3. Method  Figure 5.1: The 1:1000 scale laminated paper map of the Sunset neighbourhood in Vancouver that was used for the paper-based training task of the user study. Paper building pieces were arranged at the sides of the map, with stacked dwellings on the left and attached/detached dwellings on the right.  5.3.3  Procedure  At the start of a session participants were asked if they had read the background material. At the start of the first trial, the paper-based condition, participants were instructed on the nature of the neighbourhood design task and the colour coding conventions used for the buildings. At the start of each of the touch conditions participants were instructed on how to use the system and how to perform interactions with the digital buildings. They were able to practice for as long as they liked. Each instance of training took less than five minutes. Participants were told each task would take approximately 15 minutes. If 15 minutes elapsed before they were finished any of the trials , they were so informed, although they were not forced to finish prematurely. Major Independent Variables Interaction condition. Participants completed neighbourhood design tasks in three interaction conditions: one training condition and two touch conditions. They are described as follows: 37  5.3. Method 1. Paper-based (P). This was a training condition that used a traditional paper-based approach. This condition was always the first trial. 2. Single-touch (S). This condition used the SMART Table and a version of the pattern creation system that recognized only a single touch. Only one participant could interact with the table at one time and gestures on the table were performed with only a single finger. 3. Multi-touch (M). This condition used the SMART Table and a version of the pattern creation system that recognized simultaneous touch inputs touch. Both participants in a pair could interact with the table at the same time and gestures on the table could be performed with multiple fingers. Neighbourhood Design Task. The three neighbourhood design tasks required participants to select buildings to arrange in the map such that quantitative and qualitative targets were met as closely as possible. The quantitative targets were population and job target values. An outline of the tasks, their quantitative requirements, and the conditions they applied to is shown in Table 5.1. They are described as follows: 1. Task A. This task had simple targets and asked participants to create only a single design alternative. This task was always in the first trial. 2. Task B. This task had more complex targets than task A and asked participants to create two design alternatives. 3. Task C. This task had more complex targets than task A and asked participants to create two design alternatives.  Task A B C  TASK DETAILS Population Target Job Target 850 100 1200 400 1700 200  Alternatives 1 2 2  Table 5.1: Outline of the training and experimental tasks, their quantitative targets, and the number of alternatives participants were asked to create.  38  5.3. Method  Treatment 1 2 3 4  Trial 1 Task Cond. A P A P A P A P  Trial 2 Task Cond. B S B M C S C M  Trial 3 Task Cond. C M C S B M B S  Table 5.2: Outline of the four experimental treatments. Pairs of participants took part in one of four treatments, each consisting of three trials. The first trial was always the paper-based training condition P with task A, the simplest task. The remaining two trials fully counter-balanced experimental tasks B and C and touch conditions single-touch S and multi-touch M.  Task Description The tasks and targets were defined by our colleagues in the elementsLAB and were based on a realistic scenario of redeveloping an 11-block, 22-hectare area of the Sunset neighbourhood in Vancouver, British Columbia. The quantitative goals were population and job target values, while the qualitative goals were six key sustainability principles that participants were asked to adhere to as much as possible. The sustainability principles, illustrated in Figure 5.2, were: 1. Jobs. Developing commercial and mixed use buildings near residential units places a variety of employment opportunities near houses, reducing the time spent travelling to work. Developing them along corridors encourages the use of public transit to travel to work. These development patterns help to reduce transportation energy usage. 2. Corridors. Developing high density commercial and residential buildings along corridors focuses traffic along those routes and also creates the appropriate density for public transit systems. The corridors in the Sunset neighbourhood are Knight Street and 49th Avenue. 3. Walkability. Maintaining the interconnected street system layout and placing commercial/mixed use buildings near residential units links residents to the services they need. Street systems that place homes in close proximity to those services encourage residents to walk to their destinations, greatly reducing transportation energy use. 39  5.3. Method 4. Green Space. Maintaining or setting aside blocks for green space provides recreational opportunities for residents and connects them with natural systems. 5. Infrastructure. Integrating existing or developing infrastructure elements such as drainage, power, and sewage systems into the development plan reduces overall infrastructure costs as well as environmental impact. 6. Housing. Developing a range of housing types allows residents in differing economic situations to live in the same neighbourhood and have access to the same services. Good neighbourhood design recognizes current and future demographic trends, creating a mix of housing types allowing residents to live in the neighbourhood throughout their lives.  Figure 5.2: The six sustainability principles, derived from a book authored by a team at the Design Center for Sustainability [6]. Participants were instructed to adhere to these principles in their neighbourhood design tasks.  40  5.3. Method Participants filled out a total of five questionnaires throughout their session. Before the start of a session, one questionnaire was given to participants to obtain demographic information. After each of the three trials another questionnaire was given to collect information regarding participants’ opinions on the speed and difficulty of the task, as well as their thoughts on how good they believed their solution was and how much they felt they collaborated with their partner. The THREE post-trial questionnaires were identical. At the end of the session, a post-session questionnaire was given to gather user preference data between the two table conditions for a variety of categories, including speed, collaboration facilitation, ease of use, and ease of interactions with application elements. Experimental Setting The experiment was conducted in a dedicated laboratory in the X-wing of the ICICS/CS building at UBC. The touch table was placed near a wall in the room. For the paper-based training task, the paper map and building pieces were placed on top of the touch table to maintain consistency across conditions and so they would be visible to the video cameras. Participants were able to position themselves anywhere around the table except the side closest to the wall, though all participants chose to sit on the side opposite the wall, either next to each other or at the corners of the same side. Two video cameras were used in the study, both placed along the wall side of the table. One video camera was facing the tabletop and captured the screen and the participants’ interactions with it. The second video camera was facing the participants to capture their facial expressions, physical actions, and conversations. The questionnaires were filled out by participants at a regular table located 1.5m behind the SMART Table. An overhead layout of the experimental setup is shown in Figure 5.3. Images from video camera 1 are shown in in Figures 5.4 and Figure 5.5. Images from video camera 2 are shown in in Figures 5.6 and Figure 5.7. Results from the experiment were analysed and are discussed in the next chapter.  41  5.3. Method  Figure 5.3: Overhead view of the experimental setup. The two cameras were placed on a small table next to the wall. The SMART Table was placed in front of the cameras. A regular table was placed 1.5m behind the SMART Table for participants to fill out questionnaires.  42  5.3. Method  Figure 5.4: An image taken from video camera 1 during the paper-based training task. Here the participant on the left is placing buildings on the map and the participant on the right is summing the population and job values as they are placed.  Figure 5.5: An image taken from video camera 1 during a table condition. Here the participant on the left is watching the participant on the right place buildings in the map area.  43  5.3. Method  Figure 5.6: An image taken from video camera 2 during the paper-based training task. Here participants are working in parallel; they are both orienting the building pieces that the participant on the right placed in the corner block.  Figure 5.7: An image taken from video camera 2 during a table condition. Here participants are working in parallel; the participant on the left is retracting the pull tab for a residential building while the user on the right is placing a new block of buildings.  44  Chapter 6  Results & Discussion In this chapter we present the results for the experiment described in Chapter 5 and provide a discussion of those results. Although there were three interaction conditions, our experimental design tested only the two touch conditions. The paper-based condition was used solely to introduce participants to the task in a familiar setting. Similarly, one of the tasks was used only in the paper-based training trial, with the other two tasks used in the fully counter-balanced experimental trials. Our analysis was based on a 2 (interaction) x 2 (task) within subjects design for the experimental trials. Data analyses produced results that support hypothesis H4 (from Section 5.2). While the data analyses did not support H1, H2, or H3, participants’ perceived them to be true. That is, while participants did not actually collaborate more in the multi-touch condition, they believed that they did. They also perceived the neighbourhood patterns that they produced in the multi-touch condition to be of higher quality than the neighbourhood patterns that they produced in the single-touch condition. In addition, participants perceived that the neighbourhood design task they carried out in the multi-touch condition was completed faster than the design task in the single-touch condition. Participants also indicated on questionnaires that they liked the multi-touch application more than the single-touch application. These findings suggest that participants were more cognitively absorbed [1] in the neighbourhood design task that they carried out in the multi-touch condition than they were in the task that they carried out in the single-touch condition. Participants demonstrated a variety of turn-taking techniques and collaboration strategies in both touch conditions, many of which overlapped across conditions. We have shown that the restriction of touch inputs to enforce turn-taking and help facilitate collaboration is not necessary. There was no difference in the amount of collaboration or quality of output in either touch condition; however, participants’ perceptions of the touch conditions significantly favoured multi-touch.  45  6.1. Demographics  6.1  Demographics  Eight pairs of participants aged 23 to 43 (µ=28.56), 7 female and 9 male, took part in our study. Seven participants were undergraduate students or recently graduated from an undergraduate program and 9 participants were graduate students (6 MSc, 3 PhD). Fourteen of 16 participants had used a touch interface before and 7 use a touch interface (either a touch phone or a tablet PC) regularly. One participant who had not read the background material before the start of the session was asked to read it before beginning.  6.2  Experimental Task Completion Time  One-way ANOVA tests were conducted to measure the effects of touch condition, experimental task target set, and trial number on the completion time for the single alternative in the training task and for both alternatives of the experimental tasks. An overview of the first set of results is shown in Table 6.1. Over both experimental tasks, the average time taken to complete the first alternative (µ = 12:20, σ = 3:42) was significantly longer than the time taken to complete the second alternative (µ = 7:20, σ = 4:22), (F(1, 30) = 12.255, p < .001). This is likely due to participants becoming more adept at satisfying the task targets or because some pairs did not erase the map before creating the second alternative and instead simply made modifications to their first alternative design. Further analysis revealed that in the single-touch condition the completion time for the second alternative was significantly faster than for the first alternative (F(1, 14) = 8.5, p < .011), but in the multi-touch condition the completion time of the second alternative was only marginally faster (F(1, 14) = 4.099, p < .062). Also, the second pattern alternative in both touch conditions was created significantly faster for task C (F(1, 14) = 11.674, p < .004) though not for task B, and for the 3rd trial (F(1, 14) = 14.164, p < .002) but not for the 2nd trial.  46  6.2. Experimental Task Completion Time  COMPLETION TIME FOR EACH ALTERNATIVE (mm:ss) Effect N Alt. µ σ Sig 8 1 12:27 3:54 Single-Touch 0.011 8 2 7:10 3:18 Touch Condition 8 1 12:14 3:45 Multi-Touch 0.062 8 2 7:29 5:28 8 1 11:13 3:27 B 0.114 8 2 7:25 5:23 Experimental Task 8 1 13:27 3:50 C 0.004 8 2 7:14 3:25 8 1 13:17 3:41 2nd 0.093 8 2 9:30 4:41 Trial Number 8 1 11:23 3:42 3rd 0.002 8 2 5:09 2:51 Table 6.1: One-way ANOVA results comparing the effects of touch condition, experimental task, and trial number on the completion time of a single pattern alternative. The second pattern alternative was completed significantly faster than the first pattern alternative for the single-touch condition, task C, and the third trial. Statistically significant results are bold and highlighted in blue.  We also ran one-way ANOVA tests to measure effects of touch condition, experimental task, and trial number over individual average alternative completion times. An overview of the results is shown in Table 6.2. We found that the completion time for the second alternative in the 3rd trial was significantly faster than completion time for the second alternative in the 2nd trial (F(1, 14) = 5.005, p < .042). This may be due to participants becoming more familiar with and adept at the neighbourhood design tasks in general (a learning effect) or due to fatigue. We ran one-way ANOVA tests to measure effects of touch condition, experimental task, and trial number over the average alternative completion times, irrespective of their order. The average time taken to create a single pattern alternative in the multi-touch condition (µ = 9:51, σ = 4:26) was not significantly faster than the average time to create a single pattern alternative in the single-touch condition (µ = 9:48, σ = 5:09). This is a surprising result since in the multi-touch condition participants had the ability to work in parallel, potentially reducing the time spent completing the ex47  6.2. Experimental Task Completion Time perimental task. Perhaps there was no effect of condition on time because in either touch condition pairs engaged in design discussions before and during the tasks. The lengths of these discussions were not affected by touch condition. In addition, pairs were often observed engaging in turn-taking techniques during the multi-touch condition. We also conducted one-way ANOVA to measure the effect of touch condition, experimental task, and trial number on total experimental task time completion time (the sum of both pattern alternative completion times). There was a significant main effect of trial order on the time taken to complete both pattern alternatives in a single task (F(1, 7) = 11.586, p < .011, η 2 = .623). That is, pairs were faster completing the two alternatives in their second experimental task in the third trial, regardless of whether it was task B or task C. This is likely due to the pairs becoming more familiar with the neighbourhood and the neighbourhood design process, which is supported by post-session questionnaire comments. Because they did not tend to score lower on the second experimental task, the performance/time ratio increased. Details of these analyses are shown in Table 6.3. We found no interactions between any pairs or the three-way of touch condition, experimental task, or trial number.  48  6.2. Experimental Task Completion Time  COMLPETION TIME FOR Effect Single-Touch Multi-Touch Touch Condition Single-Touch Multi-Touch B C Experimental Task B C 2nd 3rd Trial Number 2nd 3rd  EACH ALTERNATIVE N Alt. µ σ Sig 8 12:27 3:54 1 0.912 8 12:14 3:45 8 7:10 3:18 2 0.893 8 7:29 5:28 8 11:13 3:27 1 0.243 8 13:27 3:50 8 7:25 5:23 2 0.939 8 7:14 3:25 8 13:17 3:41 1 0.318 8 11:23 3:42 8 9:30 4:41 2 0.042 8 5:09 2:51  Table 6.2: One-way ANOVA results comparing the effects of touch condition, experimental task, and trial number on the completion time of a single pattern alternative. The task completion time for alternative 2 was significantly faster in the 3rd trial than in the 2nd trial. Statistically significant results are bold and highlighted in blue.  COMPLETION TIME FOR Effect Single-Touch Touch Condition Multi-Touch B Experimental Task C 2nd Trial Number 3rd  BOTH ALTERNATIVES N Alt. µ σ Sig. 16 1 & 2 19:37 6:54 0.976 16 1 & 2 18:38 6:22 16 1 & 2 20:41 6:50 0.549 16 1 & 2 10:20 4:45 16 1 & 2 22:47 6:03 0.011 16 1 & 2 16:32 5:32  Table 6.3: One-way ANOVA results comparing the effects of touch condition, experimental task, and trial number on completion time of both pattern alternatives in a single task. Tasks in the 3rd trial were completed significantly faster than tasks in the 2nd trial. Statistically significant results are bold and highlighted in blue.  49  6.2. Experimental Task Completion Time Although the actual task completion time did not differ based on condition, failing to support H3, participants perceptions of the time taken to complete the tasks did differ. Participants thought that the multi-touch task was significantly faster than the single-touch task. The average posttask questionnaire score for the question “How fast was it to complete the task?” where 1 is very fast and 7 is very slow, was 3.438 for the single-touch condition and 2.563 for the multi-touch condition, which repeated-measures ANOVA revealed was significant (F(1, 15) = 6.176, p < .025, η 2 = .292). In the post-session questionnaire 15/16 participants indicated that the multitouch application was faster. A graph of the pattern alternative completion times is shown in Figure 6.1. For most pairs of participants, the first alternative in either touch condition was completed faster than the second, and the multi-touch condition alternatives were completed slightly faster than the respective single-touch alternatives. On the post-task questionnaires, the question “How much did you like the method used to complete this task?”, where 1 is “I liked it a lot” and 7 is “I really didn’t like it” yielded an average of 2.0 for the multi-touch condition and 3.0 for single-touch, which was significant (F(1, 15) = 4.444, p < .05, η 2 = .229). It is likely the case that participants were more cognitively absorbed in the multi-touch condition. Agarwal and Karahanna [1] define ‘cognitive absorption’ as “a state of deep involvement with software” exhibited through five dimensions: temporal dissociation, focused immersion, heightened enjoyment, control, and curiosity. In the multi-touch condition, the participants’ perception of time was faster and they enjoyed it more on average. We might conclude that participants were more cognitively absorbed during those tasks.  50  6.3. Quality of Patterns  Figure 6.1: Graph showing the pattern alternative completion times for each touch condition.  6.3  Quality of Patterns  Two experts in the elementsLAB independently scored each of the 32 patterns that had been created for each of the two alternatives for both of the experimental tasks for all 8 pairs of participants. Each set of scores was normalized relative to the maximum score given by the respective expert so that all scores were between 0 and 1. The correlation between the sets of 51  6.3. Quality of Patterns scores was investigated using a Pearson product-moment correlation coefficient. There was a large, positive correlation between the sets of scores (r = 0.73, n = 32, p < 0.0005). Their linear relationship is shown in Figure 6.2. (Cohen [5] suggests r = 0.5 to 1.0 indicates a large correlation, r = 0.3 to 0.49 indicates a medium correlation, and r = 0.1 to 0.29 indicates a small correlation.) Results from running repeated-measures ANOVA tests on the normalized pattern scores from both experts revealed no significant main effect of touch condition, experimental task, or trial number. The scoring data can be found in Table 6.4. Pearson correlation analysis indicated there was a medium correlation between the time taken to create a pattern alternative and its normalized score (r = 0.448, p < 0.01). This indicates that pattern alternatives that took longer to create tended to score higher, presumably because participants spent more time attempting to satisfy the quantitative and qualitative constraints. The normalized pattern alternatives scores were tested using one-way ANOVA to measure the effect of academic degree level on scores. Graduate students’ pattern alternatives scored significantly higher than undergraduate students’ pattern alternatives (see Table 6.5), possibly because they had more domain experience (F(1, 62) = 4.889, p < .031). We did not find touch condition to be a major factor in determining the score of a pattern so H2 was not supported; however, we did find that academic degree level and time were factors effecting score. In addition, on the post-session questionnaires, 73.3% of participants indicated they thought they produced their best solution in the multi-touch task, which repeatedmeasures ANOVA revealed to be marginally significant (F(1, 15) = 3.848, p < .069, η 2 = .204).  52  6.3. Quality of Patterns  Figure 6.2: This graph shows the linear relationship and large, positive correlation between the two sets of pattern scores generated independently by each expert (r = 0.73, n = 32, p < 0.0005).  53  6.4. Number of Interactions on Building Pieces  NORMALIZED EXPERT SCORES Effect N µ σ Single-Touch 16 0.610 0.277 Touch Condition Multi-Touch 16 0.563 0.249 B 16 0.518 0.239 Experimental Task C 16 0.655 0.270 2nd 16 0.588 0.293 Trial Number 3rd 16 0.585 0.234  Sig. 0.426 0.184 0.978  Table 6.4: One-way ANOVA results comparing the effects of touch condition, experimental task, and trial number on normalized pattern alternative scores.  NORMALIZED EXPERT SCORES Effect N µ σ Academic Undergrad 28 .508 .3411 degree level Grad 36 .648 .1475  Sig. 0.031  Table 6.5: One-way ANOVA results comparing the effects of academic degree level on normalized pattern alternative scores from both experts. Pattern alternatives created by graduate students scored significantly higher than those created by undergraduates. Statistically significant results are bold and highlighted in blue.  6.4  Number of Interactions on Building Pieces  To analyse the interactions with buildings pieces, repeated-measures ANOVA analyses were conducted with touch condition, task, and trial as withinsubjects independent variables. They were tested against several dependent variables for building elements, including total amount of translation in the X and Y directions (in pixels), total amount of rotation (in degrees), and the total number of touch instances for a building. The results of the ANOVA analyses are shown in Table 6.6 There was a significant main effect of condition on total number of pixels buildings were translated in both the X (F(1, 30) = 14.307, p < .001) and Y 54  6.4. Number of Interactions on Building Pieces directions (F(1, 30) = 11.583, p < .002), total amount of building rotations (F(1, 30) = 16.954, p < .0005), and the total number of touch instances for buildings (F(1, 7) = 8.915, p < .02). The number of times buildings were touched is the number of unique touch ‘instances’; for example, if a participant placed two fingers on a building to move it, that would count as just one touch instance. Participants did not touch, move, or rotate buildings significantly more with respect to task or trial order. It is likely that in the multi-touch condition participants manipulated the building elements more because they could work in parallel. These additional movements may have meant that more pattern layouts were investigated, leading to a higher quality output. Because the hardware was unable to identify which touch contacts came from which user, we were unable to conduct further analysis that thoroughly investigated the distribution of actions and parallelism among the pairs of participants. An interesting result is that the additional building movements did not influence the task completion time. This suggests that moving elements in the multi-touch condition was easier than in the single-touch condition. This is supported by the questionnaire data where users indicated they preferred the multi-touch rotation, translation, and scaling interactions over the single-touch methods. In the post-task questionnaires, the multi-touch interactions were generally found to be easier to perform over the single-touch interactions. A oneway repeated-measures ANOVA revealed that participants tended to find the multi-touch translation interaction easier than the single-touch equivalent, (F(1, 15) = 3.293, p < .09, η 2 = .18) and significantly preferred the multi-touch rotation interaction (F(1, 15) = 4.913, p < .043, η 2 = .247). The pinch-zoom method of scaling the map was significantly preferred over the single-touch zooming scroll bar (F(1, 14) = 6.792, p < .021, η 2 = .327). A one-way repeated-measures ANOVA was conducted on the post-session questionnaires data. We found that significantly many participants indicated that they preferred the multi-touch translation interaction (F(1, 15) = 6.0, p < .027, η 2 = .286), significantly many preferred multi-touch rotation (F(1, 15) = 6.0, p < .027, η 2 = .286), and significantly many preferred multi-touch scaling (F(1, 14) = 42.250, p < .0005, η 2 = .751). This supports H4.  55  6.4. Number of Interactions on Building Pieces  TOTAL X TRANSLATIONS (in pixels) Effect N µ σ Single-Touch 16 876141 472845 Condition Multi-Touch 16 3042867 2241995 B 16 1690241 1551990 Task C 16 2228767 2278293 2nd 16 2245245 2071949 Trial 3rd 16 1673762 1812956 TOTAL Y TRANSLATIONS (in pixels) Effect N µ σ Single-Touch 16 510662 289314 Condition Multi-Touch 16 1442814 1010832 B 16 936111 840991 Task C 16 1017365 926345 2nd 16 1036272 905653 Trial 3rd 16 917204 860890 TOTAL ROTATIONS (in degrees) Effect N µ σ Single-Touch 16 370527 207343 Condition Multi-Touch 16 1311523 890319 B 16 751892 572900 Task C 16 930158 981197 2nd 16 909458 776227 Trial 3rd 16 772592 833902 TOTAL NUMBER Effect Single-Touch Condition Multi-Touch B Task C 2nd Trial 3rd  Sig. 0.001 0.441 0.413  Sig. 0.001 0.797 0.706  Sig. 0.0005 0.535 0.634  OF TOUCH INSTANCES N µ σ Sig. 16 282.63 56.05 0.02 16 388.50 128.03 16 322.75 120.68 0.641 16 348.37 104.88 16 371.38 135.14 0.164 16 299.75 68.89  Table 6.6: Repeated-measures ANOVA results comparing the effects of condition, task, and trial on total building translation, rotation, and number of touch instances. Touch condition had a significant effect on all dependent 56 variables. Statistically significant results are bold and highlighted in blue.  6.5. Collaboration  6.5  Collaboration  Collaboration was quantified using six of the 12 methods described by RingelMorris and Winograd [26] that were most relevant to our work. We also analyse strategy type, another method, at the end of this section. We scored each pair for each task (once per condition) for each of these six methods: amount of talking, distribution of actions, re-orientation of objects, task outcome, time, and self-reports. The sets of scores for each method were normalized and then summed to create an overall score for collaboration that could be compared to other measures.  6.5.1  Amount of Talking  The amount that groups of participants talk to each other during a task can be a good indicator of the degree to which they are collaborating. We recorded the number of sentences spoken by each participant in each pair per task. Pairs spoke an average of 124 task-relevant sentences per task (min = 26, max = 251) with more sentences being spoken in the first trial (µ = 150, σ = 60.30) than in the second trial (µ = 97, σ = 54.25). Pearson correlation analysis revealed a correlation between the number of sentences spoken by pairs during a session and their average scores for a task (r = .475, p < .063). This means that pairs who discussed the task more with each other tended to produce higher quality results.  6.5.2  Distribution of Actions Among Group Members  A roughly equal distribution of user actions is another indicator of a high level of collaboration. For each task, we compared the number of building interactions, menu interactions, and map navigations (panning and zooming) that were conducted by each participant. To create a score for each pair for each task, we took the following steps: • Compute the absolute difference between the number of building interactions, menu interactions and map navigations for each partner in the pair (e.g. if one participant had 56 interactions with building objects, the menu and the map and their partner had 40 interactions, then we would take the difference, which is 16 in this case). • Divide that absolute value by the total number of interactions for the pair for that task (e.g. 16/96 = 0.1667)  57  6.5. Collaboration • Subtract that value from 1 so that lower ratios score higher (e.g. 1 0.1667 = 0.8333) • Sum the 3 values to obtain one distribution score per pair per condition • Normalize the entire set of scores so the minimum value was 0 and the maximum value was 1 A Pearson correlation revealed that there were no strong correlations between the equality of building interactions, menu interactions, or map navigations and the average task score. This may be due to the fact that pairs exhibited a variety of strategies while creating patterns, often employing several in a single task. Some of those strategies, described in detail in Section 6.5.8, involved one partner dragging buildings from the menu and the other arranging them in the map, which would indicate a high degree of collaboration but would give poor equality ratios for those interactions. We did not record which actions originated from which participant due to hardware limitations. The three interaction scores were summed and normalized for inclusion in the composite collaborative score.  6.5.3  Re-orientation of Objects  The number of times an object is re-oriented may indicate how much participants are actively collaborating on that particular object. In Section 6.4 we previously measured and presented results for the total translation in X direction, total translation in the Y direction, and total rotation. For the purposes of the composite collaboration score, we summed the measures for each task, and normalized the set of numbers.  6.5.4  Task Outcome  The outcome of the task can be an indicator of a successful/unsuccessful collaboration. In Section 6.3 we previously measured, averaged, and normalized the pattern scores for both alternatives in each experimental task. We included this measure in the composite collaboration score.  6.5.5  Time  The time taken to complete a task is not a straight-forward measure of collaboration, but it can be a relevant factor. Presumably the more participants collaborate the longer a task takes because they are engaging in 58  6.5. Collaboration discussions or trying out several scenarios. We assumed that a longer time indicated more collaboration; although parallelism reduces time. We previously measured and presented results for the time taken to complete a single pattern alternative for each experimental task and the correlation with pattern alternative scores in Section 6.2. For the purposes of the composite collaboration score, we normalized the total times taken to complete a task and added them to the composite score.  6.5.6  Self Reports  One way to get a measure for the amount of collaboration that occurred is to ask the participants themselves. At the end of each task in our study participants recorded on a 7 point Likert scale how much they felt they collaborated with their partner, where 1 represented “I did all the work”, 7 represented “They did all the work” and 4 “We did the same amount”. A one-way repeated-measures ANOVA revealed that there was no significant effect of condition on participants’ perception of collaboration (single-touch: µ = 4.06, multi-touch: µ = 3.94). In the post-session questionnaire, 75% of participants indicated that they felt they collaborated more in the multitouch condition. Both members of pair 4 felt that they collaborated more in the single-touch condition. For the composite collaborative measure, we averaged the two post-task responses for pairs for each task. We gave the optimal value, 4, a score of 1 and the remaining scores (3.5 and 4.5, the only other averaged values) a value of 0.5. Pearson correlation analysis did not indicate a correlation between the self-reported collaboration scores and the normalized pattern scores. This was not surprising because there was little variation in the self-reported collaboration measures.  6.5.7  Composite Collaboration Scores  The normalized scores for each pair, condition, and task for each of the 6 measures and their totals are shown in Table 6.7. Pearson analysis revealed a strong correlation between the total collaboration score and the averaged expert score for pattern alternatives in a task (r = .673, p < .004). This suggests that the more that pairs collaborated during a task the higher quality output they produced. A graph of the ordered pattern scores with their corresponding collaboration scores is shown in Figure 6.3. Repeated-measures ANOVA revealed that composite collaboration scores were higher for the multi-touch condition (µ = 3.394, σ = .961) than for 59  6.5. Collaboration the single-touch condition (µ = 2.915, σ = 1.168), though not significantly (F(1, 7) = 1.3, p < .292). Pairs in the multi-touch condition tended to collaborate more, as hypothesized in H1, and thus presumably tended to get higher overall scores on their neighbourhood patterns. In the post-session questionnaires, 12/16 participants indicated that they felt they collaborated more with their partner in the multi-touch condition than in the single-touch condition, which repeated-measures ANOVA revealed to be significant (F(1, 15) = 5.00, p < .041, η 2 = .25). Results from a Pearson correlation to analyse the correlation between the individual collaboration score components and the pattern scores is shown in Table 6.8. COLLABORATION SCORE COMPONENTS: OVERVIEW Amt. ReDistr. Task Self of orient. of AcOutReTime Sum Pair Cond. Talkof Obtions come port ing jects 0.2489 0.5176 0.0892 0.5918 0.1836 0.5 2.1311 1 1 0.5244 0.8267 1 0.7347 0.8138 1 4.8996 2 0.2044 0.1591 0.0346 0.7347 0.2101 0.5 1.8429 1 2 0.4711 0 0.6151 0.5918 0.8614 0.5 3.0394 2 1 0.3501 0.0343 1 1 1 4.3844 1 3 0.3733 0.6444 0.2571 0.6531 0.4166 1 3.3445 2 0.5022 1 0.1057 0.7755 0.6743 1 4.0578 1 4 0.3422 0.8060 0.9050 0.9388 0.4590 0.5 3.9510 2 0.6 0.9281 0.0447 0.9388 0.4563 1 3.9679 1 5 0.3911 0.8844 0.2588 0.6939 0.0688 1 3.2971 2 0.8178 0.3505 0.0839 0.8571 0.8817 0.5 3.4910 1 6 0.8356 0.4498 0.4077 0.7347 0.7882 1 4.2160 2 0 0.0182 0.0482 0.7347 0.0547 1 1.8559 1 7 0.16 0.0155 0.5103 0.6531 0.2101 1 2.5489 2 0.3156 0.6578 0 0 0.1174 0.5 1.5907 1 8 0.1467 0.9009 0.1054 0.2041 0 0.5 1.8570 2 Table 6.7: properties.  Normalized scores for each of the 6 quantified collaborative  60  6.5. Collaboration  Figure 6.3: This scatterplot shows the linear relationship and large, positive correlation between the average task scores and the collaboration scores (r = .673, p < .004).  61  6.5. Collaboration  COLLABORATION SCORE COMPONENTS: CORRELATION WITH PATTERN SCORE Pattern Score Component N Pearson Correlation Sig. Self report collaboration 16 0.382 0.145 Distribution of actions 16 0.060 0.825 Sentences spoken 16 0.475 0.063 Task completion time 16 0.538 0.032 Re-orientation of objects 16 0.199 0.460 Table 6.8: Results from using Pearson correlation to analyse the correlation between the individual collaboration score components and the pattern scores. There is a significant large correlation between total experimental task completion time and score. There is a marginally significant medium correlation between the number of sentences spoken and pattern score. Statistically significant results are bold and highlighted in blue.  6.5.8  Strategy Type  We observed a variety of pattern creation strategies employed by participants during both conditions. Most often pairs would use several different turntaking or parallel-work strategies in a single task. Design Discussion About half of the pairs of participants discussed and agreed upon an overall development layout before beginning to lay down buildings, such as noting the location of the corridors and planning to place higher density buildings along them. The other half simply began dragging buildings onto the map and discussed the design as they went, either stating why they were placing a building at a certain location or disagreeing with a placement their partner made. Partners also often discussed which buildings should be used in the design and when to place them, relative to which target value they were aiming to fulfill at the time. Pairs often started placing higher density buildings before placing lower density buildings and worked to fulfill the job target before fulfilling the population target.  62  6.5. Collaboration Single-touch condition In the single-touch condition, all pairs were forced to engage in turn-taking during the pattern creation process. They were also forced to be aware of their partner’s actions. At any given time there would be an active participant performing actions on the table and a passive participant watching them or checking the chart data. The active participant would drag buildings from the menu and arrange them in the map either one at a time (dragging from the menu and then placing) or as a batch (dragging several buildings from the menu at once and then placing them all afterwards). In some cases, if a participant had been passive for a long time, once they had control they used the batch method as if to claim a batch of buildings and ensure they would be the one to arrange them all in the map. If they dragged and placed buildings one at a time, their partner could interrupt between buildings; however, if they grabbed a batch, they were in possession of it and were often guaranteed to be able to finish “their” batch. Other single-touch turn-taking techniques involved division-of-labour. Pairs would divide the menu dragging and building placement tasks; the participant closest to the menu would grab the buildings and pass it to their partner, who would place the buildings in the map. This could be done individually or as a batch. Alternatively, one participant would arrange buildings on one side of a street and their partner would replicate the design on the other side. For the active participant, knowing their partner was watching often caused them to express their thoughts and actions verbally to let their partner understand their actions and their overall vision, and to solicit feedback. For example, one participant had lined up high density buildings along one side of a corridor and, without looking up, then asked their partner, “Same thing on the other side?” Another pair also had the active partner lining up buildings on one side of a block and when finished he said, “Keep going?” After a positive response he repeated the design on the other side of the street. The passive partner may comment on their partner’s actions, keep track of the pattern’s adherence to the goals, or adjust misaligned buildings when their partner was not touching the table, thereby completing the action. While the awareness of other’s actions is a desirable trait, one participant commented that “having only one hand on the touch table at once is an obstacle. [I] must coordinate with [my] partner first, then touch,” and their partner did not like that “you could not act while the partner was interacting with the touch table.” Others thought it was “very limiting, especially for 63  6.5. Collaboration group work” and “less collaborative” and noted that “you can’t share the work” and “the process was rigid, less fluid.” Several participants remarked that they thought it was harder and slower to complete the task with only one person active at a time. Alternatively, a couple of participants liked the restrictions, remarking that in the single-touch condition they “have to reach consensus before moving anything,” while in multi-touch “people just play around, put buildings together without asking other people’s opinions!” Another participant thought single-touch “might be preferable so people take turns and it doesn’t get too confusing,” and their partner liked that they were “forced to share the process.” Some people liked that “one person handles the screen” and even thought it was “easier to manage/translate the pieces” with one finger. Multi-touch condition In the multi-touch condition, a few pattern design strategies were observed. Participants often worked in parallel: once an overall design was agreed upon (e.g. place high density building along the corridors), pairs worked simultaneously to create the design. Both participants pulled buildings from the menu and arranged them in the map simultaneously. Alternatively, the participant closest to the menu would pull out a single or a batch of buildings and either the partner would place them or they would divvy up the placement of the buildings. Another technique was to strictly divide the duties so pairs took on distinct roles to create a design. The participant closest to the menu would drag out buildings while the other participant would arrange them on the map. Often the menu participant would watch the charts update as they were dragging a batch of buildings into the map area, stopping when a target value was reached. The menu participant would either then select another building type from the menu or help their partner arrange the buildings on the map if there were more to place. Even in the multi-touch condition we often observed pairs use the turntaking techniques described for the single-touch condition so that they were aware of each other’s actions and to prevent disrupting their partner. If one participant was arranging buildings in the map and their partner zoomed or panned the map, that would significantly interfere with their partner’s actions. Because only a portion of the menu was visible at one time, if one participant wanted a building that was not currently visible they would have to verify with their partner before scrolling the menu. Pairs still had to pay attention to their partner’s actions in the multi-touch condition. 64  6.5. Collaboration Interestingly, some pairs lauded the ability to work in parallel and yet almost exclusively employed turn-taking techniques to design their neighbourhood. Less active participants in this condition sometimes spent time looking at the neighbourhood as a whole, occasionally deleting and adjusting buildings placed by their partner as they thought necessary, while the more active partner spearheaded the design. Participants spent more time adjusting the arrangement of buildings in the multi-touch condition, possibly because they could do so in parallel. Analysing the questionnaire comments for the multi-touch condition, participants had almost only positive things to say. They enjoyed being able to “simultaneously do work” and found it “more collaborative; could execute ideas quickly.” Others thought that “both people allowed to use it made it much faster,” “fast creative processes were more present in the multi-touch environment since both of us could try and play with the pieces,” and “there was a greater sense of teamwork and the design process felt more spontaneous.” People generally thought it was more interactive and intuitive, though not everyone agreed. One participant felt that “other people’s touches interrupt what I’m doing” and another thought it was “hard to drag pieces around.” Overall, participants agreed that “multi-touch was way better.” Both touch conditions A frequently observed building placement technique in both conditions (though used more often for single-touch) is the rotation and then translation of building objects to their final destination. Participants found it easier to perform these actions in series, and in that order, than to rotate and translate objects simultaneously. Previous research has shown strong, independent channels for translation and orientation and that they are often done in series and in that order [42] [41]. In both conditions participants often zoomed in to make building placement easier becaues the building pieces became larger and more manageable. Because most pairs preferred to have an overall view of the neighbourhood while designing patterns, participants would first attempt to place the buildings while zoomed out, but if they were unable to do so easily they would zoom in. While the ability to zoom the map is desirable to see the city at a variety of scales, objects become difficult to manipulate at large scales and care must be taken before zooming to ensure group members are not disrupted if they are interacting with the map. Perhaps a ‘confirm zoom in/out’ coordinated 65  6.5. Collaboration gesture could prevent disruptions, but it may interrupt independent workflow.  66  Chapter 7  Conclusions & Future Work This thesis presented research on the design and evaluation of a collaborative spatial development pattern application for a multi-touch tabletop. The goal of this work was twofold: first, to provide an interactive planning support system (PSS) that offers a sufficient amount of functionality while enabling users of a variety of backgrounds to use it effectively and simultaneously; second, to explore varying the number of accepted touch inputs affects collaboration and quality of output for the interactive PSS.  7.1  Experimental Findings  In this section we summarize the findings from our experiment and discuss the implications of those findings.  7.1.1  Overview  Our study explored the effect on collaboration and output quality of varying the number of accepted touch inputs for a multi-touch tabletop application that facilitates urban planning tasks. Our hypotheses were: (H1) users will collaborate more in the multi-touch condition than in the single-touch condition (not supported); (H2) the quality of the neighbourhood patterns created in the multi-touch condition will be higher than those created in the single-touch condition (not supported); (H3) sessions in the multi-touch condition will take less time than sessions in the single-touch condition (not supported); (H4) multi-touch building interactions will be preferred over more traditional single-touch interactions (supported). The study yielded several findings. There was no significant effect of condition on the quality of output, although participants perceived their output patterns to be of higher quality in the multi-touch condition. There was also no significant effect of condition on the time taken to complete a task, although there was an effect of time on the quality of output; the longer a pair worked to design a neighbourhood, the better its quality. The second trial was faster than the first but not higher scoring, indicating a 67  7.1. Experimental Findings higher performance/time ratio. Participants also perceived they completed the multi-touch condition task faster than the single-touch condition task, even though there was no significant time difference with respect to touch condition. Building objects were translated, rotated, and touched more in the multitouch condition, presumably because more than one person could interact with the screen at one time. Interestingly, these additional interactions did not increase the time taken to complete the tasks. Participants significantly preferred the multi-touch map and building manipulations over single-touch manipulations. Participants also generally preferred the multi-touch condition overall. In terms of collaboration, pairs who spoke more scored higher than those who didn’t, and groups who collaborated more in general scored higher. Touch condition did not have a significant effect on collaboration. We observed several different strategy types in both touch conditions. Pairs in the single-touch task developed turn-taking techniques and were always aware of each other’s actions. Pairs in the multi-touch task often worked in parallel and at times independently. Overall, participants found the pattern creation system to be fun, easy to understand, and they particularly appreciated the automatic tallying of quantitative output values. One participant thought it would be “great for public processes because the data [neighbourhood pattern and chart data] can be shown later”. Another thought it was an “excellent learning tool. Quick to see strengths/weaknesses of different strategies and identify gaps/problems before they arise”.  7.1.2  Implications  One implication of our findings is that participants seemed to be more cognitively absorbed in the multi-touch condition than in the single-touch condition. Because they did not have to engage in turn-taking techniques, they were perhaps able to focus more on the neighbourhood design task rather than on collaboration strategies. This is supported by participants’ perceptions that the multi-touch task was faster, produced a better result, and that they enjoyed it more. Coordination was still required in this condition, however, because map manipulations, such as zooming, affected anyone manipulating buildings. We found that enforcing strict turn-taking, as per the single-touch condition, was not required in order to elicit effective collaboration for the neighbourhood design task. There was no difference in the amount that 68  7.2. Future Work pairs collaborated across conditions. We have also shown that effective collaboration during a neighbourhood design task leads to higher quality output. More experience with the task and the neighbourhood layout leads to the creation of neighbourhood designs more quickly but without a change in quality.  7.2  Future Work  The research described in this thesis is just the beginning of a potentially longer collaboration with the elementsLAB team. This prototype is the first version of the pattern creation application. We describe several ideas for additional interface enhancements and more complex functionality for the system.  7.2.1  Interface Enhancements  It would be useful to have a ground level or elevation view of the current development pattern on a wall display near the table. Users could see a different perspective of their pattern and get a sense of the overall layout. Even a small 3D thumbnail image of the buildings in the building details section of the menu would be useful to see its overall structure and height. Some participants wanted the ability to resize buildings. While a uniform scaling could be easily implemented with the pinch gesture (and the building’s parameters would be updated automatically), it creates logistical issues. For example, once a building is resized in the map area it no longer corresponds to a building in the menu. If a user resized a building and wanted more of the same modified buildings, they would have to drag the original from the menu and resize it precisely. One potential solution to this is to create a copy feature so individual or user-selected groups of buildings could be copied and placed elsewhere on the map. Another potential solution is to create a new menu option for the altered building, either automatically or with user intervention. This leads to further complications, such as a bloated menu that becomes difficult to navigate or find items. If users wished to scale buildings non-uniformly (change the plan view aspect ratios independently), this would require a more complex set of gestures or interactions. Because the map is scalable and buildings being dragged out from the menu subsequently change in size to accommodate the map scale, a visual indication of the buildings’ size if dragged would be helpful, especially for low density residential buildings that have variable size via the pulltab. 69  7.2. Future Work Participants in our study sometimes made more than one attempt to create an optimal-sized block of residential buildings. They made a guess as to the multiple of buildings they thought they might need, dragged it from the menu and placed it in the area, but if was too large/small, they then deleted it and created another. Another desirable functionality would be the automatic and perhaps imperceivable snapping of the edges of building pieces to lot edges, streets, and other buildings. Some participants spent a lot of time aligning the buildings properly while others left buildings looking somewhat haphazard. If buildings were to snap to edges then less time would be spent aligning buildings and the overall pattern layout would be more aesthetic. Similarly, if we prevented buildings from intersecting with roads or with each other this would aid in the layout process. This could be achieved by either strictly preventing buildings from overlapping (and having them push or repel each other) or providing affordances to indicate when they are overlapping. In the former case, additional behaviour would need to be added to the system so that building objects could ‘push’ each other if they intersect. With the latter case, such an affordance could be changing the colour of the building borders or of the building objects themselves. A couple of participants expressed a desire for a ‘copy’ function that would copy an arbitrary set of buildings currently in the map and duplicate them. This would make it easier to replicate a design choice; for example, two identical sides of a busy corridor. Such a function would require additional interaction techniques. In addition, because the area being copied is of arbitrary size and potentially the majority of the screen, users would have to be cautious about disturbing other group members when using this function. In the future we would like to add a green space option in the menu so users could explicitly allocate space on the map for natural systems. Such an object should be freeform or scalable in both the x and y dimensions, which may require a complex touch gesture or other novel user interaction. The application currently supports a maximum of three saved patterns but we would like to support more than that. In the current state of the prototype, if a group was using the application, created and saved three patterns saved and then created another pattern in the map, they would not be able to restore one of the saved patterns without losing the one currently in the map.  70  7.2. Future Work  7.2.2  Functionality  With a prototype system in place, more algorithmic processes can be added to it. For example, we could begin quantifying the sustainability principles and calculating a given pattern’s adherence to one or more of them. With these calculations in place an overall pattern score could be displayed in the chart area along with the target values. In addition, more affordances could be presented to users to inform them that, for example, the residential buildings are too far from the commercial buildings. Constraints for a neighbourhood could be entered into the system before the collaborative development process and the system could then automatically generate a default neighbourhood based on those constraints. While the default neighbourhood may be less than optimal, it would give users a starting point, for working and for discussion, from which to begin and build upon. If the system becomes heavily used and many sustainable pattern layouts are created, they could then be stored in a database of optimal pattern or sub-pattern layouts. This database could then be consulted when designing a new neighbourhood.  71  Bibliography [1] Agarwal, R. and Karahanna, E. (2000). Time flies when you’re having fun: Cognitive absorption and beliefs about information technology usage. MIS Quarterly, 24(4):665–694. [2] Arias, E., Eden, H., Fischer, G., Gorman, A., and Scharff, E. (2000). Transcending the individual human mind—creating shared understanding through collaborative design. ACM Trans. Comput.-Hum. Interact., 7(1):84–113. ˇ c´ıkov´ [3] Borning, A., Sevˇ a, H., and Waddell, P. (2008). A domain-specific language for urban simulation variables. In dg.o ’08: Proceedings of the 2008 international conference on Digital government research, pages 207–215. Digital Government Society of North America. [4] Borning, A., Waddell, P., and Frster, R. (2007). Urbansim: Using simulation to inform public deliberation and decision making. In Digital Government: Advanced Research and Case Studies. Springer-Verlag. [5] Cohen, J. W. (1988). Statistical power analysis for the behavioral sciences. Lawrence Erlbaum Associates, Hillsdale, NJ, USA, 2nd edition. [6] Design Centre for Sustainability (2007). Sustainability by Design: A Vision for a Region of 4 Million. Design Centre for Sustainability. [7] Drettakis, G., Roussou, M., Asselot, M., Reche, A., Olivier-Mangon, A., Tsingos, N., and Tecchia, F. (2005). Participatory design and evaluation of a real-world virtual environment for architecture and urban planning. Technical Report 5479, INRIA Research Report, Sophia-Antipolis. [8] elementsdb. Url: http://elementsdb.sala.ubc.ca/. [9] elementsdb About. Url: http://elementsdb.sala.ubc.ca/cms.php/about. [10] elementsLAB in the School of Architecture and Landscape Architecture at the University of British Columbia. Url: http://elementsdb.sala.ubc.ca/. 72  Bibliography [11] Girling, C., Kellett, R., and Johnstone, S. (2006). Informing design charrettes: Tools for participation in neighbourhood-scale planning. The Integrated Assessment Journal, 6(4):109–130. [12] Grasso, A., Muehlenbrock, M., Roull, F., and Snowdon, D. (2003). Chapter 11 supporting communities of practice with large screen displays. In OHara, K., Perry, M., Churchill, E., and Russell, D., editors, Public and situated displays: Social and interactional aspects of shared display technologies, pages 261–283. Kluwer Academic, Dordrecht, The Netherlands. [13] Greenberg, S. and Marwood, D. (1994). Real time groupware as a distributed system: concurrency control and its effect on the interface. In CSCW ’94: Proceedings of the 1994 ACM conference on Computer supported cooperative work, pages 207–217, New York, NY, USA. ACM. [14] Han, J. Y. (2005). Low-cost multi-touch sensing through frustrated total internal reflection. In UIST ’05: Proceedings of the 18th annual ACM symposium on User interface software and technology, pages 115– 118, New York, NY, USA. ACM. [15] Ishii, H., Underkoffler, J., Chak, D., and Piper, B. (2002). Augmented urban planning workbench: Overlaying drawings, physical models and digital simulation. In ISMAR ’02: Proceedings of IEEE and ACM International Symposium on Mixed and Augmented Reality, pages 203– 211. [16] Klosterman, R. E. (1997). Planning support systems: A new perspective on computer-aided planning. Journal of Planning Education and Research, 17(1):45–54. [17] Klosterman, R. E. (1999). The What If? collaborative planning support system. Environment and Planning B: Planning and Design, 26:393– 408. [18] Krueger, M. W., Gionfriddo, T., and Hinrichsen, K. (1985). Videoplace—an artificial reality. SIGCHI Bulletin, 16(4):35–40. [19] Kruger, R., Carpendale, S., Scott, S. D., and Tang, A. (2005). Fluid integration of rotation and translation. In CHI ’05: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 601–610, New York, NY, USA. ACM. 73  Bibliography [20] Kwartler, M. and Bernard, R. (2001). CommunityViz: An integrated planning support system. In Brail, R.K., Klosterman, R.E. (Eds.), Planning Support Systems: Integrating Geographic Information Systems and Visualization Tools, pages 285–308, Redlands, CA, USA. ESRI Press. [21] Maquil, V., Psik, T., and Wagner, I. (2008). The colortable: a design story. In TEI ’08: Proceedings of the 2nd international conference on Tangible and embedded interaction, pages 97–104, New York, NY, USA. ACM. [22] Marshall, P., Hornecker, E., Morris, R., Dalton, N. S., and Rogers, Y. (2008). When the fingers do the talking: A study of group participation with varying constraints to a tabletop interface. In Third IEEE International Workshop on Tabletops and Interactive Surfaces, pages 33–40. IEEE. [23] MetroQuest. Url: http://www.metroquest.com/. [24] Morris, M. R., Cassanego, A., Paepcke, A., Winograd, T., Piper, A. M., and Huang, A. (2006). Mediating group dynamics through tabletop interface design. IEEE Comput. Graph. Appl., 26(5):65–73. [25] Morris, M. R., Ryall, K., Shen, C., Forlines, C., and Vernier, F. (2004). Beyond “social protocols”: multi-user coordination policies for co-located groupware. In CSCW ’04: Proceedings of the 2004 ACM conference on Computer supported cooperative work, pages 262–265, New York, NY, USA. ACM. [26] Morris, M. R. and Winograd, T. (2004). Quantifying collaboration on computationally-enhanced tables. In CSCW 2004 Workshop on Methodologies for Evaluating Collaboration Behaviour in Co-located Environments. [27] Pinelle, D., Gutwin, C., and Greenberg, S. (2003). Task analysis for groupware usability evaluation: Modeling shared-workspace tasks with the mechanics of collaboration. ACM Trans. Comput.-Hum. Interact., 10(4):281–311. [28] Rogers, Y., Limb, Y., Hazlewood, W. R., and Marshall, P. (2008). Equal opportunities: Do shareable interfaces promote more group participation than single user displays? In Human Computer Interaction, volume 24, pages 79–116. 74  Bibliography [29] Scott, S. D., Grant, K. D., and Mandryk, R. L. (2003). System guidelines for co-located, collaborative work on a tabletop display. In ECSCW’03: Proceedings of the eighth conference on European Conference on Computer Supported Cooperative Work, pages 159–178, Norwell, MA, USA. Kluwer Academic Publishers. [30] Shen, C., Everitt, K., and Ryall, K. (2003). Ubitable: Impromptu faceto-face collaboration on horizontal interactive surfaces. In UbiComp ’03: Proceedings of the Fifth International Conference on Ubiquitous Computing, pages 281–288. [31] Shen, C., Vernier, F. D., Forlines, C., and Ringel, M. (2004). Diamondspin: an extensible toolkit for around-the-table interaction. In CHI ’04: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 167–174, New York, NY, USA. ACM. [32] Stewart, J., Bederson, B. B., and Druin, A. (1999). Single display groupware: a model for co-present collaboration. In CHI ’99: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 286–293, New York, NY, USA. ACM. [33] Tanenbaum, J., Antle, A., Seaborn, K., Tanenbaum, K., Bevans, A., and Wang, S. (2010). Futura: A case study in the design of an educational multi-touch tabletop game. In Proceedings of Games, Learning and Society Conference 6.0, pages 97–104. [34] Underkoffler, J. and Ishii, H. (1999). Urp: a luminous-tangible workbench for urban planning and design. In CHI ’99: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 386–393, New York, NY, USA. ACM. [35] UrbanSim. Url: http://www.urbansim.org/. [36] VanMap. Url: http://vancouver.ca/vanmap/. [37] Vonk, G., Geertman, S., and Schot, P. (2005). Bottlenecks blocking widespread usage of planning support systems. Environment and Planning, 37(5):909–924. [38] Waddell, P. (2002). Urbansim: Modeling urban development for land use, transportation and environmental planning. Journal of the American Planning Association, 68:297–314.  75  [39] Waddell, P., Borning, A., Noth, M., Freier, N., Becke, M., and Ulfarsson, G. (2003). Microsimulation of urban development and location choices: design and implementation of urbansim. Networks and Spatial Economics, page 2003. [40] Wagner, I., Basile, M., Ehrenstrasser, L., Maquil, V., Terrin, J.-J., and Wagner, M. (2009). Supporting community engagement in the city: urban planning in the mr-tent. In C&T ’09: Proceedings of the fourth international conference on Communities and Technologies, pages 185– 194, New York, NY, USA. ACM. [41] Wang, Y. and MacKenzie, C. L. (1999). Effects of orientation disparity between haptic and graphic displays of objects in virtual environments. In INTERACT ’99, pages 391–398. IOS Press. [42] Wang, Y., MacKenzie, C. L., Summers, V. A., and Booth, K. S. (1998). The structure of object transportation and orientation in human-computer interaction. In CHI ’98: Proceedings of the SIGCHI conference on Human factors in computing systems, pages 312–319, New York, NY, USA. ACM Press/Addison-Wesley Publishing Co.  76  Appendix A  Pre-Session Questionnaire  77  Pre-Session Questionnaire Demographics How old are you?  _______  What is your degree program?  _____________________________  (Please circle answers to the following:) What is your gender?  M  F  What is your degree?  Bachelors  Masters  What year are you?  1  3  4  Yes  No  2  Experience  Have you ever used a touch interface before?  PhD 5+  If yes, which type(s) and how much have you used it? Device iPhone/Touch phone  1-3 times  4-10 times  Usage Regular, infrequent use  Regular, frequent use  Tablet PC Tabletop Wall display iPad Other:  78  February 1, 2010  Page 1 of 1  Appendix B  Post-Task Questionnaire  79  Post-Task Questionnaire  (Please circle an X in each of the following questions:) How easy was it to complete the task? Very easy X  Not easy or difficult X  X  X  Very difficult X  X  X  How fast was it to complete the task? Very fast X  Not fast or slow X  X  X  Very slow X  X  X  How good do you think your solution is? Very good X  Average X  X  X  Very bad X  X  X  How much did you collaborate with your partner? I did all the work X  We did the same amount X  X  X  X  They did all the work X  X  How much did you like the method used to complete this task? I liked it a lot X  I didn’t like or dislike it X  X  X  I really didn’t like it X  X  X  Any comments about this task or the method used?  80  February 4, 2010  Page 1 of 2  How easy was it translate/move building pieces? Very easy X  Not easy or difficult X  X  X  Very difficult X  X  X  How easy was it rotate building pieces? Very easy X  Not easy or difficult X  X  X  Very difficult X  X  X  How easy was it translate/move the map? Very easy X  Not easy or difficult X  X  X  Very difficult X  X  X  How easy was it scale the map? Very easy X  Not easy or difficult (or N/A) X  X  X  X  Very difficult X  X  81  February 4, 2010  Page 2 of 2  Appendix C  Post-Session Questionnaire  82  Post-Session Questionnaire Which method was easiest to complete the task with? Single-touch table application Multi-touch table application  Which method was fastest to complete the task with? Single-touch table application Multi-touch table application  With which method do you think you created the best solution? Single-touch table application Multi-touch table application  With which method do you think you collaborated with your partner most? Single-touch table application Multi-touch table application  Which method did you prefer in general? Single-touch table application Multi-touch table application  What do you like about your preferred method?  83  February 4, 2010  Page 1 of 2  What do you dislike about the other method?  With which method was it easier to translate/move the building pieces? Single-touch table application Multi-touch table application  With which method was it easier to rotate the building pieces? Single-touch table application Multi-touch table application  With which method was it easier to translate/move the map? Single-touch table application Multi-touch table application  With which method was it easier to scale the map? Single-touch table application Multi-touch table application  Any other comments?  84  February 4, 2010  Page 2 of 2  Appendix D  Sunset Neighbourhood Background Information  85  GROWING SUNSET: CONTACT:  Gaming alternative neighbourhood 100503  futures  for  Sunset  Ronald Kellett • Landscape Architecture Program • 370 - 2357 Main Mall • Vancouver, British Columbia • V6T 1Z4 Canada • phone: 604 827 5144 • email: kellett@interchange.ubc.ca  SUNSET:  Sunset in south central Vancouver — an area bounded by E. 41st Avenue and the Fraser River to the north and south and Ontario Street and Knight Street to the west and east — is one of the city's most ethnically diverse neighbourhoods. Its population of approximately 50,000 live in primarily single-family residential areas (typically RS-1S zoning in which any dwelling may add a rental suite). The area's commercial and higher density residential nodes and corridors are located primarily along the area's arterial streets ‚ Ontario, Main, Fraser and Knight (n-s) and 41st, 49th, 57th and SE Marine Drive (e-w). GROWTH:  If official growth projections hold, the regional population of MetroVancouver is anticipated to double in roughly two generations (by ~2050). While the region's neighbourhoods and municipalities will absorb this growth assymmetrically — some growing a lot, others much less — all are compelled to anticipate an appropriate share of regional growth in their planning. 86  Accommodating such significant growth while maintaining quality of life, environment and economy will be a challenge everywhere, it will be even more so in already established neighbourhoods such as Sunset.  STUDY AREA:  For example, the approximately 11 block area in the accompanying illustrations (red outline in the map above and coloured areas of the airphoto below) will be challenged to accommodate an appropriate share of this growth with sensitivity to the prevailing physical fabric of the community and its longer term sustainability in the city and region. In this existing approximately 22 hectare area are 344 detached dwelling types. Approximately half (183) have secondary suites. At an average of 3.2 persons, these 527 dwellings would accommodate 87 approximately 1,700 persons.  In addition, there are a small number of commercial and mixed use commercial building types (red and orange areas respectively) at the intersection of E.49th and Knight that support a few (6) dwellings and 1,160 m2 of employment (~50 jobs at an average of 22.5 m2 each).  88  sustainability  principles  1 jobs  2  corridors   High density commercial and residential corridors focus growth along transit routes.  Job sites located within communities reduce time spent travelling to work.  3 walkability  4  green space   Green spaces provide recreation opportunities and connect people with natural systems.  Interconnected street systems link residents with the services they need.  5 infrastructure   housing 6  A range of housing types allows residents of differing economic situations to live in the same neighbourhood and have access to the same services.  Integrating natural systems reduces infrastructure costs and environmental impact.    89  sustainability by design      Appendix E  Task Descriptions  90  TASK_1: PAPER  Using a palette of building types provided and the accompanying Six Principles of Sustainable Communities (Design Centre for Sustainability at UBC) to guide you, work with your partner to generate ONE sustainability-oriented plan that accommodates the following growth: •  POPULATION GROWTH  + 850 persons (1.5 x current population) •  EMPLOYMENT GROWTH  +100 jobs (2 x current jobs) Work within the existing street and block pattern. However, parcel pattern may be reorganized or adapted to accommodate different building types.  91  TASK_2: TABLE  Using a palette of building types provided and the accompanying Six Principles of Sustainable Communities (Design Centre for Sustainability at UBC) to guide you, work with your partner to generate TWO alternative sustainability-oriented plans that accommodate the following growth: •  POPULATION GROWTH  + 1,200 persons (1.71 x current population) •  EMPLOYMENT GROWTH  + 400 jobs (8 x current jobs) Work within the existing street and block pattern. However, parcel pattern may be reorganized or adapted to accommodate different building types.  92  TASK_3: TABLE  Using a palette of building types provided and the accompanying Six Principles of Sustainable Communities (Design Centre for Sustainability at UBC) to guide you, work with your partner to generate TWO alternative sustainability-oriented plans that accommodates the following growth: •  POPULATION GROWTH  + 1,700 persons (2 x current population) •  EMPLOYMENT GROWTH  + 200 jobs (4 x current jobs) Work within the existing street and block pattern. However, parcel pattern may be reorganized or adapted to accommodate different building types.  93  Appendix F  Ethics Approval Certificate  94  95  

Cite

Citation Scheme:

        

Citations by CSL (citeproc-js)

Usage Statistics

Share

Embed

Customize your widget with the following options, then copy and paste the code below into the HTML of your page to embed this item in your website.
                        
                            <div id="ubcOpenCollectionsWidgetDisplay">
                            <script id="ubcOpenCollectionsWidget"
                            src="{[{embed.src}]}"
                            data-item="{[{embed.item}]}"
                            data-collection="{[{embed.collection}]}"
                            data-metadata="{[{embed.showMetadata}]}"
                            data-width="{[{embed.width}]}"
                            async >
                            </script>
                            </div>
                        
                    
IIIF logo Our image viewer uses the IIIF 2.0 standard. To load this item in other compatible viewers, use this url:
http://iiif.library.ubc.ca/presentation/dsp.24.1-0051956/manifest

Comment

Related Items