RESPONSIVE WEB Design

RESPONSIVE WEB

This presentation is

browser.nokia.com

A small campaign site introducing three new web browsers for Nokia devices

THE CASE STUDY

sadly no longer online as

of February 2013 :-(

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

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

many Nokia users on S40 feature

phones still use Opera Mini

v 6.0+

legacy and/or XHTML-MP browsers

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

mockups responsive“live”

mockup

more sketches responsive“live”

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

mockups responsive“live”

mockup

more sketches responsive“live”

mockup

small visual mockups

to discuss specific stylistic issues

“live” responsive mockup to “reality check”

performance and progressive enhancement

etc

ok?

yes no

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

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

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

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

B C

xx px to xxx px

A

B C

B C

xx px to xxx px

A B

breakpoint

style sheet 1 style sheet 2

each style sheet augments the others

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

MAJOR

BREAKPOINTS

IN DOCUMENT

HEAD

a more robust option

Multiple style sheets with media queries on the inside.

}

@media { (min-width: 640px)

}

@media { (min-width: 768px)

}

(typically)

no media queries

@

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:

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

Each 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

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

nothing is here but that’s ok!

some tablets most NetBooks many Desktops

(P) = Portrait (L) = Landscape (L*) = Landscape w/ native viewport adaptation

Major Breakpoint 3 (media query in document head)

adjust line length

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

iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY

1024

Minor Breakpoint (@media)

some tablets most NetBooks many Desktops

minor breakpoints

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

Symbian touch (L)

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

target device:

Symbian touch (P)

iPhone (P) many Android (P) many BlackBerry S60 QWERTY Most S60 (L) S40 QWERTY

1024

Minor Breakpoint (@media)

Minor Breakpoint (@media) Minor

Breakpoint (@media)

480

some tablets most NetBooks many Desktops

change in image alignment

adjust line length

(P) = Portrait (L) = Landscape (L*) = Landscape w/ native viewport adaptation

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!

real-world major and minor breakpointsprimarily content-focussed but with a pragmatic eye on our project’s target devices

‘desktop’ layout including floats

custom Nokia font

background aligned top

background aligned bottom

background x-position adjustment

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)

when queried, these devices will all return a 320 pixel wide viewport

value but each have vastly different browsers

• 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

layout appropriately sized

backgrounds

basic look

and feel functionalitybasic

STEP 1

Feature detection clarifies actual browser capabilities and enables further enhancements

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 2 Media queries detect

screen size and serve

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

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

and yet

fetching new images = extra hp 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 hp requests and latency

constrained devices

6 done! we have the right image

a heavy burden on

often imposing

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

client

server http://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

device database

see Bryan’s Adaptation presentation for greater detail on this technique

device request

device database

HEAVY LIFTING

UA string

tacit data

to override the occasional property based on real-world

or project-specific knowledge

to identify device and therefore, screen size

see Bryan’s Adaptation presentation for greater detail on this technique

device request

to determine necessary

properties such as

screen size

generate final

markup

device database

or project-specific knowledge

to 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

final markup

cookie containing device profile

resource bundle containing references needed for future client-side tweaks

DELIVERY

on orientation change

client-side

on as-needed basis

swaps images/media

on orientation change

JavaScript

changes layout and other styles

new media is only fetched if actually needed

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 final

markup

device database

determine device platform (e.g S60 3rd Edition)

choose appropriate specific message (populated with

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