1. CS160 Discussion Section
Design Patterns
April

2. Codifying design knowledge
An effective and flexible design is difficult to get “right” the first time.
Yet experienced designers do make good designs
New designers are usually overwhelmed by all the design options available.
Experienced designers evidently know something inexperienced ones don't

3. (continued)‏
Expert designers usually do not solve every problem from first principles, they reuse solutions that have worked for them in the past.
When they find a good solution, they use it again and again.
Such experience is part of what makes them experts.
Such kind of experiences can be recorded as design patterns

4. Patterns elsewhere
Novelists and playwrights rarely design their plots from scratch.
“Tragically Flawed Hero” (Macbeth, Hamlet, etc)‏
“The Romantic Novel” (countless romance novels)‏
Game players
Chess players, Go players, basketball players all rely on “patterns”

5. Design Methods Hierarchy
Design philosophy
Design principles
Design patterns
Design idioms, specific knowledge and tips

6. Writing Patterns The pattern name The problem The solution
The consequences
Pattern Name
Context
Forces
Problem Statement
Solution
Solution Sketch
Other Patterns to Consider

7. References http://developer.yahoo.com/ypatterns/
tterns/webpatterns2/webpatterns/home.php

8. “Input Error Message” pattern

9. Problem
Users have entered input that could not be validated and they must be prompted to correct the input

10. Context and forces – Use when...
Users have are trying to fill in Form and one or more of the fields is syntactically invalid or missing.
a) the field has not been filled in at all
b) the field contains data in the wrong format.
Users must be made aware of the fact that there is a problem.
Users must receive helpful information that will put them on track again.
It is important to give help information near the problem field itself

11. Solution Sketch
Tell the users that there is a problem and how to solve the problem. Also tell the users where the problem occurred.
The error message that is given needs to tell the users:

12. An error has occurred
Best done by displaying a colored box at the top of the page containing a "important notice"
Notice must say what the problem is and that the users can repair the problem by going to the "problem"-field and changing the input

13. Where the error occurred
Also done by stating the problem fields in the box at the top of the page in combination with a marking at the problem field itself
For example, the form widget can be colored as is done in the example above.

14. How the error can be repaired
Giving repair information next to the problem field.
Marked visually in order to stand out as being "help information"
Usually, such help information tells to users about the correct syntax of the entry field.

15. Other patterns to consider
Although giving good error messages is important, one should always assess if the problem can be prevented!
For example, using “Constraint Input” can sometimes be possible to prevent incorrect input.

16. MVC Pattern
Model: an internal (object-oriented) representation of the information the application is trying to manipulate
View: a visual representation of the model.
A change to the model results corresponding views to be notified so that they visually reflect the changes.
Controller: receives input from the user.
Interpreting user’s interactions with the application, determining what they mean and should be done. The controller communicates with the view to obtain geometric information of model objects.

17. Architecture Considerations
Controller and view are often coupled:
Always occur in pairs and their functionalities are intertwined
The model is always separated from the view for three reasons
A user may be working with multiple models
A user may have more than one view
Software engineering consideration: facilitating the inclusion of additional views to an existing application.

18. Presentation Assignment
Tasks
brief explanation of what the application does for the user.
Users
a demographic description of the expected user population and present the persona you used for your design.
Interaction
Pick an interaction that gives a good flavor of how the interface you designed works
Keep in mind the goal here is to sell the interface
The task should be representative and intuitive.
The interaction should be novel or interesting.
The user’s objective
relating it to the persona, specifically the user's needs and wants, assumed skill level, past experiences.
The steps by which the user accomplishes this objective.
The exact steps that the persona takes to accomplish the task
What you expect the persona to be thinking while doing each action (i.e. imagining the user is thinking out loud).
Do not skip over steps.

19. Presentation Tips You have five minutes to sell your project.
You will need a lot of practice to tune the content and timing.
Try to get at least two dry runs.
It’s hard to talk and demo at the same time.
Designate one person to do all the talking.
Another person operating the demo
Again, practice, practice, practice!

20. Design Review - Critiquer
Start with clarifying questions
Clarify any assumptions
What design is intended to do
What kind of experience it is intended to create
Listen before speaking
Understand before voicing an opinion
Be open to hearing something that challenges your thinking
Actively try to understand what’s being said, and reflect it back to the speaker.

21. Design Review - Critiquer
Lead into explorations of alternatives
Ask questions that surface other choices the designer might not have recognized
Postpone judgments, unless there are obvious gaps between the designers' intent and the design
Point out problematic aspects of UI
Based on what you know about the users, the scenarios involved, or the project goals.

22. Design Review - Critiquer
Avoid statements that refer to absolutes.
Instead, make points referent to the goals of the design.
bad: “This sucks and it’s ugly”
good: “Well, if the goal is to make this feel friendly, black and flaming red doesn’t convey that to me.”
bad: “How could anyone figure that out?”
good: “I think there’s something missing between step 3 and 4. It’s not clear to me what the sequence of operations is. How do you expect people to know where to click?”

23. Design Review - Critiquer
Speak in context of your point of view
Personal opinion, expressing your own preferences
Perception of what your customers need or want

24. Design Review - Presenters
Clearly state the objective of your interface
Be specific about what you want comments on
And ask for specificity in the critiques
Don't take it personally, don't be defensive
Clarify your reasoning