Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing, presented at DIS2004
•Transferir como PPT, PDF•
0 gostou•1,544 visualizações
Our work on creating and evaluating design patterns for ubicomp
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (20)
Semelhante a Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing, presented at DIS2004
Semelhante a Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing, presented at DIS2004 (20)
Último
Último (20)
Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing, presented at DIS2004
- 1. Development and Evaluation of Emerging Design Patterns for Ubiquitous Computing Eric Chung Jason Hong Madhu Prabaker James Landay Alan Liu Carnegie Mellon Carnegie Mellon University of California, Berkeley University of Washington University of Washington
- 2. What Are Design Patterns? Design patterns communicate common design problems and good solutions in a compact form Started in architecture, recently for user interfaces – Ex. Navigation Bar
- 3. Design Patterns for Ubicomp? Ubicomp pushes computing into physical world – Wireless networking, sensors, devices Still in early phases of ubicomp, so why create a pattern language now? Speed up diffusion of interaction techniques and evaluation results Help us see links between ideas, see what’s missing – Like first periodic table Help designers avoid bad standards – Avoid blue links and poor privacy
- 4. Our Work on Ubicomp Design Patterns Developed 45 patterns for ubicomp Evaluation with sixteen pairs of designers (32 total) – 9 pairs in first round of eval, 7 pairs in second round – Compared the design of a location-enhanced app with and without patterns – Better communication? Novices and experts? Privacy?
- 5. Talk Outline Overview Method for Creating the Patterns Evaluating the Patterns Future Work
- 6. Method for Creating the Patterns Iterative process over three months Literature review to extract ideas – Tried to do top-bottom, too hard – Bottom-up much easier, card sorting to organize into groups 80 pattern candidates, focusing on interaction design – 2 pages each – Critiqued by four other researchers Cut to 45 patterns for the first evaluation
- 7. Example Pattern A12 – Enabling Mobile Commerce
- 8. Example Pattern A12 – Enabling Mobile Commerce
- 9. Some More Example Patterns A – Application Genres VirtualInteractions B – Physical /– Fluid Spaces C –D Techniques for Privacy
- 10. Bus Stops for Relating Patterns
- 11. Talk Outline Overview Method for Creating the Patterns Evaluating the Patterns Future Work
- 12. First Round of Evaluation Nine pairs of designers High Exp (6+ yrs) Low Exp Patterns 2 pairs 2 pairs No Patterns 3 pairs 2 pairs Prototype a location-enhanced guide for shopping mall – Gave each pair a set of general goals to support – Could add any reasonable features, use any reasonable technologies – 80 minutes to prototype, 10 minute presentation to “client” Will focus on qualitative results – Had judges rate designs quantitatively, statistics hard though
- 13. Observations from First Round Eval Patterns helped novice designers – Novices without patterns struggled with tech, features – Novices with patterns fared better, patterns useful for getting ideas and explaining concepts to one another Patterns helped experts with an unfamiliar domain – Skim thru patterns to get ideas, see range of possibilities Patterns helped designers communicate ideas – Expected designers to adopt names (unrealistic in retrospect) – Common to see designers point at pictures – Many design pairs leveraged a web pattern language Navigation Bar, pages, cookies, bookmarks
- 14. Observations from First Round Eval Patterns helped designers avoid some design problems – Most teams came up with similar solutions in both conditions – But teams w/o patterns had to re-visit solutions more often Had to re-invent wheel and re-learn mistakes Patterns did not help with privacy – Most design teams identified privacy as a problem – But the teams didn’t use our patterns… Designers generally liked the idea of patterns – “Good idea to identify design patterns for ubicomp” – But… “Too many patterns to digest” – “If we had more time, I’m sure that we would be able to use these patterns to tailor them to our own ideas.”
- 15. Second Round of Evaluation Reduced to 30 patterns Edited some content, added more links Seven pairs of designers – Six pairs had patterns, one did not Already knew what non-pattern condition results were – Same task – Same amount of time
- 16. Observations from Second Round Eval 9 of 12 thought patterns helped with design task 11 of 12 thought patterns would help with future designs “These patterns are almost like a checklist. You can cover all of your bases.” Patterns used more often to communicate ideas Some patterns used to inspire designs – D5: Serendipity in Exploration, app “should not be a pushy salesperson but allow for free roaming.” One pair used patterns to annotate ideas – B1: Active Map next to the sketched UI But only one group used the privacy patterns…
- 17. Future Work Continued evolution and evaluation of the patterns Why didn’t privacy patterns work as we expected? – Unclear format? Too abstract? Too specific? – Not enough links? Too many patterns? – Important b/c we want to avoid expected privacy problems Landay and Prabaker working on ubicomp patterns for the home at Intel Research Seattle – 20 new patterns for the home – 22 pairs of designers, half with patterns, half without – Data analysis in progress
- 18. Summary Design patterns for ubicomp – 30 patterns in current set Evaluation with 16 pairs of designers – Generally useful in design task for generating and communicating design ideas – Still didn’t use privacy patterns Our patterns can be downloaded at: – http://guir.berkeley.edu/patterns – Any feedback appreciated – Help us evolve them!
Notas do Editor
- Emerged over time as a good solution Similar characteristics, but different, tailored to the needs of the specific web site Capture the essence, but apply in many different situations
- Most results and design knowledge on ubicomp still in research paper format
- Define pre-patterns
- 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. “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.”
- 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. “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.”
- 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.
- 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.