Download - System performance en-2
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
What am I talking about?
System performance as user experience catastrophe
best and worst prac.ces for interac.on designers and programmers
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?
What’s so special about it? (from a user’s perspec>ve)
TIME (aka a temporal sequence of events)
• “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.)
What’s so special about it? (from an interac>on designer’s perspec>ve)
TIME (aka a temporal sequence of events)
• 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
What’s so special about it? (from a soMware developer’s perspec>ve)
TIME (aka a temporal sequence of events)
• Notoriously difficult to handle unpredictable .me values in code –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 [email protected] 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