UI Design Patterns
From CS 160 Fall 2010
pdf Slides
Readings
A pattern approach to interaction design Jan Borchers, Proceeding DIS '00 Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques, ACM 2000.
Android UI Design Patterns R. Fulcher et al., Presentation from Google I/O Conference 2010. A video version appears here
Your Response
Login by using your user name and password, edit the page and at the end of it put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.
Jonathan Look 22:39, 14 November 2010 (CET)
I actually enjoyed watching the Google presentation and thought it was informative. In regards to the clear vs. simple point in their design philosophy, I would say this highlights the minimal/aesthetic design criterion and also how a UI should have a clear mapping between appearance and functionality. I also liked the mention of the 'cloud', as the point about a user configuring something once should be enough. However, when considering mobile devices, I am not sure if a 'one size fits all' configuration works in all situations, as some configurations may be more suitable for specific devices (i.e. screen size and organization of icons may not transfer from device to device).
In regards to Borcher's reading, the discussion about Nielson's engineering lifecycle model and the use of patterns in each phase of the design seems like an interesting process by which various members of a team can meet a project's requirements
Frank Chew 23:56, 14 November 2010 (CET)
This author stresses the use of the term pattern to describe a common solutions in design. To be more specific, a pattern has a name, a context, a problem, a solution, examples, diagrams, and cross references. When writing code for a specific language, many coding patterns can be found on the internet in forums, searching by the problem keywords, however finding a diagram as part of a pattern on the internet is usually uncommon.
This was quite an interesting article in the widgets that make an android app look great. They discussed the companion widget, the dashboard, the action bar, the quick actions, and the search bar. The companion widget is the launcher of the app that goes on the main screen. The dashboard is the initial main menu in the app (with 3-6 buttons). The action bar is the title bar of the app that goes at the top, with functions available across the entire app. The quick actions is a contextual popup with actions for objects. And the search bar allows the user to search across the data of the application.
Theron Ji 01:04, 15 November 2010 (CET)
For the first paper, I was pretty confused about what they were trying to do. In particular, the eleven activities it talks about fitting into a "usability engineering lifecycle" is not shown to us, so I'm not sure what its referring to. For the Android video on UI, it made several good points that were general to all UIs, and not just for the Android. Many of the points were common sense topics. The examples it gave though (dashboard, action bar, quick actions, etc.) seemed to be quite specific to particular applications, and I don't see many direct ways to apply it to my own application. I liked the quote from Socrates, and the way to think of UI design as not purely functional, but also as trying to persuade the user that they want to use it (this implies that the user isn't necessarily always the bottom-line, but that good design can influence change in how people view the interface).
Alex Aberle 03:02, 15 November 2010 (CET)
What better way of connecting the technical team with the nontechnical domain experts than by introducing a DAG of formal pattern nodes and a first-order logic relating those patterns? Also lets throw in a bizarre and arbitrary ranking system just to spice things up. Why yes, I am an idiot, why do you ask? Luckily, the list of 11 guidelines and the examples of patterns were actually right on the nose and quite helpful. I have to say I'm beginning to suspect that HCI people spend way too much time attending conventions, though. There were, what, four or five annual conferences mentioned in this article alone? And how many others not mentioned? Sounds pretty cushy, actually.
The Android powerpoint was much more down to earth. Practical. The five patterns that they mention get used widely, and it's nice to see some ground rules for how and when they should be used. More than just for an individual app, continuity in UI design over a large number of apps is quite pleasing visually and psychologically. Apple enforces consistent UIs with the iPhone app store, and I think it is paying off in spades. It increases the overall confidence in the platform, and makes people more likely to spend money on apps sight-unseen. Definitely worth it for a company whose business model takes a cut from every app sale.
Alexander Bolotov 03:38, 15 November 2010 (CET)
It seemed rather humorous to me that a paper whose stated purpose was to remove communication hurdles between several different types of experts working on different aspects of a single application was written in a very technical and cryptic language. However, once deciphered, the paper's idea seemed rather commonsense: namely, that in UI design, as well as in other fields, large and complex design tasks can be split up into smaller problems, each of which can be solved with a preexisting solution pattern. Such patterns are universal across a field (and perhaps beyond the confines of one field) and can be easily picked up even by laymen simply by observing examples of others' successful solutions. The Android talk making essentially the same points, and was delivering the same message cast in more practical and immediate terms.
Sean Tai 06:10, 15 November 2010 (CET)
In the first reading, the idea of using “parallel design” was interesting. This seems be a principle that IDEO used in the “Deep Dive” video when they had teams design shopping carts for different design goals and then combined the best parts of the multiple designs for the final design.
The second reading showed that Google tried to encourage consistent elements across all of its Android applications to make it easier for users. However, in developing our application for this class, I have not heard about or found a real need for anything like an “Action Bar” or “Quick Actions,” so the Android team could stand to make some of its design work more widespread and easier to use for developers.
Daniel Yoo 09:28, 15 November 2010 (CET)
I really liked the suitable process framework to think about before doing any UI modeling – know the user, setting usability goals, prototyping, and etc. Before taking this class, I never thought UI design would take so much time on thinking and considering many details where the user could easily interact with any devices. Now that I am in a process of making an application for the project in this course, I realized how many time I had to make a change on UI design because the users could not find the proper command. Even in the google presentation, I can see how hard they work for making a better design and less confusing for the users.
Brian Maissy 07:26, 15 November 2010 (CET)
The concept of design patterns seems really useful, both for keeping individual applications working as effectively as possible, and for establishing a consistent pattern of interaction on a platform. This makes the entire system feel like a unit aesthetically, and accelerates learning of the interfaces, because the common elements are shared and the user builds intuition about them.
Calvin Wang 07:29, 15 November 2010 (CET)
The Pattern Language presented in the Borchers paper is a promising way to organize information in order to better represent a design problem. It defines a clear structure for the various design tradeoffs, and sets up a relatively rigorous theoretical framework within the fuzzy world of design. This may potentially allow AI/ML approaches to analyze design problems to some extent.
I watched the Google Android UI Design Principles talk. It is very informative, but I found some principles presented to be a little inconsistent with common HCI heuristics, most notably affordances of clickable items. According to the talk, as much of the screen area as possible should be clickable to maximize the usefulness of the app, but many of the clickable-ness is not obvious from an end-user's point-of-view. For instance, the Twitter logo suggests nothing about its clickable-ness when you consider its affordances. I doubt whether this is good UI design practice.
Andy Lin 07:34, 15 November 2010 (CET)
One main point that I agree on from the first reading is that communication is one main problem of HCI practitioners. As a result, following the design pattern language is important. One thing I noticed is that the examples that the reading shows is really a good way to write a report with context, problem, solution, example, and references specified in each section. Since the main job for a report is to let people who do not actually do the design understand what is going on, the design pattern language is proved to be useful.
The video shows many different design patterns of Android user interface. It gives clear reasons why certain patterns are designed. I especially love how they design the icon and display with multiple screen sizes and pixel densities. I think that is one thing that we should work on for our project.
Vincent Rodriguez 07:40, 15 November 2010 (CET)
I feel that the reading that talked about patterns could have simplified how it presented the idea if it perhaps used simpler terms to explain what it is it actually wanted to do. If, perhaps, they called them processes, or, say, described them as a way of organizing data into a form that is easily recognizable. I suppose that that is what the reading was about exactly, and I just completely missed it the first time through. Personally, I think having patterns is a good idea, because people tend to try to interpret data that is presented to them in ways that they have done before. If we present the user a pattern that they know how to interpret already, then we know that they will understand what we are trying to tell them (hopefully).
The Google talk was interesting because it shows a real life application of patterns. It also gave a couple of insights that I think will be useful for our projects.
Don Arboleda 07:54, 15 November 2010 (CET)
From the way Googles slides describe it, designing an interface should be a fairly simple process. I suppose it's a characteristic of design patterns in general. Unfortunately for us, nothing is ever that simple. It's up to us the designers to figure out what's most important for everyone. There's a reason many of the slides have the subtitle "Recommendations" rather than something more concrete. I do find it kind of odd that the Action Bar replaces the Search Bar and vice versa. What exactly do they mean by this? Do they feel it's better to have a Search Bar that slides over the Action Bar to temporarily replace it? If that's the case, why do that? The action bar is supposed to be there consistently because it contains the actions that we're meant to have access to at all times. It feels a bit contradictory to me.
Melissa Lim 08:35, 15 November 2010 (CET)
The eleven activities described by Borchers provide a great breakdown of the process framework for the engineering lifecycle model. I agree that the most important step is to know the target group and fit the pattern language to the workflow of the user. Participatory Design is an interesting technique that I am the least familiar with; how does this differ much from Heuristic Evaluation? Both require "domain experts" to evaluate prototypes and discuss after. I enjoyed going through the deck on Android UI Design Patterns; reading about Action Bars and how an app should be organized was really helpful. I'm glad we were given these slides after we began developing so we can relate the heuristics to our specific projects.
Sui Kun Guan 08:52, 15 November 2010 (CET)
In the first reading, I am interested about using patterns in the usability engineering life-cycle. The patterns can be viewed as eleven steps, which is very similar to the design cycle discussed in the class. It follows such pattern: first, understanding the users, creating prototype, evaluate the prototype based on the users' feedback, and redesign the prototype, and so on. Such circle is the design cycle we should focus on when we design an interface.
In the Google slices, I learn that there are some particular steps when designing a android application while holding the general design cycle mentioned above. For example, Quick action is usually needed for an android application. Quick action usually makes the control more straightforward, and it is fast and fun for users.
Jeremy Sasson 09:18, 15 November 2010 (CET)
The Borchers reading presented a very interesting notion- that you could formalize some sort of pattern to allow for communication between user interface designers, developers, and application domain experts. While there does seem to be research that proves this formal process is beneficial to communication, I still believe there could be vast improvements made to improve communication between the various members of an interdisciplinary team. I like the idea of having a DAG to represent the ideas more clearly, but I also believe that there needs to be more visual aids incorporated. I think the Google slides come across quite effectively with respect to this. The visual aids incorporated into the presentation did a nice job of effectively communicating the basics of Android patterns to the average user.
Tiago Bandeira 09:52, 15 November 2010 (CET)
Pattern language is an integral part of creating an efficient interdisciplinary team that functions cohesively and this is a major focus of the first reading. It is absolutely imperative that team members have the required vocabulary to not only express their ideas clearly but be able to think effectively. If in order to describe a concept one must speak at great length and detail about it instead knowing a word that describes it then it stifles their ability to build on top of that concept.
Simplicity vs. clarity was the focus of the Google IO conference. They showed a couple apps that they felt demonstrated this design philosophy. Most notably the new, at the time, twitter app. Although this application did not support landscape layout it did use new “quick bars” that pop up when the user clicks an item and wants to see more options but does not want those options covering up the content he or she wishes to manipulate. This was key to the IO conference: give the users powerful tools but make the common case both fast and straightforward and create clear affordances that improve the usability of the application.
Yue Chang Hu 10:09, 15 November 2010 (CET)
Although I am still confused about what and why "pattern" is important for UI design, I think the author is trying to tell us that pattern is useful in design because it helps the user adapt to use the product with ease and comfort. It also is still pretty good that it talks about eleven activities because it refreshes my memories of the design cycle. The second article(it is rather a powerpoint slide), give the reader some good advice on how to design a interface that is easy for the users to use. For example, it gives suggestions on dashboard, action bars, search bars, quick actions, and companion widgets and other scaling interface. Thus, making interface as simple and as flexible as possible so that users can adapt to it quickly.
Raymond Williams 13:18, 15 November 2010 (CET)
Pattern recognition is so exciting! If you see a three letter word that starts with "t" then you know it's "the" without even looking at the rest. You might not even notice if it says "teh".
In fact:
Aoccdrnig to rscheearch at Cmabrigde Uinervtisy, it deosn't mttaer in waht oredr the ltteers in a wrod are, the olny iprmoatnt tihng is taht the frist and lsat ltteer be at the rghit pclae. The rset can be a toatl mses and you can sitll raed it wouthit a porbelm. Tihs is bcuseae the huamn mnid deos not raed ervey lteter by istlef, but the wrod as a wlohe.
I came across another interesting thing with patterns when I was creating a text analyzer. It would read a scrambled message and de-scramble it based on letter frequencies. The problem is that there are different patterns of letters depending on the context of the message. So you have to be able to switch sets until you find one with the most actual words as a result.
The standard English pattern is: ETAOINSHRDLUCMFWYGPBVKQJXZ
Mark Wei 16:32, 15 November 2010 (CET)
It's always interesting to see what Google originally intended Android apps to look like. It seems like consistency is a big deal with Android apps. The Action Bar, for example, should consistently provide the same functionality at each screen. The app icons should be consistent with texture and even light source (from the top). Also, Google obviously wants people to use UI designs like the Dashboard and the Quick Actions widgets.
Courtney Wang 17:21, 15 November 2010 (CET)
Borchers' article on pattern designing reinforces one of the key things I learned in this class: that design is as much a science as it is an art. The review of Nielsen's engineering cycle for iterative design in this context brought to light some of the foundational structures that make it a great way to design and implement new ideas and products. By even designing a pattern language for an application in development to target the flow of operations and interaction, HCI for that application could be improved dramatically. Google's presentation on specific Android design patterns brings Borchers' article closer to home and is a great resource that I wish we had sooner when we were designing our interface. By explaining the envisioned design patterns, consistency and regulation can be maintained throughout many,if not all, applications. The separation into five distinct patterns with recommendations for each one was very helpful; I plan on going back through my design and seeing how well ours conforms to these patterns
Steven Kisely08:21, 15 November 2010 (PST)
I found the idea that an architect had actually came up with the concept of “pattern languages” and to prove his concept he designed so many different building for different solutions. Essentially he created puzzle pieces developers could use. They could combine different “pieces” together to create a new area that would be better for its inhabitants. I believe this idea applied to different types of development would make for a better environment for inhabitants / users that would be easier to understand.
Samantha Paras 18:55, 15 November 2010 (CET)
The article by Borchers was a good summary of what exactly "design patterns" are and was nice background the Android presentation. I found the examples most helpful though, as some of the explanations before it were a bit confusing. It seems like one would want to use patterns in order to make design more modular -- separating the design into these patterns allows people to easily understand it as well as implement it.
I liked how the Android presentation was very clear and concise. It gave us good examples of common UI Design Patterns. I don't have an Android phone, but all these patterns were very familiar to me through my use of the iPhone and other devices.
Richard Laroue 18:57, 15, November 2010 (CET)
I like Christopher Alexander's definition of design patterns, namely that each pattern describes a problem that occurs over and over again and prescribes a general solution to the problem. Design patterns are often very general, although not as vague as guidelines. This must hold true because design patterns must provide the necessary structure to solve problems. Android's API followed many design patterns that now make it easy for programmers to design consistent applications.
Alexander Wong 19:03, 15 November 2010 (CET)
The first article mentions the communication difficulties faced by team members due to their varying backgrounds and offers pattern languages as the solution. I absolutely agree that a common language is necessary for efficient work and effective collaboration. However, and perhaps it is because I am not fully understanding the reading, the example pattern solution at the end of the reading for Blues is still very technical. Also, although the reading advocates the re-use of design patterns it seems difficult to keep design patterns from becoming proprietary to a single group of project, as slang naturally develops even in English.
Google's choice of materials and colors for their Android icons seems problematic. Besides the fact that slide 35 looks hideous should be a clear indication that more consistency needs to be introduced. The issue is along the lines of what we discussed a few lectures ago with Microsoft's icon choices: hue and texture. The icons laid out on slide 35 have varying brightnesses, different hues and saturation levels, different reflection effects, are overly geometric and then overly bubbly. The icon standards feel like an after thought. After a designer was hired to make the native OS icons, they generalized those designs to create the icon templates. However, throwing away parts of the original icon disturbs the balance of each icon. Generalizing a small portion of an icon, enlarging it and removing it form context is far from creating a template.
Avery Gee 19:21, 15 November 2010 (CET)
The first reading was interesting as it made note of ways to improve UI design by solving smaller problems with solutions you already have. It sort of goes along with the plagiarism idea from earlier in the class where you look at something that already works and then elaborate. It is also useful to have a design pattern language so that you can effectively communicate the design to people who aren't intimately involved with the project.
The second reading which talked about the ways that Google has tried to standardize Android was interesting because in theory it all sounds good and like it would work, but in reality I've found that most of my Android apps are not consistently following their ideas for dashboards, action bars, quick actions, etc.
Albert Tseng 19:34, 15 November 2010 (CET)
The paper on pattern languages presents a more formal method of approaching interactive design and usability engineering. What I found particularly helpful and enlightening is the example given; the musical design pattern section put the concepts into a concrete concepts. As for the Android design patterns, it was greatly helpful to see what the common approaches are to making an Android app, and the article's rules of thumbs are very clear and concise. Those "recommendations" are one of the things I found most helpful about the article.
Karthik Jagadeesh 19:43, 15 November 2010 (CET)
In Borchers article he talks about the Neilsen's usability engineering lifecycle model. Most of the general patterns will somehow fit into each of the eleven steps that are described in the usability engineering lifecycle. The 11 steps are: Know the User, Competitive Analysis, Setting usability goals, Parallel Design, Participatory Design, Coordinated design of the total interface, Apply guidelines and heuristic Analysis, Prototyping, Empirical testing, Iterative design, Collect feedback from field use. I really liked being able to break this down into these 11 steps because it helps to think about this before doing any UI Modeling, and to make sure that we are not forgetting anything.
I also saw the Google Android UI Design Principle talk. I felt that a couple of the UI principles that were talked about in the video were contradictory to the models we had previously learned about. For example, I noticed that they said it is important to fit as much functionality to a page as possible, but what we had learned was to make it simple and something that the user can easily understand without much thought.
Christine Lu 19:44, 15 November 2010 (CET)
The Borchers reading that introduced patterns was a bit confusing at first, as it defined patterns in terms of DAGs and gave meaning to entering and leaving edges. However, the examples the article provided later on served to clear up this confusion. It seemed that, in their examples, patterns were used to explain the design problem, present existing solutions, and evaluate why they were worthwhile. Unfortunately, I wasn't able to see how this would be helpful enough to allow "programmers without Smalltalk experience to successfully design their own Smalltalk UI's."
The second reading from Google was an interesting and very relevant example, but I thought that it was meant to help designers focus their efforts and explain important attributes of various key components of an app rather than to teach them HOW to do something and WHY something is the preferred method of doing a task, as the intro to the first reading implied. I do, however, feel that the 5 examples Google provided were tantamount to creating a useful, universally understood app, which is essentially the goal of using patterns.
James Yu 20:15, 15 November 2010 (CET)
At first reading the formal writing of the definition of the pattern language made it seem like something too academic and not necessarily useful (in other words it didn't persuade me). However, given some examples, it seems like it is an efficient way for UI designers, application developers and domain experts to communicate ideas. I particularly liked the Android slides. They provided good examples of common situations for Android developers and showed how pattern language can more easily specify good design guidelines.
Chris Song 20:36, 15 November 2010 (CET)
I was fascinated to learn that Alexander originally designed the pattern language to let users express their ideas not for designers. Even though, Borchers mentions that it didn’t translate into software designs, I think that it is a great idea that should be pursued more. Of course, one wouldn’t expect the end user to fire up Eclipse and start writing android programs, but there are many ways in which users can “design” their own apps. One of the more popular ways is the collection of usage data. By learning what the user does and how he does it, designers can incorporation those ideas right into the next iteration of the program. If we can somehow get past the privacy issue and integrate this system into apps, the result would be very similar to users “designing” their own program.
Google slides were excellent. By clearly noting dos and don’ts, the slides illustrated very clearly how to correctly design on Android. One concern I had while following the slides was how one can distinguish one’s own application. Having uniform design pattern across all of the programs will increase the ease of use, but it may limit the exposure gained through unique UI design. For example, in project presentations, I was personally more drawn to UIs that didn’t have common Android buttons and rectangular layouts.
Richard Nguyen 20:43, 15 November 2010 (CET)
I liked how the first article tries to standardize the design process. In this class we've encountered different ways to approach design and it's nice to see a slightly more technical summary of these "design patterns." The first half of the article was a bit dry but picked up with the examples which made it much more interesting and helped to solidify the concepts in my mind.
The android presentation was a nice example of more design patterns. The five design patterns were actually a very good set of UI designs that anyone can bring into any app and make work well right off the bat. I look forward to incorporating some of these patterns if not all to our interactive prototype in the future.
Aaron Loessberg-Zahl 20:52, 15 November 2010 (CET)
In the first article, while it is very information-dense and seemingly informative, it does little to concretely define the concept of a "pattern language." While a clear way of communicating between people working on different aspects of a program would certainly feel useful, after reading this work, one comes off with the feeling that the authors don't really know how that would be accomplished either.
The video seems to be about something else altogether, talking about patterns in design, rather than in language. I felt that this was much more informative than the first article, and far more practical. The core concepts of clear v. simple, content-driven interaction, and consistency with engagement are very useful, and can be readily applied to our application design. While cloud integration is also important, it is not as critical (at least to our app). Also, Richard Fulcher tells terrible jokes.
Soroosh Izadian 21:16, 15 November 2010 (CET)
I found the idea of pattern languages in Borchers's article very intriguing. pattern language helps the design process at least in two very important ways: 1.breaks down the problems to smaller components (patterns that often repeat in other problems) and 2. provides a common meaningful presentation (graph) across different fields, so design team members with different expertise can communicate they're ideas more easily. Google IO slides also discuss a similar thing introducing 5 very effective and important user interface design patterns one can/should use in an Android app. By defining standard ui patterns like these that different developers can use the same way on Android apps, google provides a standard interaction procedure for the Android framework. Android users see these patterns in many different apps and get used to them after a while. when they see the familiar patterns in new apps they know what to expect from each pattern.
Edmundo 20:55, 15 November 2010 (CET)
The first article certainly points out the importance of pattern languages in HCI. I especially like the idea of using such a language to include the users in the building of a product. It only makes sense to have a simple and effective way of communicating ideas but this article did well of formalizing how one would go about doing this. I would have liked to see an example of one of Alexander's patterns, this would have helped understand the article a little bit better at the beginning. The google presentation was really interesting in that it stressed very specific points about designing an application. It seems like it would be useful to a lot of groups to go through this presentation and apply it to their design.
Bernard_Wong 21:08, 15 November 2010 (CET)
I think Google provides plenty of guidelines in terms of how to develop using their platform. Like, recently, I found the photoshop template they provided in making icons for applications. How to make the icon clear and simple, like in the document in this lecture. I thing I love about this Google IO doc is the quick action slides, I think that is very critical of a good mobile application, cause you are always on-the-go, quick action give user an efficient way of completing their tasks.
James Butkovic 21:21, 15 November 2010 (CET)
The differing backgrounds of members of a development team creates a linguistic rift. Programmers will describe programs differently that UI designers or business people. The first article defines what this common language should look like. The formal syntax definition was hilarious and cool. The android specific language article was good too. It was pretty informative on the state of android UI, and also how to build great apps on android and embed a googley experience.
Terrance Ng 21:29, 15 November 2010 (CET)
It seemed like the authors of the first article didn't really know how to define a solid 'pattern language' either.
The Google presentation was interesting. The philosophy is similar, yet different, from Apple's application design philosophy, in that there should be a unified experience, but the way that Google is going to 'enforce' it is very different.
Bichen Wang 21:31, 15 November 2010 (CET)
Jan Borchers already seems to describe what automatically happens when designing an android application. For example, StoryTime has “books” with “pages” just as real books have real pages. These books have “hotspots” which provide the interactivity along with a “library” and other features. Every term matches with a real-world example, and every term can be thought of as a pattern in which future apps like this could follow. It would seem appropriate (and quite helpful) to have such an assignment to document all these patterns in our apps.
For the Google 2010 IO10 thing, the whole session is pretty much CS160 in one hour for Android. They discuss very basic fundamentals about smart use of Android features. Also, it seems that there is already a lot of code out there that makes the GUI elements for developers; the developers just have to put it all together. It makes making an app pretty much from scratch quite intimidating to match what could be done with just a few buttons and forms.
Sung Ma 21:31, 15 November 2010 (CET)
As I learn and read more about designs and design patterns, I come to a conclusion that designing something is very difficult step in developing a product. There are several reasons to this and one of them is that there isn't any particular answer in designing. Always there is going to be a better design that fits people and also, people change everyday and designs must follow their usage and convenience. It was very nice to see the Google presentation although it was a bit long.
Derrick Tao 21:32, 15 November 2010 (CET)
Pattern design is very interesting concept in human center interfaces. It makes for a better way of communicating ideas to the users rather than solely relying on the specific use of language. Google provided many insightful ways of developing products using their platform. They made it very easy for developers to make icons using photoshop. Overall, the design patterns all help to solve very common problems in the best practical way.
Tsung Han Tsai 21:37, 15 November 2010 (CET)
I like how the first article emphasizes the use of patterns. It gives some pretty good points and tips to follow when designing UI. I've never noticed how much patterns there were in so many different areas that doesn't seem to have anything to do with each other.
Benjamin Carpenter 21:42, 15 November 2010 (CET)
The first paper takes a very technical and theoretical approach to UI design. While I liked that they used design pattern methodology as is used in software engineering, it seems too formal for most everyday UI designers.
It would be great if they could formulate these ideas and give an example of them as commonly used in practice, and put them into a paper book. Many designers and hobbyists alike could benefit from using some of these "design patterns."
Robert Connick 21:39, 15 November 2010 (CET)
The concept of a pattern language was quite interesting and something that I don't think I've seen explicitly before, although I have had similar things recommended to me. It does seem like a lot of documentation work, although it probably compares favorably to training people in many different domains whenever they need to communicate. Sometimes, however, it looks like ambiguity could be a problem, since graphs are directed. "Is 4/4 time a reference of blues time or its context?" and similar situations. The design lifecycle looked like a more detailed (or more consolidated) version of what we're doing - I saw heuristical analysis and user testing in there. The Google Android presentation was also informative and I will be trying to implement its guidelines into Android apps.
Danica Shei 21:49, 15 November 2010 (CET)
The article was a little difficult to understand in the first two pages but eventually the main point was that pattern language is a significant process of creating a team of diverse designers and users to improve a product’s usability. The importance of having a clear pattern is that it provides a common ground and languages for people coming from different areas and expertise. I can see the efficiency of using pattern design because it really allows a user without much technical background to communicate what he/she wants through this process.
The Google talk summarized the points of the reading in much more simpler and practical terms. It focused on the importance of simplicity applications and widgets, emphasizing that consistency and simplicity goes a long way in improving the usability of a product. The patterns that the Google talk included with recommendations can be useful for our project and it would be advantageous to try to see how well ours comply with these patterns.
Alan.choi 21:52, 15 November 2010 (CET)
In Borchers paper, we basically get to see Nilsen's usability lifecycle model in the form of a DAG for the more technical persons and a flowchart/relational diagram for the less technical persons. I think that this is actually quite a good compromise because it keeps both sides on their feet and able to keep each other in the loop. For example, we basically start off general and not so technical to lay out the general goals and actions we want. And then deep in the graph, we get into the more techncial details still at a higher level, so everyone knows what's going on. Breaking down each part into its Context, Problem, Solution, Examples, and References keeps everyone on the same page for all aspects, so its greatly enhances communication.
In the Google presentation, I found it quite interesting how they view the android and its crucial components, and thus the crucial components for an app as it will be able to interact with these base components and use them to their own advantages and functionality. I like how they are trying to unify the looks of apps to a tried and true format because overall, the experience would look a whole lot smoother if everthing were able to conform to the same format so that we would only have to learn about the intricacies of an app once and apply it to everything else.
Simran Chaudhry 21:59, 15 November 2010 (CET)
In the first article, I enjoyed reading about how UI design patterns fit into every part of the usability lifecycle--you realize that these design patterns are something you need to keep in mind throughout the entire process, not just when you sit down to code.
In the second, I found it very useful that they included an example of each of the design patterns (e.g. Dashboard = What can I do with this app? What’s new?, and ActionBar = How can do I x quickly?) -- they were able to assign functions/an explicit purpose to the UI screens that we kind of take for granted.
Karl He 22:13, 15 November 2010 (CET)
The google presentation was especially interesting. I've always been a little disappointed by the Android default styling compared to the iPhone's styling, but the presentation does a good job in justifying why it is so. In addition, they introduce a bunch of conventions such as the action bar, dashboard, and icon templates, that if followed will provide Android applications with uniformity and usability without letting go of the customizability already present.
The other reading brings in a similar, more general point. Patterns provide uniformity in user understanding that allow people to understand what is happening much more quickly.
