User Interface Design
Lecture 9
1
2
Outline
History and motivation
Human limits
Designing user interface
Evaluating user interface
Examples
UML State diagram
© Z. Eichler, B. Bühnová 2
History and Motivation
Lecture 9/Part 1
3© Z. Eichler, B. Bühnová
4
Importance of user interface
Computing systems are no longer the province of
specialist users.
Computer rage => aprox. 70% of computer users used
violence or offensive language against computers.
Apple iPhone story:
 Computer company redefines phone market through one product.
The Three Mile Island Nuclear Power Plant Disaster:
 Situation misinterpretation (coolant pressure)by the power-plant
operators.
 Oversight of emergency light indicator due to ambiguous control
indicators in the power-plant user interface.
© Z. Eichler, B. Bühnová 4
5
US ballot:
presidential elections 2000 in Florida
Ballot misunderstanding suspected to decide the election.
Major recount dispute followed, which delayed the
outcome for more than a month.
© Z. Eichler, B. Bühnová 5
6
Afghanistan ballot
So simple that even illiterate person can vote
© Z. Eichler, B. Bühnová 6
7
Human-computer interaction (HCI)
HCI is the study of how humans interact with computer
systems. It involves both art and science.
Many disciplines contribute to HCI, including human
factors (ergonomics of human limits), computer science,
psychology, ergonomics, engineering, and graphic
design.
User interface design aims at system design with the
focus on the user's experience and interaction.
© Z. Eichler, B. Bühnová 7
8
User-centered design and development
 The main principles of user-centered design:
 The active involvement of users
 An appropriate allocation of function between user and system
 The iteration of design solutions
 Multidisciplinary design teams
 The essential user-centered design activities:
 Understand and specify the context of use
 Specify the user and organizational requirements
 Produce design solutions (prototypes)
 Evaluate designs with users against requirements
© Z. Eichler, B. Bühnová 8
9
Why developers should’t design user
interface
Developers usually focus more on internal product
quality than on system usability
Developers use different mental model than users:
• User’s mental model is based on metaphors and previous
experience with similar applications
• Developer’s mental model is based on the knowledge of
internal system architecture
User interfaces don't have to conform with domain model
© Z. Eichler, B. Bühnová 9
10
EXAMPLE
Consider a tablet without hardware brightness-control
buttons
Engineers placed software brightness control to POWER
MANAGEMENT section. From their point of view it is the
right place since brightness influences battery life.
From user point of view, a more proper place for such
setting is DISPLAY.
© Z. Eichler, B. Bühnová 10
11
Terms
WIMP paradigm (1973): Windows, Icons, Menus and
Pointing device.
Usability: efficient, easy to learn and satisfying to use
user interface.
User Experience: feel about using a software.
Look & Feel: induces user experience and product
identification. Look can be imitated easily (colors and
shapes), but feel (dynamic behavior) cannot.
Human Interface Guidelines: set of platform specific
recommendations provided to developers, thus users can
carry skill at a standardized interface from one application
to another.
© Z. Eichler, B. Bühnová 11
Human Limits
Lecture 9/Part 2
12© Z. Eichler, B. Bühnová
13
Laws of human limits
Fitts’law (1954)
Model of human movement, predicts the time required to
hit a target:
 physically with a hand or finger,
 virtually with a pointing device.
Given by the distance, width of the target and other
coefficients.
Hick's law (1953)
Predicts the time required to select one item from a list.
Given by the reaction time and entropy of the choices.
© Z. Eichler, B. Bühnová 13
14
Memory
Short-term memory: 7+2 elements
Important for example for proper amount of items in the
menu.
Long-term memory
© Z. Eichler, B. Bühnová 14
Designing Good User Interface
Lecture 9/Part 3
15© Z. Eichler, B. Bühnová
Rules
Consistence: similar objects should behave similarly,
important factor for predictability
Always provide proper feedback to user:
 Weak feedback: user may perceive, e.g. tool tip
 Strong feedback: user must perceive, e.g. dialog box
Prevention and toleration of users mistakes
16© Z. Eichler, B. Bühnová
Fundamental UI design principles (by Apple)
 Metaphors
 Take advantage of people’s knowledge of the world by using
metaphors to convey concepts and features of your app.
 E.g. folders to organize documents
 Mental model
 The user already has a mental model that describes the task
your software is enabling. Respect user expectations and strive
for familiarity, simplicity, availability and discoverability.
 E.g. the process of sending a letter
 Explicit and implied actions
 Explicit actions clearly state the result of manipulating an object.
 Implied actions depend on cues and contexts (drag and drop).
 Keep these two paradigms in mind as you design your UI.© Apple Inc. 17
