Design Patterns: UIs, Games, Learning

From CS 160 Fall 2008

Jump to: navigation, search

Lecture on Nov 10, 2008

slides

Readings

Discussions

Please post your critiques/commments on the required readings below. To do that, first login by using your user name and password, then click the "edit" tab on the top part of this page (between the "discussion" page and the "history" page), New to wikis? Read the Wiki editing guide. . Hint - Please put a whole line == ~~~~ == (literally) at the beginning of your submitted critique, so the wiki system will index, sign and date your submission automatically.

Contents

James Yeh 21:43, 9 November 2008 (UTC)

Patterns in HCI and game design seem to carry over well from the original concept of patterns in architecture. Despite the dynamic nature of the interaction between users and computers in games, the concept of a pattern as described in the first reading encompasses some of the design principles in games, especially with the user-oriented aspect of many games. For example, in role-playing games, the idea of unlocking more in-game content as the user becomes more powerful is a pattern that has been widely accepted by game designers. I would agree that some aspects of gameplay that might be identified as patterns would probably not be as concrete and well-defined as patterns in architecture; nevertheless, the user interface (screens to navigate through a program/game) usually provides cues for the existence of multiple patterns. This is confirmed and exemplified in the second reading, where the eight patterns that were presented demonstrated the strong potential of organizational structure in interface design. Without patterns such as the two-panel selector or one-window drilldown, I could not imagine how confusing it would be to interact with the countless programs that I encounter ever day. I am not sure if I can see how patterns are “solutions” to problems, but I certainly believe that they provide a structured foundation to ease and familiarize user interface design.

Buda Chiou 01:13, 10 November 2008 (UTC)

The design patterns introduced in "Organizing the Content" are very useful. Each of the patterns responds to the principle of Heuristic Evaluation and seems to be unchallengeable for interface design. However, even though these these patterns can definitely help us build an interface that is acceptable by public, I think the design of interface shouldn't be limited to some patterns. We should still try to find our own way to build an interface that is better than the interface that is built by just following the patterns.

Hao Luo 03:12, 10 November 2008 (UTC)

The first article talks about design patterns in regards to architecture and then tries to ties it to design interface but it's pretty long-winded with some loosely-related technical talk that doesn't serve to teach a whole lot about patterns in design interface. Rather than talk on point the article seems to dance around it and talk about anything but that, quoting numerous people about the relation between patterns in architecture and design interface but talks little about actual design interface patterns. The second article was much more useful and actually discussed many design patterns that are obvious to the examples used, but for a new program/product the designed would do well to examine the design patterns in these examples and then decide which is the best one to apply.

Mike Kendall 04:05, 10 November 2008 (UTC)

The pattern principles presented in these two articles seem to rephrase a lot of the rules that we are already using. By sticking to patterns, we are reaching for recognition rather than recall. Each of these patterns has affordances built into them that the users already know (or, they will learn them and go on to recognize these affordances later).

Stuart Bottom 05:13, 10 November 2008 (UTC)

