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

?!? / !?!

tamhan@tamoggemon.com