CS160 Discussion Section
Design Patterns
April 16 2007
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
(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
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”
Design Methods Hierarchy

Design philosophy

Design principles

Design patterns

Design idioms, specific knowledge and tips
Writing Patterns

The pattern name
1.Pattern Name

The problem
2.Context

The solution
3.Forces

The consequences
4.Problem Statement
5.Solution

Solution Sketch
6.Other Patterns to
Consider
References

http://developer.yahoo.com/ypatterns/

http://www.welie.com/patterns/index.html\
http://harbinger.sims.berkeley.edu/ui_designpa
tterns/webpatterns2/webpatterns/home.php

“Input Error Message” pattern
Problem

Users have entered input that could not be
validated and they must be prompted to
correct the input
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
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:
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
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.
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.
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.
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.
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.
Presentation Assignment

Tasks


Users


brief explanation of what the application does for the user.
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.
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!
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.
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.
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?”
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
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