NCDevCon2012_designing the mobile experience

Designing the mobile
experience
From a UX/UI perspective
Tuesday, October 2, 12

Dee Sadler
Adobe Community Professional
Adobe Certiﬁed Expert / Instructor
Adobe Freelancer Program
Conference Organizer - D2WC.com
UI Strategist/Android/HTML/CSS geek for Sprint
Total Training and Adobe TV (CS6) video tuts
Hybrid
@DeeSadler

Topics
Understanding how the user uses their devices
Rules of UX - Human Factor guidelines,
Orientation etc.
Sizes - from ﬁngers to pixels
Prototyping

Who are the users?

If you are going to bother making a
web app, consider the experience

How does it all work
“together”

Decide things like,
How is the user going to navigate?

“The Rules”
Human Interactioin
Guidelines

Mobile Design Life Cycle
This isn’t your dad’s website
1.Assess current user requirements
2.Understand your users
3.Prioritize mobile features
4.Design with mobile considerations
5.Prototype / preview / reﬁne / test

User Requirements
Agile, Story Boards and User Stories

Touch events
No rollovers, but does the user know
they clicked on something

What is the experience as
they move through pages
Multi-pane views

Tablet multi-plane views

Native
Don’t mimic other platforms, stay true to the OS
Don’t try and make a new interaction from one
that already exists and keep it consistent per OS
SAMPLE OF IOS, ANDROID AND
WINDOWS UI

Think top down

Think top down
Where is their hand going to be?

Think top down
Make usage easy and logical

Think top down
Design using physicality and realism

Think top down
Always work at a higher resolution
than you need.

Think top down
than you need.
Be aware of orientation

Think top down
than you need.
Add detail and depth

Think top down
than you need.
Typography is just as important

Think top down
than you need.
Think twice before you design
a standard control!

Think top down
than you need.
Think twice before you design
a standard control!
Create a great brand experience

4 step process
Designing for multiple screens
Define device groups by grouping screens with
similar widths together resulting in a manageable
number of groups,
Create a default reference design that will adapt
to smaller and larger screens,
Define rules for content and design adaptation
for it to display well and
Opt for Web standards and a flexible layout.

What else
Simplify navigation
Be succinct with the content
Minimize user input
Form efﬁciency
Can they use it ofﬂine?
Don’t use high res images for everything
Don’t forget to test!

Device Sizes

Sizes (some examples)
iPhone 3GS, iOS 4.3.n, 320x480px (no retina display)
iPhone 4, iOS 5, 320x480px (retina display)
iPad, iOS 5, 1024x768px (10" tablet, no retina display)
Android 2.1 — Motorola, 480x600px (popular)
Android 2.3 — HTC, 480x320px (QWERTY)
Android 2.3 — Huawei, 320x480px (low CPU)
Android 3.0 — Samsung, 320x480 (low CPU, low dpi)
Android 2.3.4 — Kindle Fire, 1024x600 px (7" tablet, proxied
browsing)

Android - trouble x 10
xlarge screens are at least 960dp x 720dp
large screens are at least 640dp x 480dp
normal screens are at least 470dp x 320dp
small screens are at least 426dp x 320dp

Pixel Density/Screen size
To get the ppi, you first need to find out how many
pixels there are diagonally.
This is the square root of each side squared, added
together (from a2 + b2 = c2)
Android densities: low, medium, high and extra high
Density-independent pixel (dp)
A virtual pixel unit that you should use when defining UI layout, to express layout dimensions or position in
a density-independent way.
The density-independent pixel is equivalent to one physical pixel on a 160 dpi screen, which is the baseline
density assumed by the system for a "medium" density screen.At runtime, the system transparently handles
any scaling of the dp units, as necessary, based on the actual density of the screen in use.The conversion of
dp units to screen pixels is simple: px = dp * (dpi / 160). For example, on a 240 dpi screen, 1 dp equals 1.5
physical pixels.You should always use dp units when defining your application's UI, to ensure proper display
of your UI on screens with different densities.
http://developer.android.com/guide/practices/screens_support.html

HTML5 Image issues
Which method to use? Scale. replace images at
each break point, what?
Start with small and then serve up larger at each
break point?

Solutions

Pros
Mimics other media syntax like <video> and
<audio>, which makes sense.
The fallback makes it backwards-compatible with
browsers that don't support it, which is extremely
important. We can't have images that just don't
work in older browsers.
Gives us web authors the control to show exactly
what we want under situations we specify.

Cons
It's a whole lot more complicated than <img>.
Harder to teach, harder to learn, more code to
write. Easy to screw up.
Muddies the water of CSS and HTML a bit, by
bringing the media query syntax into HTML.
Similar issues to why inline styles are bad. Makes
future updates more difﬁcult. Not a reusable
abstraction.

Adaptive Images

Skeumorphism

Designing
Use vector shapes where possible
Start with large artboards
Get rid of unnecessary metadata on images
Decide which format of images works best for the
images. Are they opaque, transparent, etc.
If Android, keep consistent naming conventions
for different density images

SHOWING BAD PATCHES

CSS Sprites

Prototype
Prototype

jQuery Mobile Starter Pages

Wireframe
Tools
Balsamiq
Axure
Fireworks
Ommnigrafﬂe
EightShapes for InDesign
iMockups for iPad
SketchyPad for iPad
Keynottopia for Keynote
many, many more

FIREWORKS ANDROID TEMPLATE

Fireworks CS6
CSS Sprites
CSS Properties Panel
jQuery theme creation
New wireframing tools
Gesture icons

Example: Title Bar

Thanks!

NCDevCon2012_designing the mobile experience

Recommended

Recommended

More Related Content

Similar to NCDevCon2012_designing the mobile experience

Similar to NCDevCon2012_designing the mobile experience (20)

Recently uploaded

Recently uploaded (20)

NCDevCon2012_designing the mobile experience