droidcon 2013 ui smartphones tam hanna
TRANSCRIPT
Designing User Interfaces
�for smartphones
About /me
• Tam HANNA
– CEO, Tamoggemon
Ltd.
– Director,
Tamoggemon Holding
k.s.
– Runs web sites about
mobile computing
– Writes scientific books
About /girly
• Annette BOSBACH
– Clerk to the
coordinating office,
Tamoggemon Holding
k.s.
On smartphones
- or -
think before you code
Mobiles are not computers
• CPU power on par with Intel P4
• HD screens coming
• But: itit‘‘ss NOT A PCNOT A PC
Short sessions
PalmSource, The Zen of Palm
Bursty usage
PalmSource, The Zen of Palm
Features / Satisfaction
• Adding new features gets PR boost
• On a PC, more features = better app
• In mobile, things are different
Satisfaction / Features
Satisfaction / Features - II
• Increased power widens sweet spot
• Faster CPU
– Complex features less of an issue
• More memory
– App can be larger
What to do?
Best practices
• GUI design is not fixed science
– Sometimes, bad is good
• Like a design pattern
– Feel free to adapt
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
Clicks are evil
• Mobile sessions are short
– Whiney wife wants to know where she‘ll eat
• Clicks require dexterity
Clicks are evil - II
• Solution: minimize clicks
• Dumb users are more affected
– „Simple flow“ – few clicks
– „Complex flow“ – more clicks
Clicks are evil - III
• What do they do
right?
Clicks are evil - IV
• Quick access to
common functions!
• Less quick access to
rarely needed ones!
Clicks are evil - V
• Good approach: paper prototypes
•• EXERCISEEXERCISE
– Cell phone
– Paper
– Pen
– Scissor/Knife/Dagger/fingernail
– Comrade
Input is evil
• Data input on a PC is no issue
– QWERTY keyboard
• On mobile, it‘s less funny
Input is evil - II
• Hardware keyboards
– Somewhat fast
– Still tedious
• Swype/Graffiti/whatever
– Slow
– Take up screen real estate (!)
Input is evil - III
• Cache common input
• „App thinks ahead“
– Palm Pre style
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
In Rome, like the Romans - II
• OS vendors set strong standards
• Users are accustomed to them
•• BetterBetter blend inblend in��
In Rome, like the Romans - III
Swift like the devil�
• Mobile phones are used in high pressure
• Delays are unacceptable and annoying
• Make the GUI respond swiftly
Swift like the devil� - II
• Not always possible
– Show progress indicator
– Show „spin ball“
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
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
Boom-shake-a-lake - III
• The world is not an ideal place
• Users use cell phones on the run
– Trains
– Cars
– Walking
== Vibration== Vibration
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
Boom-shake-a-lake V
• Avoid Misclicks
– LARGE controls
– Group controls sensibly
• Mitigate Misclicks
– Ask before wreaking havoc
Boom-shake-a-lake VI
• What is bad?
Boom-shake-a-lake VI
• Up and Delete
• Ouch
Save power
• Power usage is critical
– Apps which drain power are unpopular
• Problems:
– Reconnection loops
– Network keepalive
– Screen colors (OLED)
Colors count
• In direct sunlight, screen contrast suffers
Colors count - II
• Black causes more reflections than white
– But: OLED power issue
Don‘t be annoying
• Push messages are useful
– Inform users
– Can increase retention (see studies)
• IF the notification area does not overflow
Test on humans
• „Betriebsblindheit“
– Blindness of operator
• Developer of app understands his GUI
– Developer is not user
– User does not know your design specs
Test on humans - II
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!!!
Further reading
• [SPOL] http://www.joelonsoftware.com/uibook/fog0000000249.html
• [GUI] http://shop.oreilly.com/product/9780596008031.do
• [ZEN] http://www.cs.uml.edu/~fredm/courses/91.308-fall05/palm/zenofpalm.pdf
?!? / !?!