Computer Science Division University of California Berkeley, CA USA {jasonh,

Please download to get full document.

View again

of 10
All materials on our website are shared by users. If you have any questions about copyright issues, please report us to resolve them. We are always happy to assist you.
Information Report

Arts & Architecture


Views: 3 | Pages: 10

Extension: PDF | Download: 0

Development and Evaluation of Emerging Design for Ubiquitous Computing Eric S. Chung 1, Jason I. Hong 1, James Lin 1, Madhu K. Prabaker 1, James A. Landay 2, Alan L. Liu 2 1 Group for User Interface Research
Development and Evaluation of Emerging Design for Ubiquitous Computing Eric S. Chung 1, Jason I. Hong 1, James Lin 1, Madhu K. Prabaker 1, James A. Landay 2, Alan L. Liu 2 1 Group for User Interface Research Computer Science Division University of California Berkeley, CA USA {jasonh, 2 DUB Group Computer Science and Engineering University of Washington Seattle, WA USA ABSTRACT Design patterns are a format for capturing and sharing design knowledge. In this paper, we look at a new domain for design patterns, namely ubiquitous computing. The overall goal of this work is to aid practice by speeding up the diffusion of new interaction techniques and evaluation results from researchers, presenting the information in a form more usable to practicing designers. Towards this end, we have developed an initial and emerging pattern language for ubiquitous computing, consisting of 45 pre-patterns describing application genres, physical-virtual spaces, interaction and systems techniques for managing privacy, and techniques for fluid interactions. We evaluated the effectiveness of our pre-patterns with 16 pairs of designers in helping them design location-enhanced applications. We observed that our pre-patterns helped new and experienced designers unfamiliar with ubiquitous computing in generating and communicating ideas, and in avoiding design problems early in the design process. Author Keywords Design, Design patterns, Ubiquitous computing ACM Classification Keywords H.5.2 [Information Interfaces and Presentation]: User Interfaces Theory and methods, Style guides, Evaluation/methodology INTRODUCTION Design patterns have been proposed in many domains as a format for capturing and sharing design knowledge between practitioners (e.g., [2-5, 9, 21, 24]). communicate insights into design problems, capturing the essence of recurring problems and their solutions in a compact form. They describe the problem in depth, the rationale for the solution, how to apply the solution, and some of the tradeoffs in applying the solution. A set of interlinked patterns for a specific domain is known as a pattern language. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Conference DIS 04, Aug 1 4, 2004, Boston, MA, USA. Copyright 2004 ACM /04/ $5.00. differ from other formats for capturing design knowledge, such as guidelines and heuristics, in three ways. First, patterns offer solutions to specific problems rather than providing high-level and sometimes abstract suggestions. Second, patterns are generative, helping designers create new solutions by showing many examples of actual designs. Third, patterns are linked to one another hierarchically, helping designers address high-level problems as well as low-level ones. are not intended to replace guidelines and heuristics but rather complement them. are simply another tool for helping designers create high-quality solutions. Pattern languages started in the field of architecture [2], and have been emerging for UI design (e.g., [4, 7, 19, 22]) as well as for web design (e.g., [10, 21, 23]). have seen their greatest success in the area of software design as exhibited by the success of the Gang of Four book Design [9], as well as by the widespread usage of their pattern names within the software development community. This last point represents another important contribution of design patterns, which is providing a common, shared vocabulary that lets designers communicate more easily. Here, we extend on the idea [12] of using design patterns as a format for assisting designers developing applications for ubiquitous computing (ubicomp), systems that make use of sensors, computing devices in a variety of form factors, and wireless networking to assist us in all kinds of tasks [25]. Although ubicomp is still in its nascent stages, there are many potential benefits in developing a pattern language now. First, we can speed up the diffusion of new interaction techniques and evaluation results by presenting it in a form more usable to designers. Second, a pattern language for ubicomp can help us more clearly see links between ideas, as well as what issues remain to be addressed. Third, we can positively influence the design of emerging applications by helping designers find good solutions and avoid adopting poor standards, such as inadequate privacy protection and blue web links 1. As an analogy, when the 1 As noted by several designers (e.g., [14, 18]), blue is one of the worst colors for unvisited links because of the structure of the human eye. However, since so many web pages use blue for unvisited links and so many people have learned this meaning, blue links have become a de facto standard. periodic table was initially developed, Mendeleyev did not force the known elements to fit in. Instead, he left holes that helped others make predictions about unknown elements that eventually led to their discovery. Towards this end, we introduce an initial pattern language for ubicomp. This language has 45 pre-patterns addressing application genres, physical-virtual spaces, interaction and systems techniques for managing privacy, and techniques for fluid interactions. We call these pre-patterns because they are still emerging and are not in common use yet by the design community and end-users. However, we have found the format of patterns to be useful in communicating design knowledge, even if that knowledge is not set in stone. We expect the pre-patterns to evolve over time, with some being replaced by new patterns. We have also conducted what is, to the best of our knowledge, the first controlled study of patterns with designers. In our first round of evaluation, we had nine pairs of designers create an initial design for a locationenhanced application, four of which had access to our prepatterns and five that did not. In our second round, we modified the patterns based on feedback in the first round, and had six pairs of designers use our patterns and one not. This let us compare six pairs of designers in each of the two conditions in the second round. In the first evaluation round, there were no statistically significant differences in quality, completeness, or creativity between the designs of pairs that used patterns and pairs that did not. In the second round, there were some statistically significant differences with respect to factors such as accomplishing tasks more quickly and usefulness, although most of the differences were between expert and novice designers, rather than between pairs that used patterns and those that did not. However, our qualitative observations in both rounds suggest that patterns helped novice designers generate designs, helped experienced designers new to ubicomp learn about the domain, helped designers communicate ideas, and helped designers avoid potential design problems earlier in the design process. Surprisingly, although we had an entire group of patterns devoted to privacy, our patterns did not help with that issue. Generally, designers found our pre-patterns useful. RELATED WORK Design patterns were first developed by Christopher Alexander and his colleagues [2]. Alexander believed that patterns could empower both architects and their clients by providing a living and shared language for design. He and his colleagues developed 253 patterns for building and planning towns, neighborhoods, houses, gardens, and rooms. The emphasis here was on an entire language for design, since the usefulness of patterns was not only in providing solutions to common problems, but also in seeing how they intertwined and affected one another. [14, 18] Our pattern language for ubiquitous computing uses the definition generated at INTERACT 99: The goals of an HCI pattern language are to share successful HCI design solutions among HCI professionals [4]. An alternative and somewhat complementary perspective is to have a pattern language that is a lingua franca for all design stakeholders [6, 8]. While this latter approach has potential for participatory design, it is not one we focused on in the development and evaluation of our design patterns. Typically, patterns are evaluated through peer review, often in pattern writing workshops [1, 13]. Although the idea of design patterns has been around for quite a while, only recently has there been work on evaluating patterns. For example, Borchers developed and evaluated a pattern language for interactive music exhibits, by having the patterns peer-reviewed at a pattern workshop, by using those patterns in developing two interactive music exhibits, and by surveying undergraduate students that had used some patterns for usefulness and memorability [4]. Dearden et al evaluated a set of patterns for developing airline and rail travel sites with potential users of the system rather than with designers. They investigated whether the patterns empowered users to participate in participatory design and could help users generate designs [6]. However, to the best of our knowledge, there has not been a study evaluating the effect of patterns on how designers communicate and design with one another. We take a first step towards this, looking at how several pairs of designers used our patterns, in terms of learning about a new domain, communicating with one another, evaluating existing designs, and generating designs. A LANGUAGE OF PRE-PATTERNS FOR UBICOMP In this section, we give an overview of the method we used to create our pattern language for ubiquitous computing, as well as a description of the pre-patterns themselves. Developing the Language Developing the pattern language was an iterative process lasting several months. We started by brainstorming pattern candidates based on a review of the existing literature. We initially tried to create high-level patterns, ones that are fairly abstract and describe whole applications, as opposed to single screens, for example. This proved to be difficult to do, as it meant trying to create a hierarchy of patterns as well as the patterns themselves at the same time. It turned out to be far easier to work bottom-up, identifying relatively low-level and medium-level individual patterns, and then later drawing themes from those to connect them together. We generated rough cuts of about 80 fairly broad pattern candidates, which looked at a range of interaction and infrastructural issues in ubicomp. There was also a strong focus on patterns for location-based computing, since a sizeable number of this type of application are emerging in the market, and thus has a clearer path to widespread deployment than other areas of ubiquitous computing [15]. We later dropped the infrastructural patterns, instead concentrating on interaction issues because we wanted to focus on helping interaction designers. Some of these pre-patterns dealt with high-level fundamental issues cutting across all areas of ubicomp (e.g., privacy), while others were relatively low-level interaction techniques (e.g., pick and drop [16]). We tried to find at least two examples for each pattern, and generally preferred commercial implementations since that indicated that the pattern was more likely to find widespread usage. We then did a card sort [20] among ourselves to organize the pattern candidates into different pattern groups, where each group is a set of patterns with a common theme. After this, we created the main content for each pattern, describing the problem and solution, providing several examples, and establishing links to related patterns. Each pattern was written and edited by at least three of the authors, and was limited to two pages to make it more digestible for the designer. We removed weaker pattern candidates and added new ones where it made sense. We then solicited feedback from four other researchers familiar with ubiquitous computing. The researchers were first given the name of a pattern and asked to guess what kind of content the pattern would contain. Then, they were shown the full pattern, and asked to rate the quality of the pattern name and to comment on the actual content. We revised the patterns based on this feedback. At the end, we had 45 patterns in four groups (see Fig 1): Ubiquitous Computing Genres describes broad classes of ubicomp applications. Physical-Virtual Spaces looks at how physical objects and spaces can be merged with the virtual. Developing Successful Privacy describes policies and mechanisms for managing end-user privacy. Designing Fluid Interactions details interaction techniques with sensors and devices. All of the pre-patterns used for both rounds of evaluations are at Format of The format of our patterns is similar to those in The Design of Sites [21] and A Pattern Language [2]. Figures 2 and 3 (located at end of this paper) show the first page of several of our pre-patterns. Each pre-pattern consists of: A name and a letter-number pair, where the letter indicates which group the pattern belongs to. For example, A3 means the third pattern in pattern group A Ubiquitous Computing Genres. The pattern s background, which provides the context and scope of the pattern, and describes any other patterns that lead to this pattern. The problem that the pattern is addressing. The solution (or solutions) to the pattern s problem, as well as pointers to other lower-level patterns that help solve the problem. References of work related to the pattern. Figure 4. Bus maps show how patterns within a pattern group are related. Here, there are four core patterns that are fundamental in designing applications (A1 through A4), as well as several patterns specific to application genres. We also created what we call bus maps. Each map shows the core patterns in a pattern group and the relationship of the patterns within that group (see Figure 4). Our patterns tended to be more prescriptive than descriptive, mostly because there are few ubicomp applications in practice. Our patterns also tended to focus on high-level issues, such as user needs, versus specific user interfaces and interaction techniques. This is because many of these high-level issues are better understood than the low-level techniques for implementing them. For example, many people have outlined what needs smart homes can address (e.g., [11]), but there have been few widespread successes in specific interactions in that area. FIRST EVALUATION OF PRE-PATTERNS We evaluated the effectiveness of our design patterns by having designers use them in evaluating and designing location-enhanced applications. In this section, we describe our first round of evaluation. Participants Nine pairs of designers (18 designers total) participated in the first round. Four pairs were professionals, and the other five pairs were graduate students in the School of Information Management and Systems at UC Berkeley. These professional pairs had an average of 8½ person-years of experience combined (ranging from 6 to 10 combined), while the student design pairs each had an average of 4½ person-years of combined experience (with one pair having 8, the others having at most 3). The pairs were divided into two categories based on experience. High-experience pairs had at least 6 personyears of combined experience, and low-experience pairs had at most 3. They were also divided into two conditions, 4 with patterns and 5 without (see Table 1). We ed our design patterns to the groups in the patterns condition two days beforehand so that they could familiarize themselves with the patterns. Designers in this A Ubiquitous Computing Genres B Physical-Virtual Spaces C Developing Successful Privacy D Designing Fluid Interactions Describes broad classes of emerging applications, providing many examples and ideas Associating physical objects and spaces with information and meaning; location-based services; helping users navigate such spaces Policy, systems, and interaction issues in designing privacysensitive systems How to design for interactions involving dozens or even hundreds of sensors and devices while making users feel like they are in control Upfront Value Proposition (A1) Active Map (B1) Fair Information Practices (C1) Scale of Interaction (D1) Personal Ubiquitous Computing (A2) Ubiquitous Computing for Groups (A3) Ubiquitous Computing for Places (A4) Guides for Exploration and Navigation (A5) Enhanced Emergency Response (A6) Personal Memory Aids (A7) Smart Homes (A8) Enhanced Educational Experiences (A9) Augmented Reality Games (A10) Streamlining Business Operations (A11) Enabling Mobile Commerce (A12) Topical Information (B2) Successful Experience Capture (B3) User-Created Content (B4) Find a Place (B5) Find a Friend (B6) Notifier (B7) Respecting Social Organizations (C2) Building Trust and Credibility (C3) Reasonable Level of Control (C4) Appropriate Privacy Feedback (C5) Privacy-Sensitive Architectures (C6) Partial Identification (C7) Physical Privacy Zones (C8) Blurred Personal Data (C9) Limited Access to Personal Data (C10) Invisible Mode (C11) Limited Data Retention (C12) Notification on Access of Personal Data (C13) Privacy Mirrors (C14) Sensemaking of Services and Devices (D2) Streamlining Repetitive Tasks (D3) Keeping Users in Control (D4) Serendipity in Exploration (D5) Context-Sensitive I/O (D6) Active Teaching (D7) Resolving Ambiguity (D8) Ambient Displays (D9) Follow-me Displays (D10) Pick and Drop (D11) Keeping Personal Data on Personal Devices (C15) Figure 1. The overall table of our design pre-patterns for ubiquitous computing. These design patterns are organized into four pattern groups, sets of patterns that are related by a common theme. Generally speaking, lower-numbered patterns are higher-level, more abstract, and applicable in more cases than higher-numbered patterns. For example, Upfront Value Proposition (A1) is a high-level pattern that can be applied to a widerange of applications, while Enabling Mobile Commerce (A12) is a pattern specific to that domain. Figure 2. Each pre-pattern has a number (e.g., A12), name ( Enabling Mobile Commerce ), sensitizing image, background that relates this pattern to other patterns, problem statement, solution, and references. Figure 3. Some more examples of our pre-patterns for ubiquitous computing. High experience Low experience 4, 9 5, 6 No 1, 2, 7 3, 8 Table 1. Design pairs by condition for our first round of evaluation. For example, design pairs 4 and 9 had high levels of experience and were in the patterns condition. useful for Evaluation Task useful for Design Task useful for Other Projects Avg Stdev Table 2. Feedback about our design patterns from participants in the patterns condition (1 5, 5=high) Condition Creativity Completeness Quality All pairs µ = 5.08 µ = 5.42 µ = 4.67 δ = 1.24 δ = 1.00 δ = 1.07 No patterns µ = 4.00 δ = 1.31 µ = 4.67 δ = 1.40 µ = 4.53 δ = 1.51 Pairs with low experience µ = 5.17 µ = 5.50 µ = 4.83 δ = 0.75 δ = 1.22 δ = 1.17 No patterns µ = 3.83 δ = 1.17 µ = 4.00 δ = 1.79 µ = 4.00 δ = 1.79 Pairs with high experience µ = 5.00 µ = 5.33 µ = 4.50 δ = 1.67 δ = 0.82 δ = 1.05 No patterns µ = 4.11 δ = 1.45 µ = 5.11 δ = 0.93 µ = 4.89 δ = 1.27 Table 3. An analysis of the judges ratings of the designs, on a scale of 1 7 (7=high). The judges on average rated the pairs who had patterns higher than those who did not, in creativity and completeness, and in quality except for pairs with high experience. condition were also provided paper copies of the patterns during the session and given a few minutes at the start of the evaluation to look them over. Method The evaluation consisted of two tasks. The first task explored to what degree patterns assisted designers i
We Need Your Support
Thank you for visiting our website and your interest in our free products and services. We are nonprofit website to share and download documents. To the running of this website, we need your help to support us.

Thanks to everyone for your continued support.

No, Thanks

We need your sign to support Project to invent "SMART AND CONTROLLABLE REFLECTIVE BALLOONS" to cover the Sun and Save Our Earth.

More details...

Sign Now!

We are very appreciated for your Prompt Action!