0
System	
  performance	
  as	
  user	
  
experience	
  catastrophe	
  

best	
  and	
  worst	
  prac.ces	
  for	
  interac....
System	
  performance	
  as	
  user	
  
experience	
  catastrophe	
  

best	
  and	
  worst	
  prac.ces	
  for	
  interac....
What	
  am	
  I	
  talking	
  about?	
  

Let’s	
  take	
  a	
  look	
  at	
  some	
  examples	
  

h<p://www.youtube.com/...
What	
  am	
  I	
  talking	
  about?	
  
	
  

h<p://xkcd.com/612/	
  
What	
  am	
  I	
  talking	
  about?	
  
	
  

h<p://www.youtube.com/watch?v=sxtYxIObjWg	
  
What	
  am	
  I	
  talking	
  about?	
  
	
  

h<p://www.youtube.com/watch?v=nfnM_8JBmmA	
  
What	
  am	
  I	
  talking	
  about?	
  
	
  

h<p://www.youtube.com/watch?v=apN0_NQrC0s	
  
What	
  do	
  all	
  these	
  examples	
  have	
  in	
  common?	
  
	
  
What	
  do	
  all	
  these	
  examples	
  have	
  in	
  common?	
  
	
  
TIME	
  

(aka	
  a	
  temporal	
  sequence	
  of	
  events)	
  
	
  

What’s	
  so	
  special	
  about	
  it?	
  

	
  

...
TIME	
  

(aka	
  a	
  temporal	
  sequence	
  of	
  events)	
  
	
  

What’s	
  so	
  special	
  about	
  it?	
  

	
  

...
TIME	
  

(aka	
  a	
  temporal	
  sequence	
  of	
  events)	
  
	
  

What’s	
  so	
  special	
  about	
  it?	
  

	
  

...
So	
  what	
  can	
  we	
  do	
  about	
  it?	
  
1.  Acknowledge	
  that	
  UI	
  performance	
  characteris.cs	
  are	
 ...
Thanks	
  for	
  listening!	
  

and	
  now	
  it’s	
  .me	
  for	
  some	
  Q&A	
  /	
  discussions!	
  

Michael	
  Klei...
Links	
  
Jakob	
  Nielsen,	
  Response	
  Times:	
  The	
  3	
  Important	
  Limits	
  
h<p://www.nngroup.com/ar.cles/res...
Upcoming SlideShare
Loading in...5
×

System performance en-2

49

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
49
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "System performance en-2"

  1. 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. 2. System  performance  as  user   experience  catastrophe   best  and  worst  prac.ces  for  interac.on  designers  and   programmers   What  am  I  talking  about?  
  3. 3. What  am  I  talking  about?   Let’s  take  a  look  at  some  examples   h<p://www.youtube.com/watch?v=HyA6UXi0v6g  
  4. 4. What  am  I  talking  about?     h<p://xkcd.com/612/  
  5. 5. What  am  I  talking  about?     h<p://www.youtube.com/watch?v=sxtYxIObjWg  
  6. 6. What  am  I  talking  about?     h<p://www.youtube.com/watch?v=nfnM_8JBmmA  
  7. 7. What  am  I  talking  about?     h<p://www.youtube.com/watch?v=apN0_NQrC0s  
  8. 8. What  do  all  these  examples  have  in  common?    
  9. 9. What  do  all  these  examples  have  in  common?    
  10. 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. 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. 12. TIME   (aka  a  temporal  sequence  of  events)     What’s  so  special  about  it?     (from  a  soMware  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. 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. 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. 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  
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×