论文翻译：Development and Evaluation of Emerging Design Patterns for Ubiquitous ComputingDevelopment and Evaluation of Emerging
Design Patterns for Ubiquitous Computing
Eric S. Chung1, Jason I. Hong1, James Lin1, Madhu K. Prabaker1, James A. Landay2, Alan L. Liu2
1Group for User Interface Research
Computer Science Division
University of California
Berkeley , CA 94720 USA
{jasonh, jimlin}@cs.berkeley.edu
2DUB Group
Computer Science and Engineering
University of Washington
Seattle , WA 98195 USA
landay@cs.washington.edu
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 ingenerating 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, 23]). Patterns 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.
Patterns 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. Patterns are not intended to replace guidelines and heuristics but rather complement them. Patterns 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, 22]). Patterns have seen their greatest success in the area of software design as exhibited by the success of the Gang of Four book Design Patterns [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 [24].
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 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 (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.). As an analogy, when the 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 location-enhanced application, four of which had access to our pre-patterns 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.
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]. Deardenet 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 Figure 1 at the end of this paper):
• 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 http://guir.berkeley.edu/projects/patterns
Format of Patterns
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, “A 3” 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 having8, the others having at most 3).
The pairs were divided into two categories based on experience. High-experience pairs had at least 6 person-years 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).
|
| High experience | Low experience |
| Patterns | 4, 9 | 5, 6 |
| No Patterns | 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.
|
| Patterns useful for Evaluation Task | Patterns useful for Design Task | Patterns useful for Other Projects |
| 4-1 | 2 | 4 | 3 |
| 4-2 | 4 | 4 | 3 |
| 5-1 | 2 | 5 | 4 |
| 5-2 | 4 | 3 | 3 |
| 6-1 | 3 | 2 | 4 |
| 6-2 | 1 | 2 | 4 |
| 9-1 | 4 | 4 | 4 |
| 9-2 | 5 | 5 | 5 |
| Avg | 3.1 | 3.6 | 3.8 |
| Stdev | 1.4 | 1.2 | 0.7 |
Table 2. Feedback about our design patterns from participants in the patterns condition (1–5, 5=high)
| Condition | Creativity | Completeness | Quality |
| All pairs | |||
| Patterns
| µ = 5.08 δ = 1.24 | µ = 5.42 δ = 1.00 | µ = 4.67 δ = 1.07 |
| No patterns | µ = 4.00 δ = 1.31 | µ = 4.67 δ = 1.40 | µ = 4.53 δ = 1.51 |
| Pairs with low experience | |||
| Patterns
| µ = 5.17 δ = 0.75 | µ = 5.50 δ = 1.22 | µ = 4.83 δ = 1.17 |
| No patterns | µ = 3.83 δ = 1.17 | µ = 4.00 δ = 1.79 | µ = 4.00 δ = 1.79 |
| Pairs with high experience | |||
| Patterns
| µ = 5.00 δ = 1.67 | µ = 5.33 δ = 0.82 | µ = 4.50 δ = 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.
We emailed 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 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 taskexplored to what degree patterns assisted designers inevaluating an existing design. The designers performed aheuristic evaluation for 30 minutes on a design for alocation-enhanced bus locator. The design consisted oftextual descriptions of what a user can do with the serviceand storyboards that illustrated how the user could interactwith it. The design pairs were asked to go through thesemockups, circling any problems they found and rating theseverity of the problem. Later, we compared the heuristicevaluations between the two conditions to see if there wereany significant differences in the types of errors found.The second task was to design a location-enhanced serviceto help customers in a shopping mall. The designers weregiven a description of what services the mall would like,and could design other complementary services if desired.They were told they could make any assumptions theythought were reasonable, and could use any technologiesthey thought would be available within the next few years.They were given 80 minutes to create a design, using pens,paper, post-it notes, or a whiteboard. Afterwards, they hadanother 10 minutes to present their designs to us as if wewere their client. We videotaped the design andpresentation sessions and later reviewed the tapes to seehow the design patterns affected the design process.Specifically, we looked for evidence of the following:
• Are patterns useful for introducing designers to ubicomp?
• Are patterns useful for communicating between designers? For example, do designers adopt the pattern language vocabulary as they talk about a design?
• Are patterns useful for creating designs?
• Are patterns useful for creating higher-quality designs?
Participant Feedback
After finishing both tasks, the designers filled out aquestionnaire asking for basic demographic information,what type of design background they had, and whether theyhad designed a location-based service before. All of thedesign pairs had GUI and web design experience. Three ofthe nine pairs had designed location-based services before.The design pairs in the patterns condition were also askedwhether they had used design patterns before, and to ratethe usefulness of our design patterns for the evaluation task(task 1), the design task (task 2), and other projects theymight do in the future. This was done on a five-point scale(1=low and 5=high). The results are summarized in Table 2.Overall, the 4 design pairs that used our patterns rated them3.6 of 5 for usefulness in the design task. 5 out of the 8participants gave a 4 or 5 rating. The other 3 gave a 2 or 3rating. Two of these said there was not enough time toabsorb the patterns, and one said that they were a little hardto understand because English was his second language.
No Patterns eativity Completeness Quality
There was no consensus on the usefulness of patterns for
evaluation, with ratings fairly evenly distributed. We
observed that the pairs only used patterns minimally during
the evaluation. Finally, the participants thought overall the
design patterns would be useful for future projects (3.75 out
of 5, no one ranked below 3).
Judging
We also wanted to know if patterns are useful for creating
higher-quality designs. To do this, we recruited three HCI
236
graduate students familiar with ubiquitous computing to
judge the designs. For each design pair, the judges rated the
design on creativity, completeness, and quality on a sevenpoint
scale (1=low and 7=high). The judges watched each
of the ten-minute presentations, without knowing which
pairs were in which condition. The videos were shown in a
different order to each judge to minimize bias. We then
averaged the scores for each question across the judges.
Although the results are not statistically significant,
possibly due to the low number of judges and low number
of participants, the judges on average rated the pairs who
had patterns higher than those who did not, in creativity and
completeness. They also rated them higher in quality,
except for pairs with high experience. See Table 3.
First Evaluation Observations
During the design tasks, we observed several themes.
Patterns Helped Novice Designers
Unsurprisingly, pairs with the least number of years of
design experience struggled the most with understanding
how to apply new technologies in solving problems. For
example, design pairs 3 and 8 (both in the no-patterns
condition and having little design experience) had difficulty
with understanding the capabilities and limitations of
devices, how a location-enhanced application might work,
and what kinds of features such an application might offer.
However, design pairs 5 and 6, who were in the patterns
condition, had a comparable number of years of design
experience to design pairs 3 and 8, but did not face these
same difficulties. Pair 5 had no experience in designing a
location-based service, but extensively used the patterns in
generating ideas and finding solutions. Pair 6 did have some
experience in creating location-enhanced applications and
had some knowledge of ubiquitous computing research, but
still found the patterns useful in coming up with new ideas
and in explaining ideas to one another.
Patterns Helped Designers with Unfamiliar Domain
We also observed that design pairs could quickly make use
of our patterns for a domain that they were unfamiliar with.
For example, neither of design pairs 4 and 5 had ever
designed a location-enhanced application before, but both
pairs made extensive use of the patterns to generate new
ideas and to communicate with one another. It was common
to see one person leafing through the patterns and
skimming through the names and pictures to come up with
ideas. It was also common to see one designer show the
other a pattern to help explain a particular concept. Design
pairs 6 and 9 only made modest use of the design patterns,
but also did not encounter any difficulties using them.
Patterns Helped Designers Communicate Ideas
We expected designers to use the names of the patterns
when they were communicating with one another, but it
turns out that very few of these names were actually said
out loud. More often, designers used the patterns to
communicate ideas by pointing at a particular picture. We
believe that this is because location-enhanced applications
are a new domain with few well-established terms. A
pattern language could help foster the adoption of such
terms, but in retrospect it was unrealistic to expect
designers to adopt these terms in a short design session.
However, one interesting observation is that all of the
design pairs used familiar web metaphors in describing
their ideas, such as “pages”, “cookies”, and “bookmarks”,
as well as the hierarchical organization found in Yahoo and
shopping options found on Amazon. Designers in both
conditions were implicitly using design patterns that they
had direct experience in actually using or had previous
experience in designing. This common grounding helped
designers express ideas quickly and concisely.
Patterns Helped Designers Avoid Some Design Problems
We also observed that some design pairs in the non-patterns
condition often struggled to find solutions, spending a lot of
time on cases that we had patterns for. For example, design
pair 3 spent a large amount of time coming up with what
should be displayed on an Active Map (a map that displays
the user’s current location and nearby points of interest) and
how it would actually work. Active Map (B1) is one of the
patterns in our pattern language, and was one that was used
by all of the design pairs in the patterns condition.
Design pair 7, also in the no-patterns condition, faced a
related problem. As professionals, their design was quite
extensive and had many interesting ideas for optimizing
shopping time and creating wish lists while at the mall.
However, midway through, one of the designers started
disliking the amount of control the application had, saying,
“This is really cool and efficient, but I kind of just want to
wander around.” This was an issue that we actually
addressed in the pattern Serendipity in Exploration (D5).
These two examples point to a deeper issue about patterns.
Many of the designers actually came up with the same
ideas, such as using a map to show a person’s current
location and having comparison shopping. However, one
difference is that design pairs in the no-patterns condition
had to revisit and sometimes fix design decisions more
often than design pairs in the patterns condition. For
example, design pairs 3 and 8, both in the non-patterns
condition, both came up with a kiosk design that they
changed midway through the design task, before changing
to a PDA design that was better suited for the task.
We believe this is because our patterns represent solutions
that others have thought through. Our patterns encapsulated
knowledge about how a solution could be used on a
particular device, how it might work, and how it could be
presented to end-users. In contrast, designers in the nopatterns
condition often had to come up with solutions from
scratch, and sometimes overlooked important tradeoffs.
Patterns Did Not Help With Privacy
As expected, nearly all of the design pairs identified privacy
as a design issue. In all of these cases, the design pairs
237
struggled with this issue for a while and then set the issue
aside to work on the main functionality. In all cases,
privacy was treated as a secondary issue. In many respects,
this matches the evolution of web design. Very few early
web sites addressed privacy in any meaningful way.
Unfortunately, none of the design pairs managed to use our
privacy patterns in any meaningful way. We believe this
happened for three reasons. First, we did not emphasize
privacy sufficiently in the higher-level patterns. Second, the
privacy design patterns are relatively abstract and do not
lend themselves well to visual representations. As noted
earlier, our participants typically leafed through the patterns
to generate ideas, and hence visual representations of actual
solutions worked best. Third, privacy is an abstract concept
that can only be made concrete in the context of an actual
task [17]. It does not make sense to talk about privacy itself,
but rather how a specific design supports or inhibits
privacy. Our patterns discuss privacy in an abstract manner,
making it harder to find direct solutions to problems.
This last point also underscores a subtle issue here with
respect to privacy, which is that customers are unlikely to
judge an application based on its privacy merits alone. As
noted by Whitten and Tygar, security is a secondary feature
that people expect in the context of a task [25]. The same is
true for privacy. Thus, it makes sense that designers would
focus first on functionality and second on privacy.
Designers Generally Liked the Patterns
In general, designers who were in the design patterns
condition did like the patterns. One
designer said, “Good idea to identify
design patterns for ubicomp.” However,
one problem was that there were “too
many patterns to digest”. This designer
summarized his perspective on our
patterns by saying, “If we had more
time, I’m sure that we would be able to
use these patterns to tailor them to our
own ideas.”
SECOND EVALUATION OF PREPATTERNS
Based on the first round of evaluations,
we edited their content to make them
easier to learn and reduced the number of
pre-patterns to 30 for the second round.
We recruited seven pairs of designers for
this round. Three pairs were
professionals, and the other four pairs
were graduate students from local
universities. All but one pair had access
to our pre-patterns (along with the 5
pairs in the non-pattern condition from
the first round, this results in 6 pairs in
each condition for this evaluation). All of
the professionals had a high experience
level, and all of the students were
novices. We also modified the methodology, removing the
heuristic evaluation, adding 15 minutes before the design
task to read the patterns, and adding a short 10-minute quiz to
ensure that the designers were familiar with the patterns. This
approach made it easier for the design pairs to familiarize
themselves with the patterns before doing the design task.
Participant Feedback
9 out of 12 designers in the pattern condition felt that the
design patterns helped with the design task, and 11 out of 12
felt that the design patterns would help with their future
work. We also received stronger positive feedback regarding
the patterns. One designer said, “These patterns are almost
like a checklist. You can cover all of your bases.” Nearly all
of the designers at the end of the study expressed interest in
our patterns.
Judging
To judge the designs in the second round, we recruited a
student who was a teaching assistant for an undergraduate
HCI class, and two researchers familiar with ubicomp. For
each pair, the judges rated the design on how much they
agreed with ten statements, such as “Using this device would
enable me to accomplish tasks more quickly,” and “I would
find this device useful at the mall,” on a seven-point scale
(1=low and 7=high). The judges watched each of the tenminute
presentations, without knowing which pairs were in
which condition. We then averaged the scores for each
question across the judges.
Although most of the results are not statistically significant,
Condition
Accomplish
tasks more
quickly
Privacy
would not be
compromised
Make product
& store info
more available Useful
All pairs
High
experience
µ = 5.50
δ = 0.55
µ = 4.28
δ = 1.18
µ = 5.33
δ = 0.67
µ = 5.17
δ = 0.51
Low
experience
µ = 4.22
δ = 0.78
µ = 4.44
δ = 0.75
µ = 4.44
δ = 0.62
µ = 4.06
δ = 0.93
All pairs
Patterns µ = 5.11
δ = 1.07
µ = 4.22
δ = 0.96
µ = 4.72
δ = 0.88
µ = 4.67
δ = 1.26
No patterns µ = 4.61
δ = 0.77
µ = 4.50
δ = 1.01
µ = 5.06
δ = 0.68
µ = 4.56
δ = 0.50
Pairs with low experience
Patterns µ = 4.33
δ = 0.88
µ = 4.78
δ = 0.77
µ = 4.11
δ = 0.69
µ = 3.78
δ = 1.26
No patterns µ = 4.11
δ = 0.84
µ = 4.11
δ = 0.69
µ = 4.78
δ = 0.38
µ = 4.33
δ = 0.58
Pairs with high experience
Patterns µ = 5.89
δ = 0.51
µ = 3.67
δ = 0.88
µ = 5.33
δ = 0.58
µ = 5.56
δ = 0.19
No patterns µ = 5.11
δ = 0.19
µ = 4.89
δ = 1.26
µ = 5.33
δ = 0.88
µ = 4.78
δ = 0.38
Table 4. A subset of an analysis of the judges’ ratings of the designs, on a scale of
1–7 (7=high). Bold pairs of cells show significant differences (paired t-test, p < 0.1).
238
the judges overall rated novice pairs who had patterns lower
than those who did not in 7 out of 10 questions. However,
they rated expert pairs who had patterns equal or higher than
those who did not in 9 out of 10 questions. They also rated
expert pairs without patterns higher than novice pairs with
patterns in all 10 questions. One possible interpretation is that
having experience is more important than using patterns, but
expert designers know how to apply patterns better than
novices and therefore get more benefit from them. The few
statistically significant results, which are shown in Table 4,
also lend themselves to this interpretation.
Second Evaluation Observations
We had several interesting qualitative observations on the
effects of the pre-patterns on design. More design pairs
adopted the language of the patterns verbally than in the first
round. Also, the design pairs often communicated their ideas
through physical exchange of the patterns and by pointing to
examples more readily than in the first round.
One pair mentioned that they used the pattern groups as “a
way to organize their ideas.” Another pair drew inspiration
from the Serendipity in Exploration (D5) pattern, stating that
the location-based service they were designing “should not
be a pushy salesperson but allow for free roaming.” A third
pair used the patterns in an unanticipated way. Instead of
simply culling ideas from the patterns, they annotated their
designs with particular pattern references (e.g., writing “A1:
Active Map” next to their sketched UI). One of the designers
in the pair said, “It’s interesting because these [patterns] all
sort of lay out the problem and the solution on a page, so just
by saying that C2 is this one—it’s actually a quicker way of
going through this whole procedure.”
However, the participants still failed to take advantage of the
privacy patterns. 4 out of 6 pattern groups talked about
privacy, but only one group actually used any of the privacy
patterns directly, using three privacy patterns.
FUTURE WORK
In the future we will use feedback from the designers to
make another iteration on our pattern language. We are
especially interested in how to make the privacy patterns
easier to understand and use. We will also continue our
evaluations to further our understanding of how design
patterns can help designers.
CONCLUSION
In this paper, we introduced the first pattern language for
ubiquitous computing, consisting of 45 pre-patterns
organized into four pattern groups. These pre-patterns discuss
application genres, physical-virtual spaces, interaction and
systems techniques for managing privacy, and techniques for
fluid interactions. We also discuss what we believe is the first
controlled study of design patterns with designers. We asked
sixteen pairs of designers to design a location-enhanced
application. We observed that 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.
ACKNOWLEDGMENTS
We thank Quan Tran, Chris Beckmann, Jeff Heer, Alan
Newberger, Ed de Guzman, Tara Matthews, and the rest of
GUIR for their early feedback on our design patterns. This
research has been funded by NSF (IIS-0205644).
REFERENCES
1. Third European Conference on Pattern Languages of Programming
and Computing. http://www.coldewey.com/europlop98/cfp.htm
2. Alexander, C., A Pattern Language: Towns, Buildings, Construction:
Oxford University Press, 1977.
3. Bayle, E., et al., Putting it all together: towards a pattern language for
interaction design, SIGCHI Bulletin, vol. 30(1): pp. 17-23, 1998.
4. Borchers, J., A Pattern Approach to Interaction Design: John Wiley
and Sons, 2001.
5. Casaday, G. Notes on a Pattern Language for Interactive Usability. In
Proceedings of Human Factors in Computing Systems: CHI 1997.
Atlanta , GA. pp. 289-290 1997.
6. Dearden, A., J. Finlay, L. Allgar, and B. McManus. Evaluating
Pattern Languages in Participatory Design. In Proceedings of Human
Factors in Computing Systems: CHI 2002 (Extended Abstracts).
Minneapolis , MN . pp. 664-665 2002.
7. Erickson, T., The Interaction Design Patterns Page.
http://www.pliant.org/personal/Tom_Erickson/InteractionPatterns.html
8. Erickson, T. Lingua Francas for Design: Sacred Places and Pattern
Languages. In Proceedings of Symposium on Designing Interactive
Systems 2000 (DIS2000). New York , NY . pp. 357-368 2000.
9. Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns:
Addison-Wesley, 1995.
10. Graham, I. , A Pattern Language for Web Usability. Reading , MA :
Addison-Wesley, 2003.
11. Kidd, C.D., et al. The Aware Home: A Living Laboratory for
Ubiquitous Computing Research. In Proceedings of The Second
International Workshop on Cooperative Buildings - CoBuild'99
1999.
12. Landay, J.A. and G. Borriello, Design Patterns for Ubiquitous
Computing, Computer, vol. 36(8): pp. 93-95, 2003.
13. Meszaros, G., A Pattern Language for Pattern Writing. 2000.
http://hillside.net/patterns/writing/patternwritingpaper.htm
14. Nielsen, J., When Bad Design Elements Become the Standard. 1999.
http://www.useit.com/alertbox/991114.html
15. Pfeiffer, E.W., WhereWare. MIT Technology Review, 2003: p. 46-52.
16. Rekimoto, J. Pick-and-Drop: A Direct Manipulation Technique for
Multiple Computer Environments. In Proceedings of 10th ACM
Symposiusm on User Interface and Software Technology (UIST'97).
Banff , Canada . pp. 31-39 1997.
17. Schwartz, B., The Social Psychology of Privacy. American Journal
of Sociology, 1968. 73(6): p. 741-752.
18. Siegel, D., Set Your Link Colors Ergonomically. 1996.
http://www.dsiegel.com/tips/wonk3/links.html
19. Tidwell, J., Common Ground: A Pattern Language for Human-
Computer Interface Design. 1999.
http://www.mit.edu/~jtidwell/common_ground.html
20. UsabilityNet, Card Sorting.
http://www.hostserver150.com/usabilit/tools/cardsorting.htm
21. van Duyne, D.K., J.A. Landay, and J.I. Hong, The Design of Sites:
Patterns, Principles, and Processes for Crafting a Customer-
Centered Web Experience. Reading , MA : Addison-Wesley, 2002.
22. van Welie, M., Web and GUI Design Patterns. 2001.
http://www.welie.com/
23. van Welie, M., K. Mullet, and P. McInerney. Patterns in Practice: A
Workshop for UI Designers. In Proceedings of Human Factors in
Computing Systems: CHI 2002. pp. 908-909 2002.
24. Weiser, M., The Computer for the 21st Century. Scientific American,
1991. 265(3): p. 94-104.
25. Whitten, A. and J.D. Tygar. Why Johnny Can't Encrypt: A Usability
Evaluation of PGP 5.0. In Proceedings of 8th USENIX Security
Symposium. pp. 169-184, Aug 23-26 1999.
239
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)
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)
Active Map (B1)
Topical Information (B2)
Successful Experience Capture
(B3)
User-Created Content (B4)
Find a Place (B5)
Find a Friend (B6)
Notifier (B7)
Fair Information Practices (C1)
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)
Keeping Personal Data on
Personal Devices (C15)
Scale of Interaction (D1)
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)
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.
240
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.
241
Figure 3. Some more examples of our pre-patterns for ubiquitous computing.
242
翻译（部分）：
新的普适计算中的设计模式的开发和评估
Eric S. Chung1, Jason I. Hong1, James Lin1, Madhu K. Prabaker1, James A. Landay2, Alan L. Liu2
1Group for User Interface Research
Computer Science Division
University of California
Berkeley , CA 94720 USA
{jasonh, jimlin}@cs.berkeley.edu
2DUB Group
Computer Science and Engineering
University of Washington
Seattle , WA 98195 USA
landay@cs.washington.edu
摘要
设计模式是一种获得和分享设计知识的形式。在这篇论文中，我们关注到了设计模式的一个新的领域，即普适计算。这项工作的总体目标是通过加快推广新技术的交流和研究人员提出的对结果的评价（通常这些评价对实际设计者以一种更有用的方式来展现信息）来辅助工程实践。为此,我们已初步研制出一种新的专门为普适计算而设计的模式语言，包括45种用来描述应用程序的各种类型的准模式，物理-虚拟空间、交互性和管理隐私的系统技术，以及流畅交互的技术。我们通过帮助16对设计者来设计位置强化的应用程序的方式评估了我们的准模式(pre-patterns)的有效性。我们看到，我们的准模式帮助了那些新的、对普适计算不熟悉的但是有经验的设计者们想出和交流想法，并且能够在设计过程的早期避免设计的一些问题。
关键词
设计，设计模式，普适计算
ACM分类关键词
H.5.2 [信息接口与表示]: 用户接口—理论与方法，风格向导，评估/方法学
概述
设计模式作为一种获得知识和在从业者之间分享知识的形式已经在很多领域被提出来了（例如，[2-5, 9, 21, 23]）。模式以一种紧凑的方式抓住了一些重复出现的问题的本质以及相应的解决方案，能够深入地交流设计中的问题。它们深入地描述这个问题，解决方案的基本原理，以及在应用这些解决方案时的一些利弊权衡。在特定领域的一系列相互联系的模式称为一种模式语言。
模式与其他一些（比如指导方针和启发式）获得设计知识的形式在以下三点上不同。第一，模式提供的是对特定的问题解决方案而不是高层次的，有时甚至是抽象的建议。第二，模式是生成的，通过展示许多实际的设计的例子来帮助设计者创建一个新的解决方案。第三，模式在层次上是彼此相互联接的，帮助设计者既解决高层次的问题也解决低层次的问题。模式并非要取代指导方针和启发式(heuristics)，而是对它们的一种补充。模式只是另外一个帮助设计者创建高质量解决方案的工具。
模式语言发源于建筑领域[2]，并且已经应用在用户界面设计（例如，[4, 7, 19, 22]）和Web设计等方面（例如，[10, 21, 22]）。我们已经可以看到设计模式在软件设计领域取得了巨大的成功，就像GoF(译注: 指的是《设计模式》一书的四位作者Erich Gamma，Richard Helm，Ralph Johnson，John Vlissides，被誉为软件领域的设计模式之父)的《设计模式》的成功和这些模式的名称在软件开发社区的广泛使用所向我们展示的那样。最后一点是设计模式的又一重要贡献，它提供了一个共同的、共享的词汇，使得设计者能够更容易地沟通。
这里，我们扩展了这个想法，把设计模式作为一种辅助设计者为普适计算(ubiquitous computing ,缩写为ubicomp)（那些利用传感器、各种形式的要素的计算机装置，以及无线网络的系统）开发应用的形式来辅助我们进行各种各样的任务[24]。
尽管普适计算还处在新生阶段，但是现在来开发一种模式语言仍然有许多潜在的好处。首先，可以加快推广新技术、交流评价结果，并且把结果以一种对设计者更有用的方式表现出来。第二，一种用于普适计算的模式语言可以帮助我们更清楚地看到想法之间的联系以及哪些问题还有待解决。第三，可以产生积极的影响，帮助设计新应用设计者找到好的解决办法，避免采用差的标准，比如不充分的隐私保护和蓝色的Web链接（注：曾经被多个设计者提到，例如[14,18]，由于人眼睛的结构，蓝色非常不适合作为Web页中尚未访问过的链接的颜色。但是由于如此之多的Web页面如此使用并且如此之多的人已经知道了这个意义，“蓝色的Web链接”就成为了一个事实上的标准。）类似地，当元素周期表最初发展的时候，门捷列夫并没有把那些未知的元素强行填充进去。相反地，他留下了空白并且做出了关于这些未知元素的预言来帮助其他人最终完成他们各自的发现。
为此,我们提出了使用于普适计算的原始的模式语言。这种语言包括45种用来描述应用程序的各种类型的准模式，物理-虚拟空间、交互性和管理隐私的系统技术，以及流畅交互的技术。我们把他们称为“准模式”是因为他们仍然处于新生阶段并且尚未在设计社区和最终用户中得到广泛应用。然而，我们发现以模式的形式来交流设计的知识是很有用的，即使这些知识并非金科玉律。我们希望这些准模式能够随着时间的推移不断地演化，其中一些再被新的模式所取代。
我们还尽我们所知，指导了设计者第一轮受控的学习来学习模式。在我们的第一轮的评估中，我们让9对设计者为一个位置强化的应用创建一个初始的设计。其中4对使用了我们的准模式而另外5对没有使用。在第二轮评估中，我们根据第一轮的反馈修改了这些模式，并且让6对设计者每对其中的一个使用我们的模式而另一个不使用。这让我们在第二轮中对这6对设计者各自的两种情况进行比较。
在第一轮的评估计中，使用了模式和没有使用的那些设计者对之间在质量、完整性和创意上并没有多大的区别。而第二轮时则在某些要素，比如完成任务的及时性和有效性方面有了很大的差别。尽管大多数这些差别主要由于设计者是专家还是新手的差别，而不是由于这些设计者们是使用了还是没有使用模式的差别。但是，我们对这两轮的定性的观察指出，模式帮助了那些新手设计者创建设计，帮助了那些在普适计算领域不熟悉的但有经验的设计者，帮助了设计者之间沟通思想，也帮助了设计者在较早的设计过程中避免潜在的问题。令人惊讶的是，尽管我们有一整组的关于隐私方面的模式，但是它们在这个问题上似乎并没有发挥什么作用。一般而言,设计者们发现我们的准模式还是很有用的。
相关工作
设计模式最初是由Christopher Alexander和他的同事们[2]提出的。Alexander认为，模式能够通过为设计提供一种鲜活的、共同的语言来增强建筑师和他们的客户的能力。他和他的同事们为建筑和规划城镇、街道、房屋、花园、房间提出了253种模式。这里的重点是，这是一个完整的用于设计的语言，因为模式的有效性不仅在于它对一般性的问题提供解决方案，我们也能看到它们彼此之间的相互关系和影响。
我们的普适计算模式语言使用了INTERACT ’99的定义：“一门HCI模式语言的目标是在HCI专家之间分享成功的HCI设计解决方案……”[4]。另外一种变通的、有一定互补意义的观点是使某种模式语言成为一种对设计者而言通用的语言[6, 8]。尽管后者拥有分享设计的潜力，但这不是我们开发和评估我们的设计模式的过程中所关注的。
典型地，模式是通过同行审查的方式来进行评估，通常是在模式研讨会上[1，13]。尽管设计模式的想法已经存在相当一段时间，但是直到最近才有了对模式进行评估的工作。例如，Borchers开发并且评估了一种为交互式的音乐展览而设计的模式语言，他评估的方式是通过使用这些模式来开发两套交互式音乐展览进行对比，以及通过调查那些为了更有效和更容易记忆而采用了一些模式的本科生[4]。Deardenet al评估了一套为开发航线和铁路旅游站点的模式，他是和这套系统的潜在用户而不是和设计者们一起进行着项评估的。他们调查了这些模式是否能够增强用户在参与可供分享的设计和创建设计方面的能力[6]。
然而，据我们所知，目前还没有一项研究来评估模式在帮助设计者交流、与他人一起设计的效果如何。我们在这方面迈出了第一步,关注那些对使用了我们的模式的设计者在学习一个新的领域、和他人交流、评估已有的设计以及创建一个新的设计等各方面的表现如何。
一门用于普适计算准模式的语言
在这部分中，我们给出了一个我们用来创建普适计算模式语言的方法的概貌，也提供了那些准模式本身的描述。
语言开发
开发这门模式语言是一个持续了几个月的反复的过程。我们开始时根据回顾已有的文献资料对一些候选模式进行自由讨论。我们最初试图创建高层的模式，比如说是那种相当抽象,描述整个应用的，而不是只描述单一屏幕的。这是很困难的事情，因为这意味着要试图在创建这些模式本身的同时也要创造它们的层次关系。最后我们发现采用自底而上的方式要简单得多：找出相对低层和中层的单独的模式，然后再把它们连接在一起。
我们通过粗选的方法产生了大约80个相当广泛的候选模式，它们关注于普适计算在交互式和基础设施等方面的问题。我们特别关注了那些基于位置计算的模式，因为相当多的这种应用出现在市场上，因而较普适计算中的其他领域来说具有更广泛的部署途径[15]。后来我们放弃了基础设施的模式，而是关注于交互式问题，因为我们想重点帮助那些需要交互式的设计者们。
有些准模式处理高层的遍及普适计算各个领域(如隐私)的一些根本问题，而另外一些则处理相对比较低层的交互式技术(如采集和丢弃[16]).我们试图为每个模式至少找到两个例子，并且一般选择商业的实现因为这说明该模式更有可能得到广泛的应用。
然后我们做了一个分类[20]来把各个候选的模式组织到了不同的模式组里，每个组里的模式都有一个相同的主题。然后，我们为每一个模式创造了主要内容，描述问题和解决方案，提供了范例，并建立了相关模式的链接。每个模式都由至少3名作者编写、编辑，并且都限制在两页以内以便于设计者消化。我们去掉了那些不好的候选模式并且加入了一些有意义的新的模式。
接下来我们从另外四名对普适计算熟悉的研究者那里征求了反馈。我们首先给这些研究者一个模式的名称，让他们猜这个模式会包含什么内容。然后，我们再把这个模式的内容展示给他们，并让他们评价模式名称的质量、评论模式实际的内容。我们根据这些反馈来修订模式。
最终，我们选取了4组的45个模式（见此论文末尾的图1）：
• 描述普适计算中广泛的类的普适计算类型（Ubiquitous Computing Genres）.
• 关注于如何把物理的和虚拟的对象和空间融合在一起的物理-虚拟空间（Physical-Virtual Spaces）.
• 描述如何处理最终用户隐私的策略和机制的成功开发的隐私（Developing Successful Privacy）.
• 详述了和传感器等设备交互技术的设计流畅的交互（Designing Fluid Interactions）.
所有的用于前两轮评估的准模式可以在以下网址找到 http://guir.berkeley.edu/projects/patterns
模式的格式
我们模式的格式与《站点设计》[21]和《一门模式语言》[2]中描述的类似。图2和图3（位于本篇论文的末尾）展示了我们的准模式的首页。每一种准模式包含了以下几点：
• 一个名称和一个字母-数字对，其中该字母指出了这个模式属于哪一个组。比如，"A3"指的是在组A（普适计算类型）中的第3个模式。
• 模式的背景，它提供了该模式的上下文和范围，并且描述了其它可能导致该模式的其他所有模式。
• 该模式要处理的问题。
• 对这个模式要处理的问题的解决方案（或者解决方案的集合），也指向其他可能对解决此问题有帮助的低层模式。
• 和这个模式相关的工作的参考资料。
图4. "巴士图",说明在一个模式组中的各个模式是如何相联系的。 这里,有四个在设计应用时很基础的核心模式(A1通过A4)，以及若干特定于应用类型的模式。
我们也创造了我们所谓的"巴士地图"。每幅地图展示了在一个模式组中的核心模式和在该模式组中的模式之间的关系（参见图4）。我们的模式倾向于更具有说明性而不是描述性，主要是因为在实际中普适计算的应用不多。同时，我们的模式也倾向于关注于高层的问题，如用户的需要，相对于具体的用户界面和交互式技术。这是因为许多高层的问题相对于低层的用来实现它们的技术更好理解。例如，许多人已经提出了解决智能住宅问题(如[11])所需要的，但在该领域中特定的交互性方面很少取得广泛的成功。
对准模式的第一轮评估
我们通过让设计者使用我们的设计模式来评估和设计位置强化的应用的方式来评估了这些模式的有效性。这一节描述了我们的第一轮评估。
参与者
九对设计者(一共有18对设计者)参加第一轮。其中四对是专家，而另外五对是加州大学Berkeley分校系统和信息系统和管理学院的毕业生。这些专家组成的设计者对平均有8.5人年的相关经验（分布范围为6到10人年），而这些学生组成的设计者对则平均有4人年的相关经验（其中有一对有8人年，而其他的对最多只有3人年）。
这些设计者对根据经验被分成了两类。经验丰富的对至少有6人年的相关经验，而经验不足的则最多只有3人年。他们也被分成两种情况，其中4对使用模式而另外5对不使用（参见表1）。
|
| 经验丰富 | 经验不足 |
| 使用模式 | 4, 9 | 5, 6 |
| 不使用模式 | 1, 2, 7 | 3, 8 |
表1. 我们的第一轮评估中设计者对的情况。例如，编号为4和9的设计者对具有丰富的经验，并且他们使用了模式。
|
| Patterns useful for Evaluation Task | Patterns useful for Design Task | Patterns useful for Other Projects |
| 4-1 | 2 | 4 | 3 |
| 4-2 | 4 | 4 | 3 |
| 5-1 | 2 | 5 | 4 |
| 5-2 | 4 | 3 | 3 |
| 6-1 | 3 | 2 | 4 |
| 6-2 | 1 | 2 | 4 |
| 9-1 | 4 | 4 | 4 |
| 9-2 | 5 | 5 | 5 |
| 平均 | 3.1 | 3.6 | 3.8 |
| 标准差 | 1.4 | 1.2 | 0.7 |
表2. 使用模式的那些参与者对我们的设计模式的反馈(1–5, 5最高)。
| 情况 | 创造性 | 完整性 | 质量 |
| 所有的设计者对 | |||
| 使用模式
| µ = 5.08 δ = 1.24 | µ = 5.42 δ = 1.00 | µ = 4.67 δ = 1.07 |
| 不使用模式 | µ = 4.00 δ = 1.31 | µ = 4.67 δ = 1.40 | µ = 4.53 δ = 1.51 |
| 有经验的设计者对 | |||
| 使用模式
| µ = 5.17 δ = 0.75 | µ = 5.50 δ = 1.22 | µ = 4.83 δ = 1.17 |
| 不使用模式 | µ = 3.83 δ = 1.17 | µ = 4.00 δ = 1.79 | µ = 4.00 δ = 1.79 |
| 有丰富经验的设计者对 | |||
| 使用模式
| µ = 5.00 δ = 1.67 | µ = 5.33 δ = 0.82 | µ = 4.50 δ = 1.05 |
| 不使用模式 | µ = 4.11 δ = 1.45 | µ = 5.11 δ = 0.93 | µ = 4.89 δ = 1.27 |
表3. 设计的裁判排名的分析，分数范围为1-7(7最高)。裁判的评判结果中，一般来说，使用了模式的得分要比没有使用的那些设计要高，除了那些有丰富经验的设计者对。(译注：µ为平均值，δ为标准差)
我们在事前两天使用电子邮件把模式发送给了那些需要使用模式的组以便他们可以熟悉这些模式。这种情况下的设计者在此期间也获得了模式的副本，并且在评估开始之前有几分钟的时间来检查它们。
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1330430
1704
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
