pragmatic responsive design

responsive design

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

pragmatic

making the best of old and new techniques

http://www.flickr.com/photos/tinou/453593446


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

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


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


mockup

more sketches


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

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 approachOne style sheet with media queries on the inside.

styles.css

@media {(min-width: 480px)

}


}


}


}

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 optionMultiple style sheets with media queries on the inside.

basic.css mobile.css desktop.css

MINOR BREAKPOINTS WITHIN EACH STYLE SHEET


}


}


}

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

=

http://lastdropofink.co.uk/personal/random-stuff/facebook-like-button-84kb-or-1340-seconds/

http://lastdropofink.co.uk/personal/random-stuff/facebook-like-button-84kb-or-1340-seconds/

http://stevesouders.com/p3pc/

http://stevesouders.com/p3pc/

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

http://www.webperformancetoday.com/2011/07/14/fourth-party-calls-third-party-content/

http://www.webperformancetoday.com/2011/07/14/fourth-party-calls-third-party-content/

ConclusionIf 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 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 breakpointsExamplemajor 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 wideand/or unable to

understand further instructions

1024

iPhone (P)many Android (P)many BlackBerryS60 QWERTYMost S60 (L)S40 QWERTY

some tabletsmost NetBooksmany Desktops


iPhone (L*)Android (L*)someSymbiantouch (L)sometablets (L)

some Symbian touch (L)

640 768360

720



720 px to 1024 px320 px to 720 px wide


320

minor breakpointsExample

Symbiantouch (P)





iPad (P)some Android tablets (P)

Minor Breakpoint(@media)

1024




480


content-related tweaks




480 640 768360

Symbiantouch (P)

720





320

240

Minor Breakpoint for small devices

w/media query support



...and so onExample




1024

TVs





someAndroid (P)many S40 (P)most S60 (P)


as you can see, this has the potential to get out of hand...



some tablets (L)

640 768360

Symbiantouch (P)

720



TVs



320

240

Minor Breakpoint for small devices

w/media query support

someAndroid (P)many S40 (P)most S60 (P)





Minor Breakpoints

(@media)

some tablets (L)

1280800


600

some tablets (P)


1366

manylaptops







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

1024x7681280x768

key breakpoints

then determine your

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

examplereal-world major and minor breakpoints

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

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

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 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 styles and behaviours

layout

Feature detectionclarifies actual browser capabilities and enables further enhancements

appropriately sized

graphics

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

http://www.cloudfour.com/where-are-the-mobile-first-responsive-web-designs/

http://www.cloudfour.com/where-are-the-mobile-first-responsive-web-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 hp 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

http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_performanc/


“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



http://www.webperformancetoday.com/2011/04/20/desktop-vs-mobile-web-page-load-speed/

http://www.webperformancetoday.com/2011/04/20/desktop-vs-mobile-web-page-load-speed/

STRATEGY

client

serverhttp://domain.org

heavy lifting (adaptation, filtering, conditional resource/content loading)

just-in-time tweaks

devicedatabase

HEAVY LIFTING

to determine device screen size UA string

tacit data

to override the odd property based on existing knowledgeto identify device

and therefore, screen size

see Bryan’s Adaptation presentation for greater detail on this techniquedevice request

generate !nal markup

devicedatabase

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

cookiepro!leresource

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

cookiepro!leresource

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


devicedatabase

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

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

deviceversion

hint at (general) capabilitiessuper 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 providesa 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 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...

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



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 countriessince then it’s been visited by people in

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


[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



mailto:[email protected]

mailto:[email protected]

pragmatic responsive design

Technology

media screen

media queryis

style cchanges

px unnecessary style

content andcno media

touch touch

breakpointsno mediaminwidth

simplest mobile browser