Ease of Use

fencinghuddleAI and Robotics

Nov 14, 2013 (3 years and 4 months ago)

76 views

Ease of Use


Fun, Function and Freedom



CS 552


Software Project and Practicum

Architecture Checklist


Metrics


4+1 Views


Performance


Trustworthiness


Safe


Reliable


Secure


Operations and Administration


Error Recovery


Ease of Use

Poor Human Design

Ease of Use design objectives for HCI, Manuals

Forms, Printouts, Error Messages

Design Objective

Technique

1. Be consistent

Identical terminology, similar screen layout uniform
escape routes, low response time variance

2. Provide shortcuts

Direct menu access & function keys

3. Provide feedback

Dashboards & warnings

4. Design tasks for
completion.

Modularity

5. Fix errors efficiently

Polite and comprehensive message, suggest changes

6. Easy action reversal

ERASE commands, escape menus, update options

7. Local control

Avoid frequent warnings & patronizing messages

8. Reduce short
-
term
memory load

Simple displays, minimal use of windows, mnemonic
coding, blank space, no clutter

9. Use surprise effectively

Minimal highlighting, minimal input verification,
avoid flashing and auditory messages

10. Keep user located

Menu labels, graphic directories in help function,
restrict menus to three levels




Asimov’s Laws of Robotics


0. A robot may not injure humanity or, through inaction,
allow humanity to come to harm.

1. A robot may not injure a human being or, through inaction,
allow a human being to come to harm, except where that
would conflict with the Zeroth Law.

2. A robot must obey orders given it by human beings except
where such orders would conflict with the First Law.

3. A robot must protect its own existence as long as such
protection does not conflict with the First or Second Law.

Good user interfaces:




Improve end user productivity


Require data entry only once/item


Reduce training time


Reduce errors


Enhance end user acceptance


“Don’t try to correct poor software design with
good documentation.” Yuhas

Ease of use checklist


Simple and natural dialog


Speak the end user’s language


Minimize human memory load


Consistent


Provide feedback


Provide clearly
-
marked exits


Provide shortcuts


Provide helpful error messages

Northern Telecom

NEC

AT&T

ROLM

Overall Satisfaction

1

2

3

4

Most Frequently Recommended System


1

3

4

2

Training

1

4

3

2

Documentation

1

4

2

3

Attendant Operation

1

4

3

2

Installation / Cutover

1

2

3

4

System Management

1

2

4

3

User Operation


1


3

3

2

Hardware Reliability

1

3

3

4

Maintenance / Service

2

3

1

4

Troubleshooting

1

2

3

3

Systems Performed as Expected

1

4

3

4

DATAPRO PBX USER SATISFACTION


Case STUDY

As of 13Jan09 Northern Telecom went bankrupt

Human factors in interface design


Limited short
-
term memory


People can instantaneously remember about 7 items of information. If
you present more than this, they are more liable to make mistakes.


People make mistakes


When people make mistakes and systems go wrong, inappropriate
alarms and messages can increase stress and hence the likelihood of
more mistakes.


People are different


People have a wide range of physical capabilities. Designers should not
just design for their own capabilities.


People have different interaction preferences


Some like pictures, some like text.

Thanks to Ian Sommerville 2004 Software Engineering, 7th edition for this slide.

Design concepts


Bend to familiarity

The interface should be based on user
-
oriented terms and concepts
rather than computer concepts. For example, an office system
should use concepts such as letters, documents, folders etc.
rather than directories, file identifiers, etc.


Be Consistent

The interfaces must be consistent from screen to screen.. Commands
and menus should be at the same place and have the same
format,, etc.


No surprises


A user should be able to infer the use of a command from similar
ones.

Even more design concepts


Recoverability

The system should contain the effects of user errors and allow
recovery with minimal effort. This might include an undo
facility, confirmation of destructive actions, 'soft' deletes, etc.


User guidance

