Pragmatic Responsive Design

responsive design
http://www.flickr.com/photos/dwonderwall/3341419492

pragmatic
making the best of old and new techniques
This presentation is...
•
part
case study
•
part
lessons learned
•
part
future-thinking
browser.nokia.com
A small
campaign site
introducing
three new web
browsers
for Nokia devices.
THE CASE STUDY
iPad
Chrome
Opera Mini
Nokia N97
Site goals:
•
Inform
end-users and industry
•
Prompt end-users to
update their browser
•
Experiment with responsive design to support
a
global audience
and
wide range

of target devices
.
Call to action:
Update your browser!
THE CASE STUDY
70+
target
Nokia devices
Symbian^3/Anna/MeeGo
Touch (+ many w/ keyboards)
2008-present
WebKit browser
11 devices
Series 60
Touch and non-touch
2006-present (S60 3rd FP 1/2)
WebKit browser
45 devices
Series 40
Touch and non-touch
2008-present (~S40 6th Edition)
WebKit browser or
Nokia proxy browser
23 devices
new browser
being promoted
+ all the usual suspects
v. 7+
mobile
desktop
most Nokia users on S40
feature phones use Opera Mini
v 6.0+
legacy and/or XHTML-MP browsers
Internet Browser
Obigo
Windows Mobile
UC Web
< v 5.0
no support
planned for
initially
Nokia S40 Lite
Browser
popular Chinese
proxy browser
Part 1:
The design process
http://www.flickr.com/photos/jordanfischer/63832583
You can’t get there from here
Designing
only

pixel perfect mock-ups
makes it
difficult
near-impossible to then
think responsively
.
an
emerging
process
sketches/IA
basic visual
mockups
“live”
responsive
mockup
more
sketches
“live”
responsive
mockup
small visual mockups
to discuss specific
stylistic issues
“live” responsive
mockup to “reality check”
performance and
progressive enhancement
etc...
ok?
yes
no
content
first
sketches/IA
basic visual
mockups
“live”
responsive
mockup
more
sketches
“live”
responsive
mockup
small visual mockups
to discuss specific
stylistic issues
“live” responsive
mockup to “reality check”
performance and
progressive enhancement
etc...
ok?
yes
no
message/
brand/
strategy
copy
draft 1
copy
draft 2
If it’s layout
prototype it.
(...on real devices to clarify
changes in context
and the
impact of naive capabilities
and
viewport
conditions)
If it’s visual design
mock it up
(...but then prototype to determine
performance
, impact
of
native fonts
and
em values
,
viewport
coditions etc.)
PAIN POINT
Too many
to mention.
Mental models
in particular are getting in the way.
We (our teams, our clients, their marketing departments
etc.) still
presume
and
expect we can control too much
.
We have
lots of counterproductive
behaviours
we need to
unlearn
.
•
Creating
elaborate workarounds
to suit (what you
perceive) as edge case screen sizes or devices.
•
Agonising over
small differences in rendering and
alignment
(remember...
each device you haven’t testing
on
will have its own quirks.)
•
Creating
elaborate reference lists
of screen sizes,
pixel densities in the belief that
with enough data
you can design for
each
device.
•
etc...
Part 2:
The CSS strategy
http://www.flickr.com/photos/wscullin/3770015203
Mobile first
Design for (the simplest)
mobile
browser first.
TECHNIQUE
The
absence
of a media query
is in fact,
the first media query.
Bryan Rieger, Rethinking the Mobile Web
“
fully flexible with default
styles for navigation,
fonts, content and
no media query
begin with a
lightweight default
A
B
C
Embrace the cascade
Don’t merely swap style sheets
...let it cascade.
This creates a
more nimble
,
versatile
and
future-proof
layout and
can

reduce jumpiness during device
re-orientation
.
TECHNIQUE
each style sheet
augments the others
augment original
style sheet
with
(
only
) the style
changes that are
needed to enhance
the layout
A
B
C
xx
px to
xxx
px
breakpoint
breakpoint
A
B
C
<
xx
px wide
(or unable to
understand further
instructions)
style sheet 1
A
B
C
xx
px to
xxx
px
A
B
C
>
xxx
px wide
breakpoint
breakpoint
A
B
C
<
xx
px wide
(or unable to
understand further
instructions)
augment
once
again for
TVs etc.
breakpoint
style sheet 1
style sheet 2
each style sheet
augments the others
TECHNIQUE
Using
major
and
minor
breakpoints
Create
media queries
inside of
media queries
.
Why we call them
major
and
minor
breakpoints
major layout
changes
content or
device specific
tweaks
a common approach
One
style sheet with media
queries on the inside.
styles.css
@media {
(min-width: 480px)
}
@media {
(min-width: 640px)
}
@media {
(min-width: 768px)
}
@media {
(min-width: 320px)
}
a single css !le is network
efficient, but includes
unnecessary style data that
all devices end up downloading
MAJOR
BREAKPOINTS
IN DOCUMENT
HEAD
a more robust option
Multiple
style sheets with
media queries on the inside.
basic.css
mobile.css
desktop.css
MINOR
BREAKPOINTS
WITHIN EACH
STYLE SHEET
@media {
(min-width: 480px)
}
@media {
(min-width: 640px)
}
@media {
(min-width: 768px)
}
(typically)
no media
queries
media

screen
and
(min-width: 1024px)
{
section ul li {
width: 20%;
}
}
link
rel
"stylesheet"
type
"text/css"
href
"stylesheets/base.css"

media
"screen, handheld"
/
link
rel
"stylesheet"
type
"text/css"
href
"stylesheets/desktop.css"

media
"only screen and (min-width: 720px)"

/
link
rel
"stylesheet"
type
"text/css"
href
"stylesheets/mobile.css"
media
"only screen and (min-width: 320px)"

/
MAJOR BREAKPOINTS IN DOCUMENT HEAD
MINOR BREAKPOINTS WITHIN EACH STYLE SHEET
cause
multiple http requests
?
don’t
multiple style sheets

(which will affect performance)
Yes!
...but (as we will see) we have
bigger issues...
Otherwise known as...choose your partners wisely.
Source: Matthew Ogborne,
Facebook Like Button = 84Kb or 1.340 Seconds?
More great examples on Steve Souders’
P3PC project site
Facebook Like
Button
but it’s just
“one line of code”
84Kb, ~10 http requests
(or 1.340 Seconds)
I’m wondering if he
ran this test on a
PC with broadband?
=
3rd party requests don’t just include
widgets
,
they can also include:
•
ads
•
analytics
•
utilities
(comment utilities, font hosting etc.)
•
libraries
and
polyfills
Many of these services are
not yet mobile
friendly.
(And many that claim they are, merely support certain mobile browsers.
They may not necessarily be lightweight or conscious of performance).
everything has dependencies
Otherwise known as
everyone has ‘partners’
Source: Luma Partners
Example:
1 line of code spawns
49
server calls (including
21
redirects)
“What happens next is the scary part:
You effectively
lose all control.
”
- Web Performance Today,
Fourth Party Calls
Conclusion
If a few
well chosen
http requests
enable you
to improve the experience
-go for it.
(then take a long hard look at other requests that may be lurking)
choosing
breakpoints
TECHNIQUE
Disclaimer
There is
no
“
perfect set”
of breakpoints.
Set
your
breakpoints based on
your
project goals,
your
target audience,
your
typical device market share,
the weight and nature of
your
content, the nature of
your
design...
Major Breakpoint 1
(media query in document head)
Major Breakpoint 3
(media query in document head)
320 px to 720 px wide
720 px to 1024 px
major
breakpoints
Example
major layout changes
320
720
Major Breakpoint 2
(media query in document head)
nothing is
here...but
that’s ok!
(P) = Portrait
(L) = Landscape
(L*) = Landscape w/ native viewport adaptation
< 320 px wide
and/or
unable to
understand further
instructions
1024
iPhone (P)
many Android (P)
many BlackBerry
S60 QWERTY
Most S60 (L)
S40 QWERTY
some tablets
most NetBooks
many Desktops
Major Breakpoint 3
(media query in document head)
iPhone (L*)
Android (L*)
some
Symbian
touch (L)
some
tablets (L)
some
Symbian
touch (L)
640
768
360
720
Major Breakpoint 1
(media query in document head)
Major Breakpoint 2
(media query in document head)
720 px to 1024 px
320 px to 720 px wide
nothing is
here...but
that’s ok!
320
minor
breakpoints
Example
Symbian
touch (P)
(P) = Portrait
(L) = Landscape
(L*) = Landscape w/ native viewport adaptation
iPhone (P)
many Android (P)
many BlackBerry
S60 QWERTY
Most S60 (L)
S40 QWERTY
< 320 px wide
and/or
unable to
understand further
instructions
iPad (P)
some Android
tablets (P)
Minor
Breakpoint
(@media)
1024
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
480
some tablets
most NetBooks
many Desktops
content-related tweaks
iPhone (L*)
Android (L*)
some
Symbian
touch (L)
some
tablets (L)
Minor
Breakpoint
(@media)
Major Breakpoint 3
(media query in document head)
480
640
768
360
Symbian
touch (P)
720
Major Breakpoint 1
(media query in document head)
Major Breakpoint 2
(media query in document head)
720 px to 1024 px
320 px to 720 px wide
nothing is
here...but
that’s ok!
320
240
Minor Breakpoint
for
small devices

w/media query
support
< 320 px wide
and/or
unable to
understand further
instructions
...and
so on
Example
some
Symbian
touch (L)
(P) = Portrait
(L) = Landscape
(L*) = Landscape w/ native viewport adaptation
iPad (P)
some Android
tablets (P)
1024
TVs
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
iPhone (P)
many Android (P)
many BlackBerry
S60 QWERTY
Most S60 (L)
S40 QWERTY
some
Android (P)
many S40 (P)
most S60 (P)
some tablets
most NetBooks
many Desktops
as you can see, this has the potential to
get out of hand...
iPhone (L*)
Android (L*)
some
Symbian
touch (L)
some
tablets (L)
Minor
Breakpoint
(@media)
some
tablets
(L)
640
768
360
Symbian
touch (P)
720
Major Breakpoint 1
(media query in document head)
Major Breakpoint 2
(media query in document head)
TVs
720 px to 1024 px
320 px to 720 px wide
nothing is
here...but
that’s ok!
320
240
Minor Breakpoint
for
small devices

w/media query
support
some
Android (P)
many S40 (P)
most S60 (P)
< 320 px wide
and/or
unable to
understand further
instructions
some
Symbian
touch (L)
iPad (P)
some Android
tablets (P)
Minor
Breakpoints
(@media)
some
tablets (L)
1280
800
Minor
Breakpoint
(@media)
600
some
tablets (P)
some tablets
most NetBooks
many Desktops
1366
many
laptops
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
Minor
Breakpoint
(@media)
Major Breakpoint 3
(media query in document head)
iPhone (P)
many Android (P)
many BlackBerry
S60 QWERTY
Most S60 (L)
S40 QWERTY
Minor
Breakpoint
(@media)
480
1024
Existential question of the day:
Does it make sense to create a breakpoint
if there is
no known device
with that
screen size?
(...or put more bluntly is it worth setting a breakpoint
just so
stuff looks pretty
when you
resize your
desktop browser
?)
But most people aren't
scaling
the site
...that's
mostly a
developer behaviour.
@tubes
“
Follow-up question:
Does it therefore make sense to create a
breakpoint
just because
there
IS

a known
device
with that screen size?
device
and
browser
market share
get to know
regional
traffic
logs
review
your
existing
(even if your site isn’t mobile friendly,
your logs will contain mobile traffic)
review your
content
128x160
320x480
480x800
240x320
1024x768
1280x768
key breakpoints
then determine
your
...but remember
Screen dimensions
are only
one factor
to consider.
or emulators
don’t

rely
on desktop tools
all that matters is
how it
once you get
below ~800 px
looks
on
real devices
what if it’s not the native browser?
Opera Mini for iPad has a bit
more chrome
and
less CSS support
..how will that affect things?
not accurate if your
viewport
is
set to device-width
how will this device’s
native fonts

compare to desktop emulation?
note:
moving
target
value
example
real-world
major
and
minor
breakpoints
Major Breakpoint 2
721 px onwards
Major Breakpoint 1
321 - 720 px
Default
No media query
major
breakpoints
Major Breakpoint 2
721 px onwards
Major Breakpoint 1
321 - 720 px
Default
No media query
layout is primarily
centered
‘desktop’ layout
including floats
background
image removed
to reduce page
weight and
reduce risk on
older devices
major
breakpoints
Minor Breakpoint
@360 px (Nokia touch)
Minor Breakpoint
@480 px (Nokia touch)
Minor Breakpoint
@768 px (iPad)
Note:
Screenshots taken
on a Mac, proportions,
font sizes, and end result
vary more relevantly on
each device.
minor
breakpoints
Minor Breakpoint
@360 px (Nokia touch)
Minor Breakpoint
@480 px (Nokia touch)
Minor Breakpoint
@768 px (iPad)
custom Nokia font
50%
50%
30%
70%
45%
55%
50%
30%
45%
3em
line
height
background aligned top
background
aligned bottom
background x-position
adjustment
Note:
Screenshots taken
on a Mac, proportions,
font sizes, and end result
vary more relevantly on
each device.
image slides
up and down
revealing

more (or less)
of the content
alignment (top/bottom) and x-position
adjusted to suit the
content
(image)
and
context
(screen size)
Component adapts to suit differing browser environments
e.g. slight differences in layout caused by different
viewport implementations
,
differing
baseline em values
,
wider/narrower
native
fonts
,
padding
and

margin
variations etc.
responsive divider implemented using
border-image
(degrades gracefully on all but IE)
Designing breakpoints
also reveals
another important issue.
We
cannot presume
that
screen size

maps
to
browser
(or device) capabilities.
when queried, these devices will
all
return a
320 pixel
wide viewport
value but
each

have vastly different browsers
•
advanced CSS

and
JavaScript
•
touch events
•
modern WebKit
•
very
basic CSS

and
JavaScript
•
no touch screen
•
XHTML MP
•
good CSS
and
JavaScript
•
no touch screen
•
early WebKit
•
strong CSS and
JavaScript support
but
using proxy
browse
r such as
Opera Mini
PAIN POINT
Responsive design will
only get you half way.
Always
pair responsive design
with a
feature detection
and adaptation strategy.
Media queries detect
screen size

and serve
size-appropriate
styles
and behaviours
layout
Feature detection
clarifies
actual browser
capabilities
and enables
further enhancements
appropriately
sized
graphics
enhanced look
and feel
basic look
and feel
functionality
enhancements
basic
functionality
+
someday we’ll
(hopefully) be
able to detect
other useful
stuff like
bandwidth
(even) more
appropriate
graphics or
media formats
(e.g. SVG)
STEP 1
STEP 2
The more (
accurate
) information
you can
detect
, the
more intelligently
you can
adapt
.
Client-side feature detection
is
only one
of the tools
you can use.
Others include
device databases
,
user agent strings
and
your own (domain and region-specific)
tacit knowledge
.
TIP
Why should we need
tacit knowledge
when
we can
detect browser capabilities
using
JavaScript or tools such as Modernizr?
Because
‘support’
is rarely a binary thing.
Also....
some browsers
lie
.
TIP
TIP
More information about feature detection, will be covered in Bryan’s
Breaking Development presentation: Adaptation
Part 3:
responsive images
http://www.flickr.com/photos/mrs_logic/4548681436
TECHNIQUE
Serving
appropriate images
to each device
A pragmatic approach using both
server
and
client
.
include images
for the simplest
screen size/
browser first
on more advanced browsers (or at orientation
change), detect the screen size (using JavaScript),
rewrite/adapt the image tag, then load an
appropriate larger image
most responsive image
techniques
focus
primarily on the client
design
mobile
first
including images
for the
largest
screen size

first
put the burden of
screen size
detection, resizing
and/or

loading of new images
on
the smallest devices
design
“desktop first”
(...but let’s be honest,
most

responsive

sites
are still doing THIS)
Read this now:
Where are the mobile first responsive designs?
both impose a
heavy burden
on
constrained devices
1. detect
screen
size
2. spider
DOM
3. adapt
markup
4. request
new image
5. repaint,
reflow as
needed
fetching new
images =
extra hp
requests and
latency
depending on the
technique the initial
‘larger’ images may
already have been
downloaded
“
Optimize front-end performance first,
that's where
80% or more of the end-user
response time
is spent.
— Yahoo:
The importance of front-end performance
“
Optimize front-end performance first,
that's where
80% or more of the end-user
response time
is spent.
— Yahoo:
The importance of front-end performance
This was written with the
desktop in mind
...
research suggests performance impact on
mobile is
closer to 97%
.
Web Performance Today:
97% of mobile end-user response time happens on the client
STRATEGY
client
server
http://domain.org
heavy lifting
(adaptation, filtering,
conditional
resource/content
loading)
just-in-time
tweaks
device
database
HEAVY LIFTING
to determine
device screen
size
UA string
tacit data
to override the
odd property
based on
existing
knowledge
to identify device
and therefore,
screen size
see Bryan’s
Adaptation

presentation for greater
detail on this technique
device request
generate
!nal markup
device
database
cookie
HEAVY LIFTING
UA string
tacit data
see Bryan’s
Adaptation

presentation for greater
detail on this technique
application
logic
to determine
device screen
size
to override the
odd property
based on
existing
knowledge
to identify device
and therefore,
screen size
data
images
video
device gets the most
appropriate images
on first load
(in most cases)
no additional client-side
processing is required
!nal
markup
cookie
pro!le
resource
bundle
info
DELIVERY
TWEAKS
@media
changes assets
on
orientation
change
JavaScript
changes layout
and other styles
new images are
only fetched if
actually needed
!nal
markup
cookie
pro!le
resource
bundle
info
images
JavaScript also swaps images when
screen is resized. This enables you to
test adaptation on desktop browsers!
BONUS
uses onResize event
(because onOrientation change
doesn’t work on all devices)
Demo...
...use the
contextual intelligence
built into
the profile cookie to implement
other useful
enhancements.
These could include:
•
more appropriate
image formats
(e.g. SVG)
•
mobile-friendly
alternates for 3rd party widgets
•
alternative components
•
alternate
content representations
(e.g. tabular data)
TIP
Progressively enhanced
content.
“One Web” is a great ideal, but sometimes,
adding
or
removing
content based on
contextual instructions
can
dramatically imrpove the experience.
EXAMPLE
generate
!nal markup
device
database
UA string
determine
device model
(e.g. Nokia N8-00)
determine
device platform
(in cases where UA string
couldn’t provide it)
determine device platform
(e.g. S60 3rd Edition)
choose
appropriate device-
specific message
(populated with
device model number)
enhance
existing content with
device-specific message
Note: enhancement only as we didn’t want to
presume people on a PC might not want to
know how to update a featurephone
GOAL
improve
browser
update instructions

on browser.nokia.com
so we can
do this...
Server-side adaptation
pain points
•
reliance on cookies
•
say good-bye to the intelligent default
•
unknown devices
•
CDNs anyone?
PAIN POINT
Reliance on cookies
•
what happens if
cookies are disabled
?
•
what do we do about the
EU Cookie Directive
?
PAIN POINT
Say goodbye to the ‘intelligent default’
•
how do we create
intelligent defaults
when there is
no longer a ‘normal/average/typical’ screen size
or
even
a ‘typical’ device?
mobile first?
desktop first?
<something or other> first
What about
unknown devices?
•
what happens to
new devices
that are not yet in a
device database or your tacit knowledge database?
PAIN POINT
an
80/20
approach

will get you quite far
•
on many site,
80% of traffic
seems to come
from about
20% of devices
•
of the other 20%,
most are known devices
•
regularly reviewing your logs can help
catch
whatever is left
TIP
User agent strings
are
not evil.
User agent strings can be incredibly useful...so long as you
understand their limitations
.
TIP
Mozilla/5.0 (
SymbianOS
/
9.4
; Series60/5.0
NokiaN97
;
Profile/MIDP-2.1 Configuration/CLDC-1.1)
AppleWebKit/525

(KHTML, like Gecko)
BrowserNG/7.1.4
browser
version
operating
system
device
version
hint at (general)
capabilities
super useful in
conjunction with tacit
knowledge database
PAIN POINT
CDNs anyone?
•
CDNs currently
couldn’t care less about device context.

Will aggressive caching turn into a problem?
(Would we even have created CDNs, or have designed them
quite differently if
multi-context content
had come first?)
http://www.flickr.com/photos/jurvetson/5201796697
Part 4:
responsive workflows
Desktop
Mobile
Basic
message clarity & thematic consistency
key goals
when
designing
responsive images
visual consistency
(in a given context)
alignment
a “
normal”
workflow
we began with
in
one context
each graphic designed
approach
using Adobe
Fireworks
approach
but rapidly switched to
a more
context-sensitive
Benefits
Designing graphics together provides
a more global and contextual view.
•
Helps eliminate
alignment errors
,
continuity issues
etc.
•
Helps
maintain thematic consistency.
Images don’t
have to be identical but the
overall message should
not be lost.
•
Tip:
Don’t forget that you can also
vary file types
(e.g. PNG, JPG) to increase performance at certain sizes.
PAIN POINT
It’s still
not flexible enough...
Design tools enabling the use of variables, conditionals etc.
would be really nice right about now.
Part 5:
embrace opportunities
http://www.flickr.com/photos/ganesha_isis/4439563089
We realised half way through the project that
with only minor changes
, we could
support
another 80-100 Nokia feature phones
.
Many of these older, low-end devices
would also be
eligible to update
to the new (proxy-based) Nokia
Browser for mobile phones.
device
database
UA string
determine device
platform
generate
!nal markup
generate
!nal markup
change doctype from
HTML5 to XHTML MP
serve a lightweight
CSS MP style sheet
Goal:
get information out
to
more people
no change required
to mobile first
responsive approach
everyone
else
older S40
devices
So how did it go?
So how did it go?
We soft-launched the site 5 days ago...
133 countries
since then it’s been visited by people in
Nokia devices
on
51 different
(and of course many non-
Nokia devices)
including
the odd
Nokia N70
XHTML MP
176 x 208 px
2005
Nokia 1680
XHTML MP
128 x 160 px
2008
unexpected
ones
oldest
smallest
3 of these users
were in the US!
So far...the
most popular page
(just behind the home page) is the page
with
instructions to update your
browser :-)
http://www.flickr.com/photos/dwonderwall/3341419492
a few
final words...
Perform a
cost-benefit analysis
for
every technique
you use.
on
being pragmatic
Old

doesn’t mean

bad

and

new

doesn’t mean

good
.
If a technique
does more good than
bad

it’s fair game.
(Until a significantly better one comes along.)
on
being pragmatic
...develop your mobile strategy but
in the meantime...
there are
useful things
you can do
today
on
being pragmatic
STEP 1
STEP 2
STEP 3
Develop an
action plan
to address common issues
such as these:
•
key content that is
only
accessible on hover
•
key controls that are t
oo
small to manipulate
on
touch screens
•
modal windows
that
become unusable on small
screens
•
unnecessary
http requests
•
unnecessarily
heavy
graphics
and
media
Review your traffic
logs and determine
what mobile
devices

are
accessing your
site today
Test your site on those
devices and determine
where the experience
breaks down
repeat...
http://www.flickr.com/photos/tinou/453593446
hello
@yiibu.com
thank
you
many thanks to the
amazing photographers
on
http://creativecommons.org/licenses/by/2.0
http://www.flickr.com/creativecommons/by-2.0
@yiibu
contact us
at