I found both these readings interesting, especially from the perspectives we've already seen in terms of Don Norman's concepts and integrating ethnographies into UI design (that is, using alternative techniques of allowing the users to participate more and have a say in the design of a product they'll eventually be using). The first one was a bit dry, but had good content that definitely stretched my thinking on the alternative way to view design concepts through patterns. I found it slightly anticlimactic that the reading cut off after presenting all the flaws in current pattern languages and how they failed to meet the standards for a truly "portable" interdisciplinary pattern structure. It would be nice to see the new pattern language the authors proposed, if it is the solution all disciplines should be using in the future.

As far as the second reading, I found it interesting how the authors presented very commonplace UI patterns in a formalized, well-defined way that allows them to be extended to other applications where you wouldn't necessarily think of putting them. For example, the "Canvas Plus Palette" doesn't have to be just used for graphics programs, it can be used for any WYSIWYG editor - it made me realize how pervasive the design pattern is; it just appears in various reincarnations depending on the application's focus.


Wenda Zhao 05:19, 10 November 2008 (UTC)

The reading for organizing the Content from Jenifer Tidwell was helpful. I think it will help me on the designing of UI. I found one-window drilldown is a good fit for our appication because our application is designed to be on the cellphone and it consists of many pages of content for user to navigate through. The advantage of using one-window drilldown is that it keeps the UI simple and clear. And the everybody is familiar with the ipod drilldown menu. So that can also help the users to pick up our UI easily. And other content techniques are also useful.

Saliem Than 05:44, 10 November 2008 (UTC)

I found the article on design patterns to be extremely interesting especially when it came to the discussion of the descriptions and development of design structure patterns leading into the discussion on the emergence of abstractions of design pattern structures with regards to HCI. I found the second article to be useless without the context of the first article (honestly I felt the text to be obfuscated with fluff vocabulary with minimal analysis reminiscent of the content created by online content creators writing articles with little substance. The explanations as to when the design patterns were to be used I felt were circular in that the explanations as to when to use them were almost the same as the introductions as to when they were used.). The second article on UI Patterns is somewhat useful in that it illustrates the design patterns that have come into accepted use. It could do with more analysis and information though. (adding in rankings, smaller pattern examples etc)

Haosi Chen 06:05, 10 November 2008 (UTC)

Both of these readings interesting, especially from the perspectives we've seen in terms of Don Norman's concepts and integrating ethnographies into UI design. The first reading had good content that definitely stretched my thinking on the alternative way to view design concepts through patterns. For the second reading, I found it interesting how the authors presented very commonplace UI patterns in a formalized, well-defined way that allows them to be extended to other applications where you wouldn't necessarily think of putting them. After i read about these two reading, i realized that without patterns such as the two-panel selector or one-window drill down, I could not imagine how confusing it would be to interact with the countless programs that I encounter ever day.

Frank Yang 06:54, 10 November 2008 (UTC)

I found the second reading to be especially interesting. It was really helpful to see different types of UI defined with a name and explicitly labeled as to when each is useful. It was interesting to read about them because I had always sort of taken these different types for granted. For example, the whole idea of two panel selector UIs may be the reason why I prefer e-mail software as opposed to browser based e-mail. E-mail clients that are in a browser typically only provide some sort of one-window drilldown, and the ability to quickly navigate and read emails is stunted without the two panels. However, it wasn't until the reading that I realized that there were names to these implementations. With all of them so simply broken down, improving our UIs for our games should be a lot easier keeping the reasons for each implementation under consideration.

Jordan Berk 07:14, 10 November 2008 (UTC)

I found the second reading by Tidwell to be very interesting and certainly applicable to this class. One thing that I found intriguing is how all of these interface styles seem so standard to us. I've barely considered different layouts for the applicatons I use; rather, I feel like I've just accepted them. The one-window drilldown for the iPod, the two-panel selector for email and so on all just seem like the way it has to be. I don't think I've ever considered that designers sat down and thought about the designs, just because they all seem so logical. That said, the article is interesting for that very reason. Tidwell broke down the common designs into very accessible and easy-to-understand categories that perhaps may not seem obvious to a casual user. Also, coincidentally, the paper itself was very well layed out and made for a great read.

JoshuaKwan 07:20, 10 November 2008 (UTC)

Patterns are great for allowing people to understand the layout of your program (or building, as the case may be) very intuitively, by using paradigms and behaviors that are well understood by anyone with a basic familiarity of graphical computers (or buildings.) Confusing programs often have haphazardly placed buttons, list boxes for no reason, top menus for things more often found in context menus, sliders for things that deserve input boxes - things that don't fit the patterns and are not intuitive by any stretch of the mind anyway.

Perry Lee 07:25, 10 November 2008 (UTC)

Using design patterns in UI makes a lot of sense. I agree with James' sentiments: "Without patterns [...] I could not imagine how confusing it would be to interact with the countless programs that I encounter [every day]". Most users just want things to work -- they don't want to have to take out the manual or refer to the help documentation. Using patterns in your UI enables users to draw upon their past expectations and experiences, thereby easing the learning curve and improving efficiency/productivity. Using patterns also enables you, the designer, to avoid needlessly reinventing the wheel and to draw upon the shared, accumulated knowledge of past designers. The second article especially demonstrates this point: it provides clear examples as to when to use each design pattern and why.

Bing Wang 07:42, 10 November 2008 (UTC)

The two readings are interesting. The first one mainly talks about the theory while the second one provided nice examples. The first one is a little dry. I was not sure what I was reading until the software portion. Like Norman said when he quoted the article, the idea is good but the reading is confusing. Pattern seems important for a UI design. Even though we have not specifically mentioned about patterns in this class; however, many of the concepts that we have went over so far ties closely with patterns. Affordance is definitely one of them. Affordance ties in with patterns as users usually use the pattern to tell them how to use the interface. Pattern can also give user the ability to recognize something that they have done in the past which ties in with the hueristic of recongnition rather than recall portion. It also somewhat ties in with the idea of conceptual model where the pattern can be something that the user already sees in their mind. Lastly, it can also tie in with the idea of user centered design and task analysis & contextual inquiry. The designers can observe the user and see the patterns that they perform to design a better system.

I believe design pattern is quite important because it reduces user frustrations. From a designer's perspective, a widely used pattern also do no have to be as aggresively tested. The designer has the confidence because it has worked in other patterns. I think the example from the second article's useful. It helps me see which patterns are widely used. However, I believe there is a drawback of using existing patterns. It reduces designer's imagination.

Juanpadilla 07:49, 10 November 2008 (UTC)

I kind of felt the two articles were contradictory. The first one talked about how HCI was lacking in discipline and consistency in design patterns while the second one seemed to give examples of well thought out and consistent design patterns. I do understand however, given the context of a discipline that has been around for thousands of years like architecture, the principles of UI design patterns can seem archaic, comparably; although, given its relatively short life span, Tidwell presents what seem to be consistent design patterns. Furthermore, I think that there are many patterns that have yet to be documented, or at least that I have seen. For example, given the context of this class, I think the heads up display in many games could easily be given as a UI design pattern. It Is standard in many types of games from first person shooter to role playing games, which use a common goal of displaying health, weapons avail, maps, etc. In sum, I think there just hasn’t been enough done to pull together the resources and ideas floating around in the enormous amounts of UIs to actually say that the discipline of design patterns in HCI are in fact incomplete.

Xuexin Zhang 07:55, 10 November 2008 (UTC)

After reading these two articles, I believe that when building the architecture of a Human Computer Interaction, designer should consider the advantages and disadvantages between different design patterns and apply different design patterns according to the purpose of the HCI. For example, we tend to use drilldown pattern for a simple and clear UI for some easy straight forward tasks like mp3 playing. Also, by using patterns, designer could make their HCI more acceptable by users since it appears to be in a modular way that they have seen before.

Alan McCreary 08:34, 10 November 2008 (UTC)

The second reading reminded me a lot of Nielsen's ten usability heuristics. The two-panel selector emphasizes the importance of "recognition over recall," since it gives the user a light memory load; the canvas-plus-palette pattern matches well with the real world; the "alternative views" pattern shows flexibility for the user; and so on. A common theme in these patterns is simplicity - they start as basic as possible to minimize confusion, and only become more complex at the user's will. When it comes to UI design, fancier is not necessarily better.

Vedran Pogacnik 08:40, 10 November 2008 (UTC)

Clearly the organization and design depend on the type of application. For example, the organization of an email tool seems to be the same across a range of different applications, like gmail or outlook. Also, games seem to follow the same menu design pattern with some added functionality, depending on the type of game. It seems to be essential to take into account what the users expect the application to be, what sort of interactions will be most commonly performed, and what information should clearly stand out without prompting the user to look for it. However, although it is important to conform to some patterns that have been accepted, being too strict about it can lead to monotony and lack of innovation.

Karen Tran 08:56, 10 November 2008 (UTC)

The reading begins with a discussion of pattern languages in architecture, and then continues the discussion of the same concept in software engineering, human-computer interaction (HCI), and how city planning, architecture, and interior design can play a role in influencing people's lives and actions. The section about software engineering resonated with me personally because in high school I was first exposed to object oriented programming and how to write "elegant" code. I never realized how useful the design pattern framework in solving problems ranging from designing cafes to programming code. The constituents of a pattern include name, context, problem, solution, examples, diagrams, and cross references. The central theme surrounding pattern languages is active user participation. In other words, inhabitants or users, not architects or designers, are actively involved in the design of their environments. I think that this is a different view on designs comparing to the ones that we have been exposed to previously in the readings in that it takes on the perspective of the users of the design instead of the designers themselves in determining the outcome of a design. However, the validity of this argument is well justified by the street café example in which the author discusses how things as simple as the design of the café terrace is substantial enough to affect users and their social interactions among one another.

Kai Lin Huang 09:32, 10 November 2008 (UTC)

As discussed in "Patterns for Effective Interaction Design", One-Window Drilldown could lay a huge memory burden on the user. For certain applications that require full screen of display, a first-person shooting game, for example, users may want either another screen to display the reference contents or to print them out. Otherwise, the user has to memorize all references (such as keyboard shortcuts) or to switch the windows back and forth between contents. Another instance, writing a research paper also requires a lot of references. Average writers will set the reference on one side of the screen and the paper in progress on another side to quickly refer to their resources unless the users have trouble with focusing on the paper with the reference next to it (such as a movie effect research paper).

Another common but important aspect of effective interaction design also draws my attention: alternative view. Imagine a daily routine of someone checking out a webpage: while there are conflict between commercial interest and viewer's interest, such as advertisement all over a webpage with some article on it, it is always more user friendly to provide an alternative view for users to print or read teh main content easier, and without the lost of not displaying commercials as a source of income for the web. I believe the web would have a trend toward customizable alternative views system similar to the ones (Mac Finder or WIndows Explorer) in operating systems.There are some websites have provided customizable alternative views such as eBay.com, which allows users to choose gallery view or the listing view with all kinds of sorting criteria. I believe this option allows more successful

Billy Grissom 09:39, 10 November 2008 (UTC)

I think this talk about patterns is a very important concept that many Ui designers seem to forget about. As designers there's often the urge to create something new and innovative that's fresh, cool and overall something the world's never "seen before". But that's just the catch...something new isn't exactly always the best way to approach a situation. if there's one thing we learned in this class it's that giving the user a good sense of control is key to any user interface's success. As the articles point out, I think it's very important that we have patterns that give a sort of template for designers to follow. This way the user is familiarized and doesn't feel quite so lost when using an application. They'll feel more natural and use to working with the interface. The beauty in creativity is pushing Ui design along those borders but at a pace that users can keep up with. Patterns help keep things in familiar waters and are a great starting point for developers to work with so thy don't start something too radical.

KevinFriedheim 09:59, 10 November 2008 (UTC)

The idea of connecting and documenting the ideas that a) people like/gather around windowed areas in a room/space and b) people get tired and wish to sit -- its interesting to find that by simply connecting these two ideas (a and b), and creating a new idea (place a seating area in/around a windowed area) creates less conflict for people. I guess thats to say, most people don't like to sit and watch the wall. I think this was a perfect image to define the importance of building and using patterns as it applies to HCI.