Fundamental UI design principles (by Apple)
 Direct manipulation
 Allows users to feel that they are controlling the objects
represented by the computer.
 E.g. drag and drop
 See and point
 Based on the noun-then-verb paradigm, where the noun (icon) is
selected first and then the possible verb list (action menu)
browsed.
 User control
 It should always be the user who controls the situation.
 Feedback and communication
© Apple Inc. 18
Fundamental UI design principles (by Apple)
 Consistency
 Visual and behavioral UI consistency with the product itself, with
the platform, previous product versions, user expectations.
 WYSIWYG
 Forgiveness
 Perceived stability
 The user always feels better in a stable and familiar
environment, where e.g. icons do not disappear when inactive.
 Aesthetic integrity
 Your product should look pleasant on the screen, even when
viewed for a long time.
© Apple Inc. 19
20
Prominent positions on screen
Position is
preferred over
graphical
highlight.
Observed by
EyeTracker
device.
© Z. Eichler, B. Bühnová 20
21
Cross-platform GUI
Do not use (different platform metaphors and Look&Feel)
Works everywhere => ugly and less usable everywhere
 It is like designing a house without knowledge where the house
will be located (city, village, mountains).
May adapt Look to particular platform, but Look itself is
not Look&Feel
© Z. Eichler, B. Bühnová 21
22
Point and click vs. touch
Different paradigms, should not be combined.
Touch supports different model of:
 Cursors – not only input but also output indicator, e.g. busy
cursor
 Mouse over indication
Touch interface should support more direct manipulation
and especially the undo operation, to be safe against
user inaccuracy.
Touch is not suitable for difficult conditions, like
turbulence in aircraft.
© Z. Eichler, B. Bühnová 22
23
Always follow Human-Interface Guidelines
(HIG) if available
HIG describe especially proper use of components, e.g.
distances between buttons, labels.
Look inside Windows and/or Mac OS X HIG is
recommended.
Linux user interface guidelines are not competitive to
above mentioned ones, thus such applications don’t
provide such a standardized user interface interface and
Look&Feel.
© Z. Eichler, B. Bühnová 23
24
WEB
No strict HIG.
Designed for content consuming instead of creating.
Do not try to imitate desktop applications.
Support browser integrated navigation controls: Next and
Previous page.
Native HTML (HTML5) with CSS is always preferred over
non standardized ones like Adobe Flash and Microsoft
Silverlight.
© Z. Eichler, B. Bühnová 24
25
Prototyping
Always make a prototype
first.
We distinguish between:
 Wireframes – initial sketches
 Mockups – models of a
design used for
demonstration or evaluation
 Prototypes – early (partlyworking)
samples of the
software
© Z. Eichler, B. Bühnová 25
Evaluating User Interface
Lecture 9/Part 4
26© Z. Eichler, B. Bühnová
27
Evaluation techniques
Interviews (unstructured, semi-structured, structured)
and user observation – easy, very useful for beginners.
Usability Testing (qualitative and quantitative measures):
Quantitative – time to complete task, error rates
Qualitative – questionnaires and surveys, subjective
Field Studies – Complex studies used whenever UI is
very critical, time consuming, considers many factors.
© Z. Eichler, B. Bühnová 27
28
Direct user observation
Underrated technique
Useful for beginners in HCI
Can be combined with
qualitative and quantitative
measures
User’s screen and face can
be recorder
Useful for task simulations,
may be supplied with e.g.
simulated helpdesk
© Z. Eichler, B. Bühnová 28
29
Eye Tracker
Measures the point
which the subject is
looking at
Output:
Heat map
Video of a focus point
on the interface
Useful for marketing
© Z. Eichler, B. Bühnová 29
Examples
Lecture 9/Part 5
30© Z. Eichler, B. Bühnová
31
Who controls the situation?
"Restart Later" option has been disabled, but is still
visible, just to taunt you.
© Z. Eichler, B. Bühnová 31
32
Apple: Ejecting disk through trash can
What happens when you drag the
disk into the trash can?
Erase the whole disk or eject?
Can user be sure without
experiment? => Learning through
exploration
Apple later changed the concept.
© Z. Eichler, B. Bühnová 32
33
Error messages
Does it explain anything to the user?
Errors are never “OK”, use “Continue” or “Exit” instead.
Always provide feedback in order to help the user with
the situation.
© Z. Eichler, B. Bühnová 33
34
Bloatware
(creeping featurism, feature war)
© Z. Eichler, B. Bühnová 34
35
IS
Correct usage of control features is fundamental for good
design!
Main defects:
Hyperlink “Zneaktivnit obě volby” should be replaced with
third radio-button meta-option named “NONE”.
Label “seminární skupinu”
© Z. Eichler, B. Bühnová 35
36
Colors
Beware of proper color and symbol use
© Z. Eichler, B. Bühnová 36
37
USB
Have you ever tried to plug
the USB turn the wrong
way? Why?
WhyA and B are better?
© Z. Eichler, B. Bühnová 37
© Clear View Training 2010 v2.6 38
UML State Diagram
Lecture 9/Part 6
© Clear View Training 2010 v2.6 39
State machines
 Some model elements such as classes, use cases and subsystems, can have
