This talk from the 2012 UX Barcamp Vienna was intended as a campaign against "slow" (laggy, jerky, freezy etc.) user interfaces. I make an argument for the importance of UI performance, possible reasons for its commonly being ignored, and steps that designers and programmers should take to avoid these issues.
2024: Domino Containers - The Next Step. News from the Domino Container commu...
Designing and implementing responsive, fluid UIs to delight end users
1. Designing
and
implemen-ng
responsive,
fluid
UIs
to
delight
end
users
best
and
worst
prac.ces
for
interac.on
designers
and
programmers
Michael
Klein
Interac.on
designer,
developer
and
UI
connoisseur
at
CURE
(Center
for
Usability
Research
and
Engineering),
Vienna
hCp://gplus.to/michaelklein27,
hCp://www.linkedin.com/in/michaelklein3,
@mischkl
2. Designing
and
implemen-ng
responsive,
fluid
UIs
to
delight
end
users
best
and
worst
prac.ces
for
interac.on
designers
and
programmers
What
am
I
talking
about?
3. What
am
I
talking
about?
Let’s
take
a
look
at
some
examples
hCp://www.youtube.com/watch?v=HyA6UXi0v6g
10. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
a
user’s
perspec-ve)
• “HCI
impedance
mismatch”
(my
phrase)
–
user’s
ac.ons
are
too
fast
for
the
system,
system’s
responses
are
too
slow
for
the
user
• Without
immediate
feedback,
user
error
is
introduced—they
click
buCons
mul.ple
.mes,
try
to
swipe
mul.ple
.mes,
try
to
close
unresponsive
apps
even
if
they
are
not
actually
frozen,
poten.ally
leading
to
data
loss,
etc.
• When
things
don’t
work
smoothly,
users
are
reminded
that
they
are
“using
a
computer”,
sense
of
magic/fun
decreases,
sense
of
control
decreases,
frustra.on
increases
• Unresponsive
apps
violate
4
of
Nielsen’s
10
usability
heuris-cs
(Visibility
of
system
status,
match
with
real
world
(real
objects
don’t
stuCer/freeze),
user
control/freedom,
error
preven.on.)
11. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
an
interac-on
designer’s
perspec-ve)
• Difficult
to
portray
.me-‐sensi.ve
interac.ons
in
sta-c
mockups,
or
even
in
higher-‐level
prototypes
• Time-‐based
performance
characteris.cs
are
invisible
and
unpredictable,
which
makes
it
hard
to
iden.fy
them
as
“features”
or
“defects”
• UI
performance
considera.ons
are
largely
qualita-ve
in
nature
–
the
answer
to
the
ques.on
of
“what’s
good
enough?”
varies
widely
• Because
of
their
invisible
and
qualita.ve
nature,
UI
performance
characteris.cs
tend
to
rate
low
on
the
list
of
managers’
and
programmers’
priori.es
12. TIME
(aka
a
temporal
sequence
of
events)
What’s
so
special
about
it?
(from
a
soPware
developer’s
perspec-ve)
• Notoriously
difficult
to
handle
npredictable
.me
values
in
code
–
u
event/callback-‐driven
asynchronous
programming
is
easy
to
screw
up
(or
is
avoided
due
to
fear
of
complexity,
lack
of
understanding)
• Race
condi.ons
• Error
handling
issues
• “Feedback
loops”
• Execu.ng
on
UI
thread
• Asynchronous
APIs
are
harder
to
understand
and
debug
• Difficult
to
pin
down
sources
of
performance
issues
• UI
toolkit
weaknesses
(e.g.
Flash,
HTML5)
• Difficult
to
judge
real-‐world
performance
characteris.cs
because
developers’
machines
tend
to
be
high-‐spec’d
13. So
what
can
we
do
about
it?
1. Acknowledge
that
UI
performance
characteris.cs
are
a
key
component
of
user
experience.
Designers
can’t
be
sa.sfied
with
sta.c
mockups
alone.
Developers
can’t
be
sa.sfied
with
simply
“looking
like”
a
design.
2. No
“designing
it
and
then
dropping
it
off
at
the
programmers’
feet”.
Designers
need
to
work
closely
with
developers
and
test
itera-ons
in
-ght
cycles—that’s
what
UCD
is
all
about!
3. Enough
-me
needs
to
be
devoted
to
fine-‐tuning
UI
performance.
It
should
be
a
key
ongoing
task
for
developers
and
testers,
not
an
aqerthought.
4. Programmers
need
to
wrap
their
heads
around
asynchronous
APIs
and
event-‐driven
programming,
if
they
haven’t
already.
5. In
cases
where
performance
can’t
be
directly
improved,
don’t
keep
the
user
wai-ng
–
show
some
kind
of
progress
indica.on,
use
cached
content
liberally,
and
don’t
block
the
UI
(thread)!
14. Thanks
for
listening!
and
now
it’s
.me
for
some
Q&A
/
discussions!
Michael
Klein
michaelklein27@gmail.com
hCp://gplus.to/michaelklein27
hCp://www.linkedin.com/in/michaelklein3
@mischkl
Notes de l'éditeur
Disclaimer: Is not specifically about natural user interfaces, tablet apps, multi-touch; also not specifically about automatically adapting to different screen sizes – although that is certainly importantApplies to all user interactions in all domains It could be that I cover a lot of material that is clear to everyone—I just want to get everyone on the same page
Commentary: Why is this so? Because Apple is one of the few companies that truly invests in fine-tuning every aspect of the user experience, regardless of how much effort is needed.Note that most review sites focus on a simple paging / scrolling test in order to rate a device’s speed and “fluidity”Only in the last year has Google made UI smoothness in Android a top priority—5 versions / 5 years in.
Note for the non-programmers In the room: I’m about to devolve into techno-babble. Feel free to tune this out.Error handling issues – story about Java throwing ExceptionsStory: Async UI vs. SyncFlash – lack of async APIHTML5 – Facebook app as example – unfortunately HTML is still not there yet due to performance issues, browser differences QuickTime for Java – lcoal network access
Story: Microsoft uses exclusively Async APIs for accessing resources in Windows 8