Some user guidance such as help systems, on
-
line manuals, etc.
should be supplied. The design should strive for a ‘zero
-
training’ ideal.


User diversity

Interaction facilities for different types of user should be supported.
For example, both command lines and menus should be
supported.


Interaction styles

I
nt
erac
ti
o
n
s
t
y
l
e
Ma
in
a
d
va
nt
ages
Ma
in

dis
adva
nt
ages
A
ppli
cat
i
o
n
exa
mpl
es
D
ir
ec
t
m
an
i
pu
l
a
ti
on
F
as
t
and

in
t
u
iti
ve
i
n
t
e
r
ac
ti
on
E
asy
t
o
l
ea
r
n
M
a
y

be

ha
r
d
t
o

i
m
p
l
e
me
nt
.
On
l
y

su
it
ab
l
e

wher
e

t
he
r
e

i
s a
v
i
su
a
l
m
e
t
apho
r

f
o
r

t
a
s
ks and
ob
j
ec
ts
.
V
i
deo

ga
m
es
CA
D

s
ys
t
e
m
s
M
e
nu
s
el
ec
ti
on
Avo
i
ds

us
e
r e
r
ro
r
L
i
ttl
e
t
yp
i
ng
r
equ
i
r
e
d
Sl
ow
f
o
r
expe
ri
enc
e
d

u
s
er
s
.
C
a
n

beco
me
co
m
p
l
ex
i
f
m
any
m
enu

opt
i
on
s
.
Mo
st
g
e
ner
a
l
-
pu
r
pose

sy
st
e
m
s
F
or
m f
i
ll-i
n
Sim
pl
e
da
t
a

en
tr
y
E
asy
t
o
l
ea
r
n
Ch
e
ckab
l
e
T
akes

up
a

l
o
t
o
f
sc
r
een

spa
c
e.
C
a
use
s
p
r
ob
l
e
m
s

whe
r
e u
s
e
r
op
ti
ons

do no
t m
a
t
ch
t
he
f
or
m
fi
e
l
ds
.
St
ock
c
ont
r
o
l,
P
e
r
sona
l l
oan
p
r
oces
si
ng
Co
mm
and
l
anguage
P
owe
r
fu
l
and
fl
ex
i
b
l
e
Ha
r
d
t
o
l
ea
r
n.
P
oor

e
r
ro
r
m
a
nage
m
en
t.
Ope
r
a
ti
ng
s
ys
t
e
ms
,
Co
mm
and

and
con
tr
o
l

s
ys
t
e
m
s
Na
t
u
r
a
l
l
anguage
Acc
e
s
s
ib
le

t
o
c
asu
a
l
us
e
r
s
E
as
il
y
e
x
t
ended
R
e
qui
r
e
s

m
o
r
e
t
yp
i
ng
.
Na
t
u
r
a
l

la
nguage und
e
r
st
and
i
ng
sy
st
e
m
s

a
r
e un
r
e
li
ab
l
e
.
I
nfo
rm
a
ti
on
r
e
t
r
i
ev
al

s
ys
t
e
m
s
© Thanks to Ian Sommerville 2004 Software Engineering, 7th edition for this slide.


Information presentation

© Thanks to Ian Sommerville 2004 Software Engineering, 7th edition for this slide.


Screen Layout

Displa

y

Application Network Presentation

Data

Information presentation


Static information


Initialised at the beginning of a session. It does not change
during the session.



Dynamic information


Changes during a session and the changes must be
communicated to the end user.


Web sessions are one transaction with
persistence remembered in a cookie.

Error messages reflect your design


Messages must be polite, concise, consistent,
complete, constructive. and helpful,


Error codes are ok iff they are coupled with a text
message telling the user how to correct the error.


Avoid cryptic error messages.

Analysis techniques


Task analysis


Models the steps involved in completing a task.


Model frequency and sequences of tasks


Interviewing and questionnaires


Asks the users and their bosses about the work they do.