Alexander also points out the simple patterns in writing consistancy facilitates usability. He mentions the example of using a "therefore' just before a solution statment to indicate that a solution is going to be stated so a user can jump right to it and know what to spot (in this case, the bold-faced "therefore"). For the most part though - the first reading went into great detail as to where Alexander's pattern designs are used in HCI and various other paradigms.

The mac-mail example was a perfect example of using good design patterns for interfaces that can borrow from mac-mail. I think that the author makes many great points (one that popped out to me was that the user can navigatae through emails and email content all on the same screen -- many email clients borrow from this design idea like Outlook Express by Windows).


Jacekmw 10:07, 10 November 2008 (UTC)

The first article is somewhat strange and not that useful as far as I'm concerned. While design patterns are a significant portion of human-computer interaction, I found the wording of the article to be needlessly complex and something of a rehash of previously discussed topics. The concept of cross-discipline readability clearly also extends to good user interface design, specifically the ability to understand the controls and concepts of our serious games without being specifically instructed by the coder.

The second article seemed to me much more interesting, presenting real-life successful and intuitive interfaces and when they may be appropriate for use. I could see such a quick guide as becoming a handy quick-check for the UI designer in a hurry. Notably, the interface of the document itself is very minimalist in the spacing (in fact, it reminds me of a previous reading on spacing and margins of text - this succeeds very well with that) yet populated immediately with images, benefits, drawbacks, etc., for each and every layout. Ultimately, I can see this as a very useful tool for the future. For the present, chunking of tasks as mentioned on page 43 in the wizards section seems to me to be a good way to handle in-game tutorials as well. I appreciated that the examples used were up-to-date as well, drawing from sources as diverse as OSX exploring applications to the popular gmail email interface.

