The document discusses responsive design for a site promoting new web browsers for Nokia devices. It describes the design process used, which emphasized prototyping designs on real devices to understand how changes would impact the context and user experience at different screen sizes. It also discusses the CSS strategies used, including a mobile-first approach, embracing the cascade to allow styles to augment one another progressively, and using major and minor breakpoints in media queries to target specific devices. Examples of major and minor breakpoints are provided.
5. THE CASE STUDY
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!
6. 70+ target Nokia devices
Symbian^3/Anna/MeeGo Series 60 Series 40
Touch (+ many w/ keyboards) Touch and non-touch Touch and non-touch
2008-present 2006-present (S60 3rd FP 1/2) 2008-present (~S40 6th Edition)
WebKit browser WebKit browser WebKit browser or
11 devices 45 devices Nokia proxy browser
23 devices
new browser
being promoted
7. + all the usual suspects
most Nokia users on S40
feature phones use Opera Mini
v 6.0+
mobile
v. 7+
desktop
8. initially
no support planned for
legacy and/or XHTML-MP browsers
< v 5.0 Obigo
Windows Mobile
Nokia S40 Lite
Browser
Internet Browser
UC Web
popular Chinese
proxy browser
9. Part 1: The design process
http://www.flickr.com/photos/jordanfischer/63832583
10. You can’t get there from here
Designing only pixel perfect mock-ups makes it
difficult near-impossible to then think responsively.
11. an emerging process
etc...
sketches/IA basic visual “live” more “live”
mockups responsive sketches responsive
mockup mockup
no
ok?
“live” responsive small visual mockups
yes mockup to “reality check” to discuss specific
performance and stylistic issues
progressive enhancement
12. message/ copy copy content first
draft 1 draft 2
brand/
strategy
etc...
sketches/IA basic visual “live” more “live”
mockups responsive sketches responsive
mockup mockup
no
ok?
“live” responsive small visual mockups
yes mockup to “reality check” to discuss specific
performance and stylistic issues
progressive enhancement
13. 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.)
14. 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.
15. 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...
16. Part 2: The CSS strategy
http://www.flickr.com/photos/wscullin/3770015203
17. TECHNIQUE
Mobile first
Design for (the simplest) mobile browser first.
18. “
The absence of a media query
is in fact, the first media query.
Bryan Rieger, Rethinking the Mobile Web
19. begin with a lightweight default
A
fully flexible with default
B styles for navigation,
fonts, content and
C
no media query
20. TECHNIQUE
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.
21. each style sheet augments the others
breakpoint breakpoint
style sheet 1
augment original
A A
B style sheet with
B C
(only) the style
C changes that are
needed to enhance
the layout
< xx px wide xx px to xxx px
(or unable to
understand further
instructions)
22. each style sheet augments the others
breakpoint breakpoint breakpoint
style sheet 1 style sheet 2
A C
A A B
B augment
B C
once
again for
C TVs etc.
< xx px wide xx px to xxx px >xxx px wide
(or unable to
understand further
instructions)
23. TECHNIQUE
Using major and minor breakpoints
Create media queries inside of media queries.
24. content or
device specific
tweaks
Why we call them major and minor breakpoints
major layout
changes
25. a common approach
One style sheet with media
queries on the inside.
styles.css
@media {
(min-width: 320px)
}
a single css file is network
@media { efficient, but includes
(min-width: 480px) unnecessary style data that
} all devices end up downloading
@media {
(min-width: 640px)
}
@media {
(min-width: 768px)
}
26. a more robust option
Multiple style sheets with
media queries on the inside.
MAJOR
BREAKPOINTS
IN DOCUMENT
HEAD
basic.css mobile.css desktop.css
MINOR
(typically) @media { @media {
BREAKPOINTS
no media (min-width: 480px) (min-width: 768px)
WITHIN EACH queries } }
STYLE SHEET
@media {
(min-width: 640px)
}
27. MAJOR BREAKPOINTS IN DOCUMENT HEAD
<link rel="stylesheet" type="text/css" href="stylesheets/base.css"
media="screen, handheld" />
<link rel="stylesheet" type="text/css" href="stylesheets/mobile.css"
media="only screen and (min-width: 320px)" />
<link rel="stylesheet" type="text/css" href="stylesheets/desktop.css"
media="only screen and (min-width: 720px)" />
MINOR BREAKPOINTS WITHIN EACH STYLE SHEET
@media screen and (min-width: 1024px) {
section ul li {
width: 20%;
}
}
28. don’t multiple style sheets
cause multiple http requests?
(which will affect performance)
29. Yes!...but (as we will see) we have
bigger issues...
Otherwise known as...choose your partners wisely.
30. 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
Facebook Like PC with broadband?
Button
Source: Matthew Ogborne, Facebook Like Button = 84Kb or 1.340 Seconds?
More great examples on Steve Souders’ P3PC project site
31. 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).
33. 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
34. 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)
36. 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...
37. (P) = Portrait
Example (L) = Landscape
(L*) = Landscape w/ native viewport adaptation
major breakpoints
major layout changes
Major Breakpoint 1 Major Breakpoint 2
(media query in document head) (media query in document head) Major Breakpoint 3
(media query in document head)
1024
320 px to 720 px wide 720 px to 1024 px
320 720
< 320 px wide
and/or unable to nothing is
understand further here...but
some tablets
instructions that’s ok!
most NetBooks
iPhone (P) many Desktops
many Android (P)
many BlackBerry
S60 QWERTY
Most S60 (L)
S40 QWERTY
38. (P) = Portrait
Example (L) = Landscape
(L*) = Landscape w/ native viewport adaptation
minor breakpoints
content-related tweaks
Major Breakpoint 1 Major Breakpoint 2
(media query in document head) (media query in document head) Major Breakpoint 3
Minor (media query in document head)
Breakpoint
(@media)
Minor Minor Minor
Breakpoint Breakpoint Breakpoint
(@media) (@media) (@media)
360 480 640 768 1024
320 px to 720 px wide 720 px to 1024 px
320 720
< 320 px wide iPhone (L*)
and/or unable to Android (L*) nothing is
understand further Symbian some here...but iPad (P)
touch (P) some tablets
instructions Symbian that’s ok! some Android most NetBooks
iPhone (P) touch (L) tablets (P) many Desktops
many Android (P) some some
many BlackBerry tablets (L) Symbian
S60 QWERTY touch (L)
Most S60 (L)
S40 QWERTY
39. (P) = Portrait
Example (L) = Landscape
(L*) = Landscape w/ native viewport adaptation
...and so on
Major Breakpoint 1 Major Breakpoint 2
(media query in document head) (media query in document head) Major Breakpoint 3
Minor (media query in document head)
Breakpoint
Minor Breakpoint
(@media)
for small devices Minor Minor Minor
w/media query Breakpoint Breakpoint Breakpoint
support (@media) (@media) (@media)
TVs
240 360 480 640 768 1024
320 px to 720 px wide 720 px to 1024 px
320 720
< 320 px wide iPhone (L*)
and/or unable to Android (L*) nothing is
understand further Symbian some here...but iPad (P)
touch (P) some tablets
instructions Symbian that’s ok! some Android most NetBooks
iPhone (P) touch (L) tablets (P) many Desktops
some
many Android (P) some
Android (P) some
many BlackBerry tablets (L)
many S40 (P) Symbian
most S60 (P) S60 QWERTY touch (L)
Most S60 (L)
S40 QWERTY
40. as you can see, this has the potential to get out of hand...
Minor
Breakpoint
Major Breakpoint 1 (@media) Major Breakpoint 2
(media query in document head) (media query in document head) Major Breakpoint 3
Minor (media query in document head)
Breakpoint Minor
Minor Breakpoint
(@media) Breakpoint
for small devices Minor Minor Minor (@media) Minor
w/media query Breakpoint Breakpoint Breakpoint Breakpoints
support (@media)
(@media) (@media) (@media)
TVs
240 360 480 600 640 768 800 1024 1280 1366
320 px to 720 px wide 720 px to 1024 px many
laptops
720 some
< 320 px wide 320 some
iPhone (L*) tablets
and/or unable to nothing is tablets (L)
Android (L*) (L)
understand further Symbian some here...but iPad (P)
touch (P) some tablets
instructions Symbian that’s ok! some Android most NetBooks
iPhone (P) touch (L) tablets (P) many Desktops
some
many Android (P) some
Android (P) some
many BlackBerry tablets (L)
many S40 (P) Symbian
most S60 (P) S60 QWERTY touch (L)
Most S60 (L) some
S40 QWERTY tablets (P)
41. 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?)
42. “
But most people aren't scaling
the site...that's mostly a
developer behaviour.
@tubes
43. Follow-up question:
Does it therefore make sense to create a
breakpoint just because there IS a known
device with that screen size?
44. get to know regional
device and browser market share
45. review your existing
traffic logs
(even if your site isn’t mobile friendly,
your logs will contain mobile traffic)
50. how will this device’s native fonts
compare to desktop emulation?
not accurate if your viewport is
set to device-width
note:
moving
target value
what if it’s not the native browser?
once you get below ~800 px
Opera Mini for iPad has a bit more chrome and
less CSS support ..how will that affect things? all that matters is how it
looks on real devices
52. major
breakpoints
Default Major Breakpoint 1
No media query 321 - 720 px
Major Breakpoint 2
721 px onwards
53. major
breakpoints
background
image removed
to reduce page
weight and layout is primarily
reduce risk on centered
older devices
Default Major Breakpoint 1
No media query 321 - 720 px
‘desktop’ layout
including floats
Major Breakpoint 2
721 px onwards
54. Note: Screenshots taken
on a Mac, proportions, minor
font sizes, and end result
vary more relevantly on
each device.
breakpoints
Minor Breakpoint
@360 px (Nokia touch)
Minor Breakpoint
@480 px (Nokia touch)
Minor Breakpoint
@768 px (iPad)
55. Note: Screenshots taken
on a Mac, proportions, 50% 50%
font sizes, and end result
vary more relevantly on Minor Breakpoint
each device. @360 px (Nokia touch)
background
45% aligned bottom
70% 30%
background aligned top
Minor Breakpoint
50% @480 px (Nokia touch)
55% 45%
custom Nokia font 3em
line background x-position
height adjustment
Minor Breakpoint
30%
@768 px (iPad)
56. alignment (top/bottom) and x-position
adjusted to suit the content (image)
and context (screen size)
image slides
up and down
revealing
more (or less)
of the content
responsive divider implemented using border-image
(degrades gracefully on all but IE)
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.
57. Designing breakpoints also reveals
another important issue.
We cannot presume that screen size maps to browser
(or device) capabilities.
58. PAIN POINT
• good CSS and • strong CSS and
• very basic CSS JavaScript JavaScript support
and JavaScript
• no touch screen
• no touch screen but using proxy
• advanced CSS • early WebKit browser such as
and JavaScript • XHTML MP
Opera Mini
• touch events
• modern WebKit
when queried, these devices will all return a 320 pixel wide viewport
value but each have vastly different browsers
59. Responsive design will only get you half way.
Always pair responsive design with a feature detection
and adaptation strategy.
60. STEP 1 STEP 2
Media queries detect Feature detection
screen size and serve clarifies actual browser
size-appropriate styles capabilities and enables
and behaviours further enhancements
+
appropriately
enhanced look functionality
layout sized
and feel enhancements
graphics
someday we’ll
(even) more
(hopefully) be
appropriate
basic look basic able to detect
graphics or
and feel functionality other useful
media formats
stuff like
(e.g. SVG)
bandwidth
61. TIP
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.
62. 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.
63. TIP
More information about feature detection, will be covered in Bryan’s
Breaking Development presentation: Adaptation
64. Part 3: responsive images
http://www.flickr.com/photos/mrs_logic/4548681436
65. TECHNIQUE
Serving appropriate images to each device
A pragmatic approach using both server and client.
66. most responsive image techniques
focus primarily on the client
design
mobile
first
include images on more advanced browsers (or at orientation
for the simplest change), detect the screen size (using JavaScript),
screen size/ rewrite/adapt the image tag, then load an
browser first appropriate larger image
67. (...but let’s be honest, most responsive sites are still doing THIS)
Read this now: Where are the mobile first responsive designs?
design
“desktop first”
put the burden of screen size
including images
detection, resizing and/or
for the largest
loading of new images on
screen size first
the smallest devices
68. both impose a heavy burden on
constrained devices
depending on the 3. adapt fetching new
technique the initial markup images =
‘larger’ images may extra hp
already have been requests and
downloaded latency
2. spider 4. request
DOM new image
1. detect 5. repaint,
screen reflow as
size needed
69. “
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
70. “ 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
71. heavy lifting
(adaptation, filtering,
STRATEGY server conditional
http://domain.org resource/content
loading)
just-in-time
client
tweaks
72. to determine
device screen to override the
size UA string odd property
device based on
database tacit data existing
to identify device knowledge
and therefore,
screen size
see Bryan’s Adaptation
HEAVY LIFTING presentation for greater
device request detail on this technique
73. to determine
device screen to override the
size UA string odd property
device based on
database tacit data existing
to identify device knowledge
and therefore,
screen size
data application
video
logic
generate cookie
final markup
images
see Bryan’s Adaptation
HEAVY LIFTING presentation for greater
detail on this technique
74. final
markup
cookie
resource profile
bundle
info
device gets the most
appropriate images
on first load
(in most cases)
no additional client-side
processing is required
DELIVERY
75. images
new images are
final only fetched if
markup actually needed
cookie
resource profile
bundle
info
JavaScript
changes assets
on
orientation
change
TWEAKS
@media
changes layout
and other styles
76. uses onResize event
(because onOrientation change
doesn’t work on all devices)
JavaScript also swaps images when
BONUS screen is resized. This enables you to
test adaptation on desktop browsers!
78. TIP
...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)
79. EXAMPLE
Progressively enhanced content.
“One Web” is a great ideal, but sometimes, adding or
removing content based on contextual instructions can
dramatically imrpove the experience.
80. UA string
GOAL
determine device platform
improve browser (e.g. S60 3rd Edition)
update instructions
on browser.nokia.com
device
database
determine device platform determine device model
(in cases where UA string (e.g. Nokia N8-00)
couldn’t provide it) so we can
do this...
choose appropriate device-
specific message (populated with
device model number)
generate enhance existing content with
final markup 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
81. Server-side adaptation pain points
• reliance on cookies
• say good-bye to the intelligent default
• unknown devices
• CDNs anyone?
82. PAIN POINT
Reliance on cookies
• what happens if cookies are disabled?
• what do we do about the EU Cookie Directive?
83. 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?
84. mobile first?
<something or other> first
desktop first?
85. PAIN POINT
What about unknown devices?
• what happens to new devices that are not yet in a
device database or your tacit knowledge database?
86. TIP
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
87. TIP
User agent strings are not evil.
User agent strings can be incredibly useful...so long as you
understand their limitations.
88. operating
version device
system
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 hint at (general)
super useful in capabilities
conjunction with tacit browser
knowledge database version
89. 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?)
90. Part 4: responsive workflows
http://www.flickr.com/photos/jurvetson/5201796697
91. visual consistency
(in a given context) message clarity & thematic consistency
alignment
Desktop
Mobile
key goals
when designing
responsive images
Basic
94. using Adobe
Fireworks
but rapidly switched to
a more context-sensitive
approach
approach
95. 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.
96. PAIN POINT
It’s still not flexible enough...
Design tools enabling the use of variables, conditionals etc.
would be really nice right about now.
97. Part 5: embrace opportunities
http://www.flickr.com/photos/ganesha_isis/4439563089
98. 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.
99. UA string
Goal:
get information out
device
database to more people
determine device
platform
everyone older S40
else devices
change doctype from
no change required HTML5 to XHTML MP
to mobile first
responsive approach serve a lightweight
CSS MP style sheet
generate generate
final markup final markup
103. on 51 different
Nokia devices
(and of course many non-
Nokia devices)
104. oldest smallest
Nokia N70 Nokia 1680
XHTML MP XHTML MP
176 x 208 px 128 x 160 px
2005 2008
3 of these users including the odd
were in the US!
unexpected ones
105. So far...the most popular page
(just behind the home page) is the page
with instructions to update your
browser :-)
106. a few final words...
http://www.flickr.com/photos/dwonderwall/3341419492
107. on being pragmatic
Perform a cost-benefit analysis
for every technique you use.
108. 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.)
109. on being pragmatic
...develop your mobile strategy but
in the meantime...there are
useful things you can do today
110. STEP 1 STEP 2 STEP 3
Review your traffic Test your site on those Develop an action plan
logs and determine devices and determine to address common issues
what mobile devices where the experience such as these:
are accessing your breaks down
site today • key content that is only
accessible on hover
• key controls that are too
small to manipulate on
touch screens
• modal windows that
become unusable on small
screens
• unnecessary http requests
• unnecessarily heavy
graphics and media
repeat...
111. @yiibu
s
contact u
at
hello@yiibu.com thank you
many thanks to the
amazing photographers
on
http://www.flickr.com/creativecommons/by-2.0
http://creativecommons.org/licenses/by/2.0
http://www.flickr.com/photos/tinou/453593446