Ethnography


Observes the user at work


Model the system.


Extend the life of the prototype to system delivery


Calibrate the prototype with data from the actual system


Measure system performance under projected loads and
enhancements

The HCI design process


User analysis: Create the use cases


Prototyping: Develop a series of HCI prototypes


Interface evaluation: Experiment with these
prototypes with naïve users. Measure learning
time, error rates, satisfaction…


Create encapsulation software object classes to
separate screen layout details from data structure
details.


Feedback the analysis of the experiments to the
use cases that then influence the design


© Thanks to Ian Sommerville 2004 Software Engineering, 7th edition for this slide.



Humanistic Systems



“A computer shall not harm your work or, through inaction,
allow your work to come to harm” Vesonder

An interface is humane if it is responsive to human needs and
considerate of human frailties


Boot up
-

that the user should not be kept waiting
unnecessarily is an obvious and humane design
principle


Users should set the pace of interaction


Feedback status a la dashboards

A computer should not waste your time or require you to do
more work than is strictly necessary


Never require data to be keyed twice

Color use guidelines


Limit the number of colors used and limit their
use.


Use color change to show a change in system
status.


Use color coding to support the task that users are
trying to perform.


Be careful about color pairings.

Design factors in message wording

F
a
ct
o
r
D
e
s
cr
i
p
t
i
on
C
o
n
t
ex
t
W
he
r
e
v
e
r

p
oss
i
b
le,

t
h
e

m
e
ss
a
g
e
s

g
en
e
ra
t
e
d

b
y

t
h
e

sys
te
m

sh
o
u
l
d

r
e
f
lec
t

t
h
e

c
u
r
r
e
nt
u
s
e
r

co
n
te
x
t.

A
s

fa
r

a
s

i
s

p
o
ssi
bl
e
,
t
he

s
ys
t
e
m

s
h
o
u
l
d
b
e

a
w
a
r
e

o
f

w
h
at

t
h
e
u
s
e
r

i
s

d
o
i
n
g
a
n
d
sh
o
u
l
d g
ene
r
a
t
e
m
e
ss
a
g
e
s

t
ha
t
a
r
e
r
e
l
eva
n
t

to

t
h
ei
r
c
u
r
r
e
n
t
a
ct
i
vi
t
y
.
E
x
pe
r
ie
n
ce
As
u
s
e
rs

b
ec
om
e

f
a
m
i
l
ia
r

w
it
h

a
s
y
s
t
em

t
h
ey

be
c
o
m
e

i
r
r
i
t
at
e
d

b
y

l
o
n
g
,

Ōm
ean
i
n
gf
ul
Õ
m
e
ss
a
g
e
s
.

H
o
w
e
v
e
r
,

b
eg
i
n
n
e
rs

f
i
n
d

i
t

d
i
f
f
i
cu
l
t

t
o

u
n
de
rs
ta
n
d

s
h
o
r
t

t
e
r
s
e

s
ta
t
e
m
en
ts

o
f

a
p
r
o
b
l
e
m
.

Y
o
u

s
h
o
u
l
d

p
r
o
v
i
d
e

b
ot
h

t
y
p
e
s

o
f

me
s
sa
ge

an
d

a
l
lo
w

t
he

u
s
e
r

t
o

c
o
n
t
r
o
l
m
e
ss
a
g
e c
o
n
c
i
s
e
n
e
ss
.
S
k
i
ll

le
v
el
M
ess
age
s

s
h
o
u
l
d

b
e

t
ai
l
o
r
ed

t
o

t
h
e

us
er
Õs

sk
i
l
l
s

a
s

we
l
l

as
t
h
ei
r

e
x
p
e
r
i
en
c
e.

M
e
ss
ag
es
f
o
r

t
h
e

d
i
ff
er
e
n
t

cl
as
s
es

o
f

us
e
r

m
ay

be ex
p
r
ess
ed

in d
i
f
f
e
r
en
t

