- Smartphone interfaces should be designed with short, bursty usage sessions in mind rather than long desktop sessions. Features that require many clicks or inputs should be minimized as clicks and inputs are difficult on small touchscreens.
- Designs must also account for the inaccuracy of touchscreens and avoid small, closely packed interface elements to prevent accidental selection. Notifications and messages should be used carefully so as not to overwhelm the user. Thorough testing with real users is important.
10. Satisfaction / Features - II
• Increased power widens sweet spot
• Faster CPU
– Complex features less of an issue
• More memory
– App can be larger
12. Best practices
• GUI design is not fixed science
– Sometimes, bad is good
• Like a design pattern
– Feel free to adapt
13. Dont waste screen space
• Screen real estate is severely limited
– 800x480 is common baseline
• HD resolution in mobile is NOT PC-like
– Screen is MUCH SMALLER
• Users dont have 10:10 eyes
14. Clicks are evil
• Mobile sessions are short
– Whiney wife wants to know where she‘ll eat
• Clicks require dexterity
15. Clicks are evil - II
• Solution: minimize clicks
• Dumb users are more affected
– „Simple flow“ – few clicks
– „Complex flow“ – more clicks
17. Clicks are evil - IV
• Quick access to
common functions!
• Less quick access to
rarely needed ones!
18. Clicks are evil - V
• Good approach: paper prototypes
•• EXERCISEEXERCISE
– Cell phone
– Paper
– Pen
– Scissor/Knife/Dagger/fingernail
– Comrade
20. Input is evil
• Data input on a PC is no issue
– QWERTY keyboard
• On mobile, it‘s less funny
21. Input is evil - II
• Hardware keyboards
– Somewhat fast
– Still tedious
• Swype/Graffiti/whatever
– Slow
– Take up screen real estate (!)
22. Input is evil - III
• Cache common input
• „App thinks ahead“
– Palm Pre style
23. In Rome, like the Romans
• Consistency is everything
– Inconsistent behavior => unhappyness
• Humans are animals of habit
– Rote learning is effective
– E.g. arms disassembly drill
24. In Rome, like the Romans - II
• OS vendors set strong standards
• Users are accustomed to them
•• BetterBetter blend inblend in
26. Swift like the devil
• Mobile phones are used in high pressure
• Delays are unacceptable and annoying
• Make the GUI respond swiftly
27. Swift like the devil - II
• Not always possible
– Show progress indicator
– Show „spin ball“
28. Boom-shake-a-lake!
• Desktop users have high accuracy input
– Mice are accurate as hell
– Trackpads are decent, too
– Position and Activation are two steps
• On mobile, things are different
– Hello, touchscreen
29. Boom-shake-a-lake! - II
• Resistive screen
– With stylus: 05cm x 0.5cm
– Without stylus: see below
• Capacitive screen
– Very inaccurate (even with stylus)
– 1cm x 1cm is reasonable
30. Boom-shake-a-lake - III
• The world is not an ideal place
• Users use cell phones on the run
– Trains
– Cars
– Walking
== Vibration== Vibration
31. Boom-shake-a-lake - IV
• Misclicks are really evil on touchscreens
– No Select/Confirm-Pattern
• Misclicks cause unhappy users
– They fucked up
– but your app gave them the opportunity
32. Boom-shake-a-lake V
• Avoid Misclicks
– LARGE controls
– Group controls sensibly
• Mitigate Misclicks
– Ask before wreaking havoc
35. Save power
• Power usage is critical
– Apps which drain power are unpopular
• Problems:
– Reconnection loops
– Network keepalive
– Screen colors (OLED)
37. Colors count - II
• Black causes more reflections than white
– But: OLED power issue
38. Don‘t be annoying
• Push messages are useful
– Inform users
– Can increase retention (see studies)
• IF the notification area does not overflow
39. Test on humans
• „Betriebsblindheit“
– Blindness of operator
• Developer of app understands his GUI
– Developer is not user
– User does not know your design specs
41. Test on humans - III
• Testers „burn“
– They get accustomed
• The world is full of testers
– Check forums or ask on the road
– Not being able to find testers: ouch!!!