Pragmatic responsive design

109
responsive design http://www.flickr.com/photos/dwonderwall/3341419492 pragmatic making the best of old and new techniques

description

Presented by Stephanie Rieger in Nashville for Breaking Development 2011

Transcript of 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 STUDYsadly no longer online as of February 2013 :-(

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/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

TECHNIQUE

Use major and minor breakpoints

Create media queries inside of media queries.

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

cause multiple http requests?

don’t multiple style sheets

(which will affect performance)

Yes!...but (as we will see) we have bigger issues...

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

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)

choosing breakpoints

TECHNIQUE

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

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

and yet...

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

TWEAKS

on orientation

change

client-side

on as-needed basis

@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)

Demo...

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?

mobile first?

desktop first?

<something-or-other> just-in-time

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

largest

larger

small

message clarity & thematic consistency across contexts

a “normal” workflow

we began with

in one context

each graphic designed

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

So how did it go?

So how did it go?Within five days of our (soft) launch...

133 countriesthe site had been visited by people from

Nokia devices

on 51 different

(and of course many non-Nokia devices)

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...

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 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