w
ay
s

de
p
en
d
i
n
g

o
n

t
h
e
t
e
r
mi
n
o
lo
g
y

t
h
at
is f
a
m
i
l
ia
r
t
o t
he
r
e
a
de
r
.
S
t
y
le
M
ess
age
s

s
h
o
u
l
d

b
e

p
o
si
ti
v
e

r
a
t
he
r

t
ha
n

n
e
ga
t
i
v
e.

T
h
e
y

s
h
o
u
l
d

us
e

t
he

act
i
v
e

r
a
t
h
er
t
h
a
n
t
h
e
p
a
ss
i
v
e
mo
de
of
a
d
d
r
e
ss
. T
h
e
y

s
h
o
u
l
d
n
e
v
er

be

i
ns
ul
t
i
n
g
or
t
r
y

t
o
be

f
u
n
n
y
.
C
u
l
t
u
r
e
W
he
r
e
v
e
r

p
oss
i
b
le,

t
h
e

d
e
s
i
g
ne
r

o
f

m
e
ss
ag
e
s

s
h
o
u
l
d

b
e

f
a
m
i
l
ia
r

w
i
t
h

t
h
e

cu
l
t
u
r
e

o
f

t
he
c
o
u
n
t
r
y

wh
er
e

t
h
e

sys
te
m

is

s
o
l
d
.

Th
e
re

a
r
e

d
is
t
i
nc
t

c
u
lt
ur
al

d
i
ff
er
e
nc
es

be
t
w
e
en
E
u
r
o
pe
,

A
s
i
a

a
n
d

A
m
e
r
i
c
a.

A su
it
a
b
l
e

m
e
ss
a
g
e

f
o
r

o
ne

cu
l
t
u
re

m
i
g
ht

be

u
n
acce
p
ta
b
l
e
i
n
a
n
o
t
he
r
.
©

Ian Summerville 2004


Good and bad message design

©

Ian Summerville 2004

Analysis techniques


Task analysis


Model each step involved in completing a task.


Model the sequences and repetition of tasks


Interviewing and questionnaires


Asks the users and their bosses, ‘what do you do?” and ‘who do
you work with?”


Ethnography


Observe the user at work


Model the system.


Extend the life of the prototype to system delivery


Calibrate the prototype with data from the actual system


Measure system performance under projected loads and
enhancements

User analysis


If you don’t understand what the users want to do
with a system, you have no realistic prospect of
designing an effective interface.


User analyses have to be described in terms that
users and other designers can understand.


Scenarios where you describe typical episodes of
use, are one way of describing these analyses.

Interviewing


Design semi
-
structured interviews using open
-
ended questions.


Passive Listening technique


Users will say what they think essential; not just
what you thought of collecting.


Group interviews or focus groups allow users to
clarify their thinking and move form the
subconscious to the conscious..

Ethnography


Involves an external observer watching users at
work and asking them in an unscripted way about
their work.


Valuable because many user tasks are intuitive
and they find these very difficult to describe and
explain.


Also helps understand the role of social and
organisational influences on work.


Check the ‘postems’ on their terminals

Ethnographic example

Air traffic control involves a number of control ‘suites’ where the suites
controlling adjacent sectors of airspace are physically located next to
each other. Flights in a sector are represented by paper strips that are
fitted into wooden racks in an order that reflects their position in the
sector. If there are not enough slots in the rack (i.e. when the airspace
is very busy), controllers spread the strips out on the desk in front of the
rack.

When we were observing controllers, we noticed that controllers
regularly glanced at the strip racks in the adjacent sector. We pointed
this out to them and asked them why they did this. They replied that, if
the adjacent controller has strips on their desk, then this meant that
they would have a lot of flights entering their sector. They therefore tried
to increase the speed of aircraft in the sector to ‘clear space’ for the
incoming aircraft.

©

Ian Summerville 2004

Insights from ethnography