Jimmy Nguyen 10:23, 10 November 2008 (UTC)

I like the part in the first article about the typographical rules. It is something that I have believed coming into the semester (to be simplistic). The concept that some object oriented languages do not go about following some of these rules made me immediately to think about Action Script (3.0). Ever since using this language as part of our project, we have come to realize that the major differences between this and older versions make this a very different language. I would have that that with such a higher level language that is used by many (i.e. web developers, scripters, etc) that the language and syntax would have been much simpler, but the syntax has actually gotten more explicit as opposed to implicit.

Also, looking at the help screen provided in the next article, I recommend that keyboard short cuts (like tab moving) is important as well as tutorial screens that go page by page. A tutorial page full of questions makes it less encouraging to go through the potentially intricate process, as opposed to literally being step by step.

nathanyan 11:09, 10 November 2008 (UTC)

The first Borchers reading was terribly dry - I didn't come out of it with a very clear idea of what "patterns" was, though looking back at it after the second reading, it shows how patterns also apply in non-software fields. I did find it somewhat interesting in the first section where it mentions a conflict between "professional" designers being out of touch with the needs of users, which I suppose highlights the need for the kind of HCI study we do in the software field to determine the actual needs of the users, which has obviously been helpful given how much we've changed our program based on user testing and the heuristic evaluation. The second reading does a much better job at explaining, probably because it provides examples and is actually talking about software. In general, I don't know if I see studying "design patterns" as much more than a study of typical conventions in design. It may be good to adhere to them for consistency's sake, so that users may be able to recognize them and immediately use them based on past experience.