interesting dynamic behavior - state machines can be used to model this behaviour
 Every state machine exists in the context of a particular model element that:
 Responds to events dispatched from outside of the element
 Has a clear life history modelled as a progression of states, transitions and events. We’ll
see what these mean in a minute!
 Its current behaviour depends on its past
 A state machine diagram always contains exactly one state machine for one model
element
 There are two types of state machines (see next slide):
 Behavioural state machines - define the behavior of a model element e.g. the behavior of
class instances
 Protocol state machines - Model the protocol of a classifier
• The conditionsunderwhich operations ofthe classifiercan be called
• The ordering and results of operation calls
• Can modelthe protocolof classifiers thathave no behavior(e.g.interfacesand ports)
© Clear View Training 2010 v2.6 40
State machine diagrams
state = off
Off On
Off On
turnOff
 We begin with the light
bulb in the state off
burnOut
light bulb {protocol}
turnOn
© Clear View Training 2010 v2.6 41
Light bulb turnOn
State = off
Off On
Off On
turnOn
turnOff
 We throw the switch to On and
the event turnOn is sent to the
lightbulb
burnOut
Event =
turnOn
light bulb {protocol}
© Clear View Training 2010 v2.6 42
Light bulb On
State = on
Off On
Off On
turnOn
turnOff
 The light bulb turns on
burnOut
light bulb {protocol}
© Clear View Training 2010 v2.6 43
 We turn the switch to Off.
The event turnOff is sent
to the light bulb
Light bulb turnOff
State = on
Off On
Off On
turnOn
turnOff
burnOut
Event =
turnOff
light bulb {protocol}
© Clear View Training 2010 v2.6 44
Light bulb Off
state = off
Off On
Off On
turnOff
burnOut
turnOn
 The light bulb turns off
light bulb {protocol}
© Clear View Training 2010 v2.6 45
Basic state machine syntax
 Every state machine should have a initial state which
indicates the first state of the sequence
 Unless the states cycle endlessly, state machines should
have a final state which terminates the sequence of
transitions
 We’ll look at each element of the state machine in detail in
the next few slides!
A B
anEvent
initial state transition
event
state final state
© Clear View Training 2010 v2.6 46
States
 "A condition or situation during the life of
an object during which it satisfies some
condition, performs some activity or
waits for some event"
 The state of an object at any point in
time is determined by:
 The values of its attributes
 The relationships it has to other objects
 The activities it is performing
Color
red : int
green : int
blue : int
How many states?
© Clear View Training 2010 v2.6 47
State syntax
 Actions are instantaneous
and uninterruptible
 Entry actions occur
immediately on entry to the
state
 Exit actions occur
immediately on leaving the
state
 Internal transitions occur
within the state. They do not
transition to a new state
 Activities take a finite amount
of time and are interruptible
EnteringPassword
entry/display password dialog
exit/validate password
keypress/ echo "*"
help/display help
do/get password
entry and exit
actions
internal
transitions
internal
activity
Action syntax: eventTrigger / action
Activity syntax: do / activity
state name
© Clear View Training 2010 v2.6 48
Transitions
A B
event1,event2 [guard condition]/ act1, act2
behavioralstate machine
C D
[precondition]event1,event2 /[postcondition]
protocolstate machine{protocol}
protocol
state
machine
behavioral
state
machine
events Boolean
guard condition
actions
precondition events postcondition
© Clear View Training 2010 v2.6 49
 The junction pseudo state
can:
 connect transitions
together (merge)
 branch transitions
 Each outgoing transition
must have a mutually
exclusive guard condition
A
B
C
t1
t2
simple merge junction
simple merge example
A
B
C
t1
t2
D
[c1]
[c2]
merge with branch
junction with
merge and branch
Connecting - the junction pseudo state
© Clear View Training 2010 v2.6 50
 The choice pseudo
state directs its single
incoming transition to
one of its outgoing
transitions
 Each outgoing