Air Traffic Controllers had to see all flights in a
sector, so scrolling displays where flights
disappeared off the top or bottom of the display
were unacceptable.


The HCI must indicate how many flights were in
adjacent sectors so that controllers can plan their
work.

© Thanks to Ian Sommerville 2004 Software Engineering, 7th edition for this slide.



Perception of elapsed time


Jones,
For Principles of Main Computer Dialog Computer Aided Design
, Vol. 10, No. 3, pg 197, May 1978

Instantaneous

Less than 1/3 sec workstation


Fast


1/3 to 1 second transaction

Pause

1 to 10 seconds www

Wait

More than


10 seconds

HCI importance


End users often judge a system by its

interface rather than its functionality


A poorly designed interface can cause a user to
abuse the system


Match the skills, experience and expectations of
end users.


Unusable interfaces is the shortest path to shelf
-
ware.

Usability attributes

A
t
t
r
i
b
ut
e
D
e
s
cr
i
p
t
i
on
Lea
rn
ab
i
li
t
y
H
o
w

l
o
n
g

d
oe
s

it ta
k
e

a

ne
w

us
er

t
o

be
c
o
m
e

p
r
o
d
uc
t
i
v
e

w
it
h
t
h
e
sys
te
m
?
S
p
e
ed

of
o
p
e
r
at
i
o
n
H
o
w

w
el
l

d
o
e
s

t
he

s
y
s
t
e
m

r
e
s
p
o
ns
e

m
a
t
c
h

t
h
e

us
er
Õs

w
o
rk
p
ra
c
ti
c
e?
R
o
b
us
t
n
e
ss
H
o
w
t
o
le
r
a
n
t
is
t
h
e
sys
te
m

o
f
u
se
r
e
r
r
o
r
?
R
e
co
v
e
r
ab
i
li
t
y
H
o
w
g
o
o
d is
t
h
e
sys
te
m
a
t

r
ec
o
ve
r
i
n
g

f
r
o
m

u
s
e
r
e
rr
o
rs
?
A
da
p
ta
b
i
l
it
y
H
o
w
c
l
o
s
e
l
y
is
t
h
e
sys
te
m t
ie
d t
o a
s
i
n
gl
e m
o
d
el

o
f w
o
r
k
?
©

Ian Summerville 2004

Try to design and build Zero Training Systems

Design target: novice (N) or expert (E)


metric


Objective

Time
-
to
-
learn

Respon
se time

Error
Rate

Efficie
ncy

Reliabil
ity

User

Satisfacti
on


Effectiven
ess

1. Be consistent

N

N&E


N&E




N&E


N&E


N

2. Provide shortcuts

E


E

E

E


E

3. Provide feedback


N


N&E


N&E


N&E

4. Design tasks for
completion.


N

N&E


N&E

5. Fix errors efficiently

N&E


N

6. Easy action reversal


N

N&E

N&E

N&E

N&E

N&E

7. Local control


E


E

E


E

8. Reduce short
-
term
memory load

N

N&E

N&E

N&E

9. Use surprise
effectively

E

N&E

10. Keep user located

N

N&E

N&E

N&E

N&E

N&E

Design target: novice (N) or expert (E)


metric

objective


Time
-
to
-
learn

Response
time

Error Rate

Efficiency

Reliability

User

Satisfaction


Effectiveness

1. Be consistent

N

N&E


N&E




N&E


N&E


N

2. Provide shortcuts

E


E

E

E


E

3. Provide feedback


N


N&E


N&E


N&E

4. Design tasks for
completion.


N

N&E


N&E

5. Fix errors efficiently

N&E


N

6. Easy action reversal


N

N&E

N&E

N&E

N&E

N&E

7. Local control


E


E

E


E

8. Reduce short
-
term
memory load

N

N&E

N&E

N&E

9. Use surprise
effectively

E

N&E

10. Keep user located

N

N&E

N&E

N&E

N&E

N&E