Your SlideShare is downloading. ×
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Designing and implementing responsive, fluid UIs to delight end users
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Designing and implementing responsive, fluid UIs to delight end users

471

Published on

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 …

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.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

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

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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 importantApplies 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
  • Transcript

    • 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  
    • 4. What  am  I  talking  about?     hCp://xkcd.com/612/  
    • 5. What  am  I  talking  about?     hCp://www.youtube.com/watch?v=sxtYxIObjWg  
    • 6. What  am  I  talking  about?     hCp://www.youtube.com/watch?v=nfnM_8JBmmA  
    • 7. What  am  I  talking  about?     hCp://www.youtube.com/watch?v=apN0_NQrC0s  
    • 8. What  do  all  these  examples  have  in  common?    
    • 9. What  do  all  these  examples  have  in  common?    
    • 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  

    ×