Model Call Girls In Ariyalur WhatsApp Booking 7427069034 call girl service 24...
Â
System performance en-2
1. System
 performance
 as
 user
Â
experience
 catastrophe
Â
best
 and
 worst
 prac.ces
 for
 interac.on
 designers
 and
Â
programmers
Â
Michael
 Klein
Â
Interac.on
 designer,
 developer
 and
 UI
 connoisseur
Â
Â
h<p://gplus.to/michaelklein27,
 h<p://www.linkedin.com/in/michaelklein3,
 @mischkl
Â
2. System
 performance
 as
 user
Â
experience
 catastrophe
Â
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
Â
h<p://www.youtube.com/watch?v=HyA6UXi0v6g
Â
4. What
 am
 I
 talking
 about?
Â
Â
h<p://xkcd.com/612/
Â
5. What
 am
 I
 talking
 about?
Â
Â
h<p://www.youtube.com/watch?v=sxtYxIObjWg
Â
6. What
 am
 I
 talking
 about?
Â
Â
h<p://www.youtube.com/watch?v=nfnM_8JBmmA
Â
7. What
 am
 I
 talking
 about?
Â
Â
h<p://www.youtube.com/watch?v=apN0_NQrC0s
Â
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
Â
bu<ons
 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
 stu<er/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)
Â
â˘âŻ DiďŹcult
 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
 soMware
 developerâs
 perspec>ve)
â˘âŻ Notoriously
 diďŹcult
 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
Â
â˘âŻ DiďŹcult
 to
 pin
 down
 sources
 of
 performance
 issues
Â
â˘âŻ UI
 toolkit
 weaknesses
 (e.g.
 Flash,
 HTML5)
Â
â˘âŻ DiďŹcult
 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.sďŹed
 with
Â
sta.c
 mockups
 alone.
 Developers
 canât
 be
 sa.sďŹed
 with
 simply
Â
âlooking
 likeâ
 a
 design.
Â
2.⯠No
 âdesigning
 it
 and
 then
 dropping
 it
 oďŹ
 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
 ďŹne-Ââ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
Â
h<p://gplus.to/michaelklein27
Â
h<p://www.linkedin.com/in/michaelklein3
Â
@mischkl
Â
15. Links
Â
Jakob
 Nielsen,
 Response
 Times:
 The
 3
 Important
 Limits
Â
h<p://www.nngroup.com/ar.cles/response-Ââ.mes-Ââ3-Ââimportant-Ââlimits/
Â
Jakob
 Nielsen,
 Website
 Response
 Times
Â
h<p://www.nngroup.com/ar.cles/website-Ââresponse-Ââ.mes/
Â
Steven
 Seow,
 Designing
 and
 Engineering
 Time
 (Book)
Â
h<p://www.engineering.me.com
Â
Steven
 Seow,
 User
 Interface
 Timing
 Cheatsheet
Â
h<p://www.stevenseow.com/papers/UI%20Timing%20Cheatsheet.pdf
Â
GNOME
 Human
 Interface
 Guidelines
 2.2.2,
 Characteris>cs
 of
 Responsive
 Applica>ons
Â
h<p://developer.gnome.org/hig-Ââbook/3.5/feedback-Ââresponsiveness.html
Â