designing and implementing responsive, fluid uis to delight end users
TRANSCRIPT
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
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?
What am I talking about? Let’s take a look at some examples
hCp://www.youtube.com/watch?v=HyA6UXi0v6g
What am I talking about?
hCp://www.youtube.com/watch?v=sxtYxIObjWg
What am I talking about?
hCp://www.youtube.com/watch?v=nfnM_8JBmmA
What am I talking about?
hCp://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 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.)
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 soPware 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] hCp://gplus.to/michaelklein27 hCp://www.linkedin.com/in/michaelklein3 @mischkl