Trinhvo 11:12, 10 November 2008 (UTC)

The first article is kind of boring. The second one is more interesting with nice examples.

Cynthia T. Hsu 11:23, 10 November 2008 (UTC)

I really enjoyed today's reading, although much of it was a review of principles previously presented in class. The "Organizing the Content" reading seemed to be written geared towards a single principle - don't change aspects of user interfaces that users are already familiar with.

I found the "Design Pattern Languages" reading particularly interesting - it seemed to be applying the principles of UI design to non-computer interfaces - I never considered architecture (cities and cafes) to be interfaces, but they are to an extent, and it was interesting to see the parallels. The description of how cafes had different types of seating and different types of drinks to cater to various individuals seemed to suggest that cafes were designed with various personas in mind, each with a different goal.

Witton Chou 12:29, 10 November 2008 (UTC)

There are a lot of UI design elements that we encounter every day. Many of these elements have common features and they often go unnoticed - these elements are unnoticed because their design is either very common and/or work very well so we tend to overlook its characteristics. Tidwell lays out these concepts very well and describes how it works, why it works, and when to use them.

Typically, a good design will tend towards simplicity. Following Web 2.0 concepts, simplicity yields clarity and usability. Tidwell's piece very well reflects the idea of simplicity. Rather than trying to compress a multitude of features in one frame, things like wizards and extras on demand will lead to better usability. While many features are nice, they don't necessarily have to be in the same display and can be fit into a multilevel design to reduce clutter.


