System performance en-2
0 likes310 views
The document discusses the importance of system performance and responsiveness from the perspectives of users, interaction designers, and software developers. It notes that slow or unresponsive systems can negatively impact the user experience by creating frustration and usability issues. Both designers and developers need to prioritize performance testing and work together in tight cycles to ensure smooth interactions. While performance cannot always be directly improved, the user experience can be enhanced by providing feedback during longer processes.
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
- 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 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) • 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 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. 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 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