- 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.

1. Designing User Interfaces
for smartphones

2. About /me
• Tam HANNA
– CEO, Tamoggemon
Ltd.
– Director,
Tamoggemon Holding
k.s.
– Runs web sites about
mobile computing
– Writes scientific books

3. About /girly
• Annette BOSBACH
– Clerk to the
coordinating office,
Tamoggemon Holding
k.s.

4. On smartphones
- or -
think before you code

5. Mobiles are not computers
• CPU power on par with Intel P4
• HD screens coming
• But: itit‘‘ss NOT A PCNOT A PC

6. Short sessions
PalmSource, The Zen of Palm

7. Bursty usage
PalmSource, The Zen of Palm

8. Features / Satisfaction
• Adding new features gets PR boost
• On a PC, more features = better app
• In mobile, things are different

9. Satisfaction / Features

10. Satisfaction / Features - II
• Increased power widens sweet spot
• Faster CPU
– Complex features less of an issue
• More memory
– App can be larger

11. What to do?

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

16. Clicks are evil - III
• What do they do
right?

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

25. In Rome, like the Romans - III

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

33. Boom-shake-a-lake VI
• What is bad?

34. Boom-shake-a-lake VI
• Up and Delete
• Ouch

35. Save power
• Power usage is critical
– Apps which drain power are unpopular
• Problems:
– Reconnection loops
– Network keepalive
– Screen colors (OLED)

36. Colors count
• In direct sunlight, screen contrast suffers

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

40. Test on humans - II

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!!!

42. Further reading
• [SPOL]
http://www.joelonsoftware.com/uibook/fog
0000000249.html
• [GUI]
http://shop.oreilly.com/product/978059600
8031.do
• [ZEN]
http://www.cs.uml.edu/~fredm/courses/91.
308-fall05/palm/zenofpalm.pdf

43. ?!? / !?!
tamhan@tamoggemon.com