transition must have a
mutually exclusive
guard condition
Unpaid
FullyPaid PartiallyPaidOverPaid
[payment = balance]
[payment > balance] [payment < balance]
acceptPayment
acceptPayment
makeRefund
BankLoan
choice pseudo-state
Branching – the choice pseudo state
© Clear View Training 2010 v2.6 51
Events
 "The specification of a noteworthy
occurrence that has location in time and
space"
 Events trigger transitions in state machines
 Events can be shown externally, on
transitions, or internally within states
(internal transitions)
 There are four types of event:
 Call event
 Signal event
 Change event
 Time event
Off
On
turnOff turnOn
event
© Clear View Training 2010 v2.6 52
close()
Call event
 A call for an operation
execution
 The event should
have the same
signature as an
operation of the
context class
 A sequence of
actions may be
specified for a call
event - they may use
attributes and
operations of the
context class
 The return value
must match the
return type of the
operation
InCredit
deposit(m)/ balance = balance + m
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
internalcallevent action
condition
externalcallevent
entry action
SimpleBankAccount
© Clear View Training 2010 v2.6 53
close()
Signal events
 A signal is a
package of
information that is
sent
asynchronously
between objects
 the attributes
carry the
information
 no operations
InCredit
deposit(m)/ balance = balance + m
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
SimpleBankAccount
OverdrawnAccount
send a signal
«signal»
OverdrawnAccount
date : Date
accountNumber: long
amountOverdrawn:double
© Clear View Training 2010 v2.6 54
Receiving a signal
 You may show a signal
receipt on a transition
using a concave
pentagon or as an
internal transition state
using standard notation
Calling borrowerOverdrawnAccount
signal receipt
SignalName : someAction
Some state
© Clear View Training 2010 v2.6 55
close()
Change events
 The action is
performed when the
Boolean expression
transitions from false
to true
 The event is edge
triggered on a false
to true transition
 The values in the
Boolean
expression must
be constants,
globals or
attributes of the
context class
 A change event
implies continually
testing the condition
whilst in the state
InCredit
deposit(m)/ balance = balance + m
balance >= 5000 / notifyManager()
AcceptingWithdrawal
entry/ balance = balance - m
RejectingWithdrawal
entry/ logRejectedWithdrawal()
withdraw(m)
[balance < m]
withdraw(m)
[balance >= m]
SimpleBankAccount
OverdrawnAccount
Boolean
expression
© Clear View Training 2010 v2.6 56
Time events
 Time events occur when a
time expression becomes
true
 There are two keywords,
after and when
 Elapsed time:
 after( 3 months )
 Absolute time:
 when( date =20/3/2000)
Overdrawn
balance < overdraftLimit / notifyManager
Frozen
after( 3 months )
Context: CreditAccount class
© Clear View Training 2010 v2.6 57
Composite states
 Have one or more regions that
each contain a nested
submachine
 Simple composite state
• exactly one region
 Orthogonal composite state
• two or more regions
 The final state terminates its
enclosing region – all other
regions continue to execute
 The terminate pseudo-state
terminates the whole state
machine
A composite state
A B
C
region 1
region 2
submachines
Anothercomposite state
D E
F
terminate
pseudo-state
© Clear View Training 2010 v2.6 58
[dialtone]
after(20 seconds)/noDialtone after(20 seconds)/noCarrier [carrier]
cancel
Simple composite states
 Contains a
single
region
 The nested
states
inherit the
cancel
transition
from
DialingISP
do/dialISP
DialingISP
entry/ offHook
WaitingForDialtone
Dialing
WaitingForCarrier
entry
pseudo
state
notConnected
dial
connectedexitpseudo-state
NotConnected Connected
entry/onHook exit/onHook
do/useConnection
ISPDialer
© Clear View Training 2010 v2.6 59
Orthogonal composite states
 Has two or more regions
 When we enter the superstate, both submachines start
executing concurrently - this is an implicit fork
do/ initializeSecuritySensor
Initializing
InitializingFireSensors
do/ initializeFireSensor
InitializingSecuritySensors
Initializing composite state details
do/ monitorSecuritySensor
Monitoring
MonitoringFireSensors
do/ monitorFireSensor
MonitoringSecuritySensors
fire
intruder
Monitoring composite state details
Synchronized exit - exit the superstate when both
regions have terminated
Unsynchronized exit - exit the superstate when either
region terminates. The other region continues
© Clear View Training 2010 v2.6 60
Key points
 Behavioral state machines
 Protocol state machines
 States
 Actions, exit and entry actions, activities
 Transitions
 Guard conditions, actions
 Events
 Call, signal, change and time
 Composite states
 Simple and orthogonal composite states