Volodymyr Kalish 15:26, 10 November 2008 (UTC)

For successful engineering it is important to follow well tested and proven patterns. That's what one of the readings is all about. When following a pattern, it is less likely that an enginner will make mistakes and the whole process is more predictable (especially how much time a project will take). My experience in software enginnering design patters started with an OOP "singleton design pattern" which ensures that only one instance of an object initializes some variables. And it has proven to be pretty effective. Another example that this reading triggered in my mind is Ruby on Rails, the philosophy of which is "convention over configuration" meaning that it is a better practice to follow some conventions as aides in some Web 2.0 software designs.

Antony Setiawan 16:23, 10 November 2008 (UTC)

Borchers' paper is hard to be read (I had to rotate the pages back and forth). Aside from that, the structure of patterns , to me, somehow similar the design process discussed in the lecture with three parts: intro (name, ranking, picture, context), central part (problem desc, solution, diagram), and closing part (references). I still don't quite understand why software design pattern are useful for communication among software designer but not for users just for environment sake.

In my personal experience, I dislike having a two-panel selector. In real use of two-panel selector, there are a lot of confusions (maybe also because of design implementation). For example, if the user click on one of the subject, the screen below changes and the mail is considered as "read". It is said that having two-panel selector, the user can quickly shift attention between two frames. I believe that that is not the case. Take yahoomail for example. Having a lot of short email in this two-panel format, as we scan through the list of mail and have them each displayed in the bottom panel in a very short time, we ended up iterating the list but have all the mail marked as unread. It seems like there's a duration of time we have to stay still in order for that mail to be marked as read. If that's the case, the statement "switching attention back and forth" is not applicable here.

Geoffrey Lee 17:35, 10 November 2008 (UTC)

I thought it was very interesting when the reading mentioned that in cognitive theory, patterns are a natural way of organizing complex information. I didn't realize it until now, but every time I work with a team to brainstorm or design something, we always end up assigning names or naming conventions to abstract ideas that we're discussing. In effect, we are creating patterns on-the-fly that we can later reference and document. And speaking of documentation, the best kind of documentation will discuss the reasoning or usage-scenario behind functions and objects, which is essentially a pattern prescribed for a very specific application.

MuQing Jing 17:53, 10 November 2008 (UTC)

I think the concept of using pattern in design is one of the most underemphasized aspects of a good UI. Clearly, without patterns, it would be incredibly be hard from a user's standpoint to quickly understand how to do a task, even if it seems very intuitive. Patterns allow for the user to put into an environment that they are somewhat familiar and comfortable in; this allows for them to understand how to perform tasks much quicker and efficiently. Patterns that are widely used and known to be fairly successful; there's no reason to think a pattern in use for a while is not tried and true. If anything, even if the pattern does tend to be a little haphazard and messy to work with, the mere fact that people have been exposed to it for so long means that the flatter learning curve more than makes up for the potentially unintuitive design.

Kumar Garapaty 18:06, 10 November 2008 (UTC)

Both articles seem to be very useful for game design, particularly the UI of game design. Patterning is extremely useful in game design as in all designs because it introduces familiarity to the user and allows the user to perform better with that UI as well as favor it more than others that don't use any patterning techniques.

Anthony Kilman 18:14, 10 November 2008 (UTC)

It seems as if the first article tends to rephrase many of the rules that we are already using. Additionally, this includes the theme of utilizing recognition rather than recall. It is imperative to go by these tested and proven patterns in HCI as a generic framework from which to build on.

One section of the second reading that our group had been chatting about, was the UI providing all the directions for the user to follow in some complicated task. For example, moving through an airport (p 13 of the PDF). If a user of some PDA app is only going to do this occasionally, they could care less about the airport's overall structure. But if this is a pilot who frequently flys out of this airport, and say, he wants to find some office he/she has never been too; the additional guidance is a burden. Our group was trying to determine if we needed more confirmation dialogs. I honestly think the number of confirmation dialogs is inversely proportional to the number of users and success of a UI. The more "are you sure" dialogs implies that it wasn't clear the first time.

Paul Im 18:27, 10 November 2008 (UTC)

The article regarding pattern languages seems somewhat useful, in that the users have these design patterns already evolving in their heads. This idea, however, seems somewhat painfully obvious. During our design interviews, our interviewees gave us feedback and input on how they perceived our interface and what improvements we could make (most of their suggestions followed a specific pattern as well). To give it some credit, however, the article did go into much detail on how to actually set up and interpret these design patterns, and how to apply them to programming and HCI.

The article ‘Organizing the Content’ provided very useful tips and strategies in order to make user interfaces more attractive and helpful. There were many applications to our serious games, such as what kind of information to display, how to display the information, etc… These tips seemed like concrete examples of the heuristics in the heuristic evaluations. For example, how to display information would probably fall under ‘Aesthetic and Minimalist Design’. Although the heuristics are usually used to test an interface, it seems like it would be good to know these strategies during the design phase in order to design according to these heuristics.


Shyam Vijayakumar 18:28, 10 November 2008 (UTC)

The structure of patterns defined in the first reading is followed closely by design principles that we have discussed in this class. One difference is that diagramming is a big step in the structure of patterns, where as it wasn't defined as one in the design principles. However, diagramming is a technique that can be used to go about following a certain step in the design principles. For example, one step of the design principles discussed is prototyping. One technnique we have discussed is low fidelity prototype, which essentially is drawing out the entire user interface and testing it. Also, storyboarding is a technique that involves diagramming the user interface under the correct context. The second reading goes into more detail into the prototyping step of our design principles. It gives various patterns that one can follow to organize the content efficiently while prototyping. For examples, these patterns can be used when initially coming up with the low-fidelity prototype.

Yuta Morimoto 18:28, 10 November 2008 (UTC)

In general, it is useful to make general reusable solution to commonly occurring problems. First reading mentions various reusable solutions on historical and classical aspects. Second reading also shows us various salient design patterns in software engineering. Both of them remind me of object oriented design on computer science. We can make use of many programming libraries to support our coding without consuming time. I did not notice that such programming techniques are applicable for UI design. Actually, most UI designs are taking advantage of ancestor's properties. However, UI designs are sometimes very specific for their products so that we may not inherit them.

Kevin Lam 18:29, 10 November 2008 (UTC)

As mentioned before, the first article attempts to parallel architectural design with software UI's. It's a clever way to describing the different patterns you may come across in HCI, but it is a far stretch. Nonetheless, the patterns that are presented are very intuitive and resonate with some of the concepts we've already covered in class. Some of the things that are presented, such as the one-window drilldown, are trivial today because we have seen them time and time again. Getting a more detailed description of the concepts and development of the idea was enlightening.

Mikeboulos 18:30, 10 November 2008 (UTC)

The pattern principles discussed in these two articles go hand in hand with the rules that we have read before and have been applying. For example, recognition rather than recall is the back bone of design patterns. The second reading was more interesting, I never knew that all of these different types of user interface had a special name, For example the Alternative view, I have been using for a while and sometimes I prefer one view over the other when I try searching for something I use the table view and when I am looking for programs I use the icon view. These articles were helpful to open our minds in finding how we can use these patterns.

Retrieved from "http://bid.berkeley.edu/cs160-fall08/index.php/Design_Patterns:_UIs%2C_Games%2C_Learning"
Personal tools