Pragmatic responsive design
-
Upload
yiibu -
Category
Technology
-
view
209.607 -
download
1
description
Transcript of Pragmatic responsive design
responsive design
http://www.flickr.com/photos/dwonderwall/3341419492
pragmatic
making the best of old and new techniques
browser.nokia.com A small campaign site introducing three new web browsers for Nokia devices.
THE CASE STUDYsadly no longer online as of February 2013 :-(
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/MeeGoTouch (+ many w/ keyboards)
2008-presentWebKit browser11 devices
Series 60Touch and non-touch
2006-present (S60 3rd FP 1/2)WebKit browser45 devices
Series 40Touch and non-touch
2008-present (~S40 6th Edition)WebKit browser orNokia proxy browser23 devices
new browser being promoted
+ all the usual suspects
v. 7+
mobile
desktop
many Nokia users on S40 feature phones still use Opera Mini
v 6.0+
legacy and/or XHTML-MP browsers
Internet Browser
Obigo
Windows Mobile
UC Web
< v 5.0
no support was 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” responsivemockup 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” responsivemockup 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 native 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 conditions 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 counterproductivebehaviours 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 tested on will have its own quirks.)
• Creating elaborate reference lists of screen sizes,pixel densities in the belief that with enough datayou 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 fact that it may be mobile doesn’t really maer...
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 not defined through media queries
begin with a lightweight default
A
B
Ckey word here is ‘de"ned’...see slide 26
Embrace the cascade
Don’t merely swap style sheets...let it cascade.
This results in smaller subsequent style sheets, less duplication in declarations and is more efficient for the browser to parse (as it’s only dealing with deltas).
TECHNIQUE
each style sheet augments the others
augment original style sheet with (only) the style changes that are needed to enhance the layout
A BC
xx px to xxx px
breakpoint breakpoint
A
BC
< xx px wide(or unable to
understand further instructions)
style sheet 1
A BC
xx px to xxx px
A
B
C
>xxx px wide
breakpoint breakpoint
A
BC
< 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
Why we call them major and minor breakpoints
major layout changes
content or component-specific
tweaks
a common approachOne 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)
}
1 css "le = 1 hp request, but includes unnecessary style data that all devices end up downloading
MAJOR BREAKPOINTS IN DOCUMENT HEAD
a more robust optionMultiple style sheets with media queries on the inside.
basic.css enhanced.css enhanced+.css
MINOR BREAKPOINTS WITHIN EACH STYLE SHEET
@media {(min-width: 480px)
}
@media {(min-width: 640px)
}
@media {(min-width: 768px)
}
(typically) no media queries
@320px
@720px
but feel free to include some if you feel they can enhance the experience and are sure (!) they will graciously degrade on older browsers
@media screen and (min-width: 640px) { section ul li {
width: 20%; }
}
<link rel="stylesheet" type="text/css" href="stylesheets/basis.css" media="screen, handheld" />
<link rel="stylesheet" type="text/css" href="stylesheets/enhanced+.css" media="only screen and (min-width: 720px)" />
<link rel="stylesheet" type="text/css" href="stylesheets/enhanced.css" media="only screen and (min-width: 320px)" />
MAJOR BREAKPOINTS IN DOCUMENT HEAD
MINOR BREAKPOINTS AS NEEDED WITHIN EACH STYLE SHEET
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).
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
ConclusionEach http request should add value!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)
DisclaimerThere is no “perfect set” of breakpoints.
Set your breakpoints based on the needs of your layout and (the legibility, weight and nature of) your content.
Cross-check these choices on your key devices.
(...80% of traffic in your analytics will often come from 20% of devices...seems a shame not to ensure the site looks and works especially well on these devices).
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 breakpointsmajor layout changes
320 720
Major Breakpoint 2(media query in document head)
nothing is here...but that’s ok!
< 320 px wideand/or unable to
understand further instructions
1024
iPhone (P)many Android (P)many BlackBerryS60 QWERTYMost S60 (L)S40 QWERTY
some tabletsmost NetBooksmany Desktops
(P) = Portrait(L) = Landscape(L*) = Landscape w/ native viewport adaptation
Major Breakpoint 3(media query in document head)
adjust line length
645 732
720
Major Breakpoint 1(media query in document head)
Major Breakpoint 2(media query in document head)
720 px to 1024 px320 px to 720 px wide
nothing is here...but that’s ok!
320
iPhone (P)many Android (P)many BlackBerryS60 QWERTYMost S60 (L)S40 QWERTY
< 320 px wideand/or unable to
understand further instructions
change in image alignment
Minor Breakpoint(@media)
1024
Minor Breakpoint(@media)
some tabletsmost NetBooksmany Desktops
minor breakpointscontent-related tweaks
(P) = Portrait(L) = Landscape(L*) = Landscape w/ native viewport adaptation
TVs
body copy is too large
Minor Breakpoint(@media)
Major Breakpoint 3(media query in document head)
target device:Symbiantouch (L)
645 732360
720
Major Breakpoint 1(media query in document head)
Major Breakpoint 2(media query in document head)
720 px to 1024 px320 px to 720 px wide
nothing is here...but that’s ok!
320target device: Symbiantouch (P)
iPhone (P)many Android (P)many BlackBerryS60 QWERTYMost S60 (L)S40 QWERTY
< 320 px wideand/or unable to
understand further instructions
Minor Breakpoint(@media)
1024
Minor Breakpoint(@media)
Minor Breakpoint(@media)
Minor Breakpoint(@media)
480
some tabletsmost NetBooksmany Desktops
change in image alignment
adjust line length
(P) = Portrait(L) = Landscape(L*) = Landscape w/ native viewport adaptation
minor breakpointskey-device-related tweaks
Minor Breakpoint for small devices w/media query
support
someAndroid (P)many S40 (P)most S60 (P)
OMG...”
http://www.flickr.com/photos/richardmoross/1413692087
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?)
Follow-up question:Does it therefore make sense to create a breakpoint just because there IS a known device with that screen size?
Answer: Yes, and yes...
• Be pragmatic. If content looks ‘wrong’ at a given screen size on the desktop, fix it (there’s probably a device out there that will match those conditions).
• Anticipate problems. Leave breathing space and don’t micro-manage the layout.
• If the layout keeps breaking during testing, that’s a sign that your tolerance for diversity may be too low...consider changing the design!
examplereal-world major and minor breakpoints
primarily content-focussed but with a pragmatic eye on our project’s target devices
Major Breakpoint 2721 px onwards
Major Breakpoint 1321 - 720 px
DefaultNo media query
major
breakpoints
Major Breakpoint 2721 px onwards
Major Breakpoint 1321 - 720 px
DefaultNo media query
layout is primarily centered and now includes background image
‘desktop’ layout including floats
background image omitted to reduce page weight and reduce risk on older devices
major
breakpoints
Minor Breakpoint@360 px (cross-checked for Nokia touch)
Minor Breakpoint@480 px (cross-checked for Nokia touch)
Minor Breakpoint@768 px (cross-checked for iPad)
Note: Screenshots taken on a Mac for demonstration purposes.
minor
breakpoints
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
Minor Breakpoint@360 px (cross-checked for Nokia touch)
Minor Breakpoint@480 px (cross-checked for Nokia touch)
Minor Breakpoint@768 px (cross-checked for iPad)
Note: Screenshots taken on a Mac for demonstration purposes.
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 environmentse.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)
...but rememberMedia queries are wonderfully versatile but screen size is only one factor to consider.
Screen size rarely aligns with 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 browser 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 layouts and basic behaviours
layoutappropriately
sized backgrounds
basic lookand feel
basic functionality
STEP 1
layout
Feature detectionclarifies actual browser capabilities and enables further enhancements
enhanced look and feel
basic lookand 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 2
Media queries detect screen size and serve
size-appropriate layouts and basic behaviours
STEP 1
appropriately sized
backgrounds
The more (accurate) information you can detect, the more intelligently you can adapt.
Client-side feature detection is only one of the toolsyou can use.
Others include device databases, user agent strings and your own (domain and region-specific) tacit knowledge.
TIP
Why should we need our own tacit knowledge when we can detect browser capabilities using JavaScript or libraries such as Modernizr?
Because ‘support’ is rarely a binary thing.
Also....some browsers lie.
TIP
TIP
More information about feature detection, can be found in Bryan’s Breaking Development presentation: Adaptation
Part 3: responsive content & media
http://www.flickr.com/photos/mrs_logic/4548681436
“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
fetching new images =extra hp requests and latency
1. detect screen size
most responsive image techniques
are primarily client-side
3. done! we have the right image
2. request new image
1. detect screen size
2. spider the DOM
3. adapt markup
4. request new image
5. repaint, reflow as needed
fetching new images =extra hp requests and latency
constrained devices
6. done! we have the right image
a heavy burden on
often imposing
TECHNIQUE
Serving more appropriate* images to constrained devices
A pragmatic approach using both server and client.
*the nature of an “appropriate image” is complicated. To better understand the problem, and what standards bodies are hoping to do to solve it, we recommend reading A framework for discussing responsive images by Jason Grigsby
STRATEGY
client
serverhttp://domain.org
determine basic device capabilities then choose/adapt and conditionally load most appropriate mark-up...
server-side pre-processing delivers the most appropriate markup, images and scripts on initial load
clarifies device capabilities (using feature detection) and adapts on the fly as needed (e.g. on reorientation, new data, dynamic components)
just-in-time tweaks
delivery
heavy-lifting
devicedatabase
HEAVY LIFTING
to determine necessary properties such as screen size UA string
to identify device and therefore,
screen size
see Bryan’s Adaptation presentation for greater detail on this techniquedevice request
devicedatabase
HEAVY LIFTING
UA string
tacit data
to override the occasional property based on real-world or project-speci"c knowledgeto identify device
and therefore, screen size
see Bryan’s Adaptation presentation for greater detail on this techniquedevice request
to determine necessary properties such as screen size
generate "nal markup
devicedatabase
cookie
HEAVY LIFTING
UA string
tacit data
see Bryan’s Adaptation presentation for greater detail on this technique
application logic
data
images
video
to override the occasional property based on real-world or project-speci"c knowledgeto identify device
and therefore, screen size
to determine necessary properties such as screen size
device gets the most appropriate images
on first load
(in most cases)no additional client-side
processing is required
"nal markup
cookie containing device pro"leresource bundle
containing references needed for future client-side tweaks
DELIVERY
@media
swaps images/media
on orientation
change
JavaScript
changes layout and other styles
new media is only fetched if
actually needed
images etc.
TWEAKS
client-side
on as-needed basis
updated device pro"le cookie sent back to server
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)
This technique isn’t just good for images...you can use it to implement other useful (progressive) enhancements.
These include specifying:• more appropriate image formats (e.g. SVG)• mobile-friendly alternates for 3rd party widgets• alternative functional components (e.g. form elements)• alternate content representations (e.g. visual
alternatives to complex tabular data)
TIP
A simple content enhancement
“One Web” is a great ideal, but sometimes, adding or removing content based on device/user context can dramatically improve the experience.
EXAMPLE
Scenario: Provide each user with customized download instructions based on detection of their browser version.
Benefits: • increases likelihood of a download• reduces the amount of stuff users need to read/
understand
generate "nal markup
devicedatabase
UA string
determine device model(e.g. Nokia N8-00)
determine device platform(in cases where UA string
doesn’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
so we can do this...
Note: Content was merely enhanced (not swapped entirely) as we expected certain people would visit the site from one device (e.g. a PC) but need to review download instructions for another
Server-side adaptation pain points
• reliance on cookies• reliance on external data• say good-bye to the intelligent default• CDNs anyone?
PAIN POINT
Reliance on cookies
• what happens if cookies are disabled?• what do we do about the EU Cookie Directive?
What about unknown devices?
• what happens to new devices that are not yet in a device database or your collection of tacit knowledge? (...the reality is, no method is perfect, combining server-side and client-side detection helps plug the gaps)
PAIN POINT
an 80/20 approach will get you quite far
• on many site, 80% of traffic seems to comefrom about 20% of devices
• of the other 20%, most are known devices• regularly reviewing your logs can help catch
whatever is left
TIP - don’t panic
PAIN POINT
Say goodbye to the ‘intelligent default’• how do we create intelligent default content or
behaviours when there is no longer a ‘normal/average/typical’ screen size or even a ‘typical’ device?
PAIN POINT
CDNs anyone?
• CDNs currently couldn’t care less about changes in device context. A URL is presumed to represent a single, cacheable resource.
• Will aggressive caching turn into a problem?
(Would we even have created CDNs, or have designed them quite differently if content had been variable, based on device context from the very start?)
http://www.flickr.com/photos/jurvetson/5201796697
Part 4: design workflows
Some key goals when designing multi-context image-sets
• visual consistency in the given context• message clarity & thematic consistency across contexts• appropriate image weight for each context
visual consistency (in the given context)
alignment of graphical elements maers here
not so much here
approach
Adobe Fireworks enables you to design and export different sizes from one single artboard
approach
but rapidly switched to
a more context-sensitive
Benefits
Designing graphics together providesa more global and contextual view.
• Helped eliminate alignment errors, continuity issues etc.
• Helped maintain thematic consistency. Images don’t have to be identical but the overall message shouldnot 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...
Graphical 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.
devicedatabase
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
User agent strings are not evil.
User agent strings can be incredibly useful so long as you understand their limitations and use them to enhance rather than exclude.
Reminder
including the odd
Nokia N70XHTML MP
176 x 208 px2005
Nokia 1680XHTML MP
128 x 160 px2008
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...
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 planto address common issues such as these:
• 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
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
[email protected] 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 usat