• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
System performance as usability catastrophe
 

System performance as usability catastrophe

on

  • 449 views

A brief discussion about how system performance in terms of user interface fluidity impacts user experience, and how this important factor can be better prioritized by designers, software engineers ...

A brief discussion about how system performance in terms of user interface fluidity impacts user experience, and how this important factor can be better prioritized by designers, software engineers and project managers.

Statistics

Views

Total Views
449
Views on SlideShare
304
Embed Views
145

Actions

Likes
0
Downloads
1
Comments
0

1 Embed 145

http://www.uxcamp.at 145

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    System performance as usability catastrophe System performance as usability catastrophe Presentation Transcript

    • What  am  I  talking  about?   Let’s  take  a  look  at  some  examples   h<p://www.youtube.com/watch?v=HyA6UXi0v6g  
    • 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?     (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.)  
    • 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  
    • 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  
    • 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)!    
    • 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  
    • 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