Real-Life Responsive Web Design

Vitaly Friedman13/11/2014 • Rome, Italy

Vitaly Friedman, editor-in-chiefand co-founder of SmashingMag

Design Systems

Patty Toland, FilamentGroup, “Design Consistency for RWD”, https://t.co/Tb0q1gMwQS

Responsive Considerations

• Components

Flexible gridTypographyNavigationAccessible form controlsCarouselsTabbed navigationResponsive tablesAccordionsMedia lists Drop-downs PaginationData tablesButtons Icon fonts

• Strategy

Responsive imagesResponsive typographyAccessibility architectureLegacy browser supporti18n/l10n tolerancePerformance budgetInteraction/AnimationsResponsive advertising

• Strategy

Responsive imagesResponsive typographyAccessibility architectureLegacy browser supporti18n/l10n tolerancePerformance budgetInteraction/AnimationsResponsive advertising

• Layouts

Homepage layoutSubpage layoutArticle index layoutArticle layoutProduct index layoutProduct detail layoutSign up flowCheckout flow

• Components

Flexible gridTypographyNavigationAccessible form controlsCarouselsTabbed navigationResponsive tablesAccordionsMedia lists Drop-downs PaginationData tables Buttons Icon fonts

Smart URL Design

http://global.burton.com/on/demandware.store/Sites-Burton_GLOBAL-Site/default/Home-Show/index.html

What fascinates me are a few things: how something that got its roots in late 19th century over a course of the century turned into something as established as Teletext. What does it

Progressive Reduction

“ Your proficiency in a product will decay over time without usage. As such, this proficiency is reflected in experience decays over time. These decays should be avoided at all costs.

— Allan Grinshtein

Progressive Reduction

• Usability is a moving target; users getsmarter at a product as they keep using it.

• An interface should adapt and enable usersto become more efficient at using it.

• Idea: change the UI as the user moves through different stages of proficiency.

Progressive Reduction

• Every UI regresses without usage. For major features, track and observe their usage.

• Create a proficiency profile for every user;as a feature is used more, start reducing the “hand-holding” in a series of levels.

Progressive Reduction

• Assign a proficiency level to each feature and design its variations for each level.

• If a user doesn’t use a feature for a long time, UI regresses back to level 1.

• If a user uses a feature more, UI keeps increasing levels to the “advanced” mode.

Designing for Extremes

“ We have clients come to us and say, “We know our average customer. She’s female, 34 years old, with 2.3 kids…” But what we really need to do to design well, is to look at the extremes…

— Dan Formosa, “Smart Design”

“ ...the weakest, or the person with arthritis, or the athlete, or the strongest or the fastest person. Because if we really understand what the extremes are, the middle will take care of itself.

— Dan Formosa, “Smart Design”

Designing for Extremes

• Average user is an artificial, static representation of users that don’t exist.

• Real users change constantly, reaching different positions, roles and contexts.

• Idea: optimize for edge cases first, then converge towards more common cases.

Skeleton Screens

Skeleton Screens

• Good feedback focuses on the progress;keeps updating current state to ease anxiety.

• Blank screens are user experience gaps that disrupt user experience. Progress bars focus on the waiting; focus on the progress instead.

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Idea: minimize gaps to reduce friction with “seamless” transitionsand skeleton screens.

Performance Strategy

“ There is no difference for the user between a site being down and a site being inaccessible due to loading issues caused by blocking resources or slow networks.

— Andy Hume“Real-Life Responsive Redesign”, SmashingConf 2013

• T-Mobile roaming charges for loading the full front page of Vogue.co.uk, in Moscow: €93,13

The Guardian Redesign (2013)

• Project goals focused on mobile experience:

• Tackle dropping print circulation with mobile,• Replace the slow, rigid mobile/desktop sites,

• Solution: a mobile-first “stealth” redesign with a strong focus on progressive enhancement.

• First focus on “mobile” experience, • Long term: new RWD client-side architecture,• Ultimate goal: one code base, one responsive site.

“ “Core HTML content first” with “Core CSS styles first” is a simple corollary of the good ol’ progressive enhancement.

— Andy Hume“Real-Life Responsive Redesign”, SmashingConf 2013

The Guardian Redesign

• Priority lists for content and styles to define “core”:

• Core content doesn’t rely on JavaScript,• Only one main feature image considered “core”,• No Ajax support for ratings, comments and live scores,

• “Cutting the mustard” to “buckle” browsers,• Web fonts aren’t loaded by default (prevent FOUT).

The Guardian’s Modular Load

• Consider at least three types of page content:

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Core content(essential HTML+CSS, usable non-JS enhanced experience);

• Enhancement(JS, Geolocation, touch, enhanced CSS, Web fonts, widgets);

• Leftovers(analytics, advertising, third-party content).

• Idea: load Core content first, then Enhancement on DOMContentReady, then Leftovers on Load.

The Guardian’s Modular Load

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Load JS into a browser asynchronously.While JS is being downloaded, browser stillcan parse the document and show content.

• HTML/JS (for modern browsers):@if(isModernBrowser) { <script src="enhanced.js" async defer></script> }

BBC’s isModernBrowser( )

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• We can use server-side device detection using UA strings with DeviceAtlas, WURFL etc.

• We can use client-side feature detection to split browsers into groups “HTML4” / “HTML5”.

• JS:if ( 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window ) { // HTML5 browser detected; load the JS app}

BBC’s isModernBrowser( )

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• JS:if ( 'querySelector' in document && 'localStorage' in window && 'addEventListener' in window ) { // HTML5 browser detected; load the JS app}

• HTML5 Browsers:IE9+, FF 3.5+, Opera 9+,Safari 4+, Chrome 1+, iOS1+,Android phone and tablets 2.1+, Blackberry OS6+, Win 7.5+,Mobile Firefox, Opera Mobile

• HTML4 Browsers:IE8-, Blackberry OS5-,Nokia S60 v6-, Nokia S40,Symbian, Windows 7 Phone (pre-Mango), a plethora of legacy devices.

• A median start render time for an uncached page: 0.798 seconds (iPhone 4, 3G, 1.6Mps, 300ms RTT).

• Guardian users need to successfully complete1 HTTP-request to start reading the news.

• Median time for an uncached page to start displaying: 0.727 seconds (stable networks).

• With enhanced JS loaded, front page has 35 images on “desktop”, 67 requests, 657 Kb.

SmashingMag’s Refactoring

• Drawbacks prompted a focus on performance:

• Independent sections with separate WP-installs,• Accessing content was difficult on slow connections,

• Question: (once we clean up the front-end), how fast can we be, rather than how fast should we be?

• Decoupling JS dependencies (also with ads), • Dealing with annoying Web fonts loading.• Ultimate goal: one code base, one responsive site.

“ So how fast ist fast enough? A Speed Index of under 1000. And for professionals that get there, they should shoot for delivering the critical-path view (above the fold) in the first 14Kb of the page.

— Paul Irish

Performance Strategies

• Average page load (onLoad) doesn’t say much about the quality of performance. Metrics:

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Visual comparison (against competitors)• Interface response times (<=100ms)• Start render time within 1s on a suboptimal 3G

(“above-the-fold” optimization),• Monitor perf. with a private instance of WebPageTest,• Run code against performant budget (Grunt-task).

SmashingMag’s Modular Load

• Consider three types of page content:

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Core content(essential HTML+CSS, usable non-JS enhanced experience);

• Enhancement(JS, syntax highlighter, full CSS, Web fonts, comments);

• Leftovers(analytics, advertising, Gravatar images).

• Idea: load Core content first, then Enhancement on DOMContentReady, then Leftovers on Load.

SmashingMag’s Optimization

• Minor optimizations based on a simple principle: optimize content, defer the rest.

• Load critical CSS inline and full CSS on load,• Avoid JavaScript libraries ( jQuery → JavaScript),• Store Web fonts in localStorage + cookies,• Defer advertising, tracking and all non-critical CSS/JS,• Replaced Respond.js with IE8 stylesheet (fixed-width).• Optimize the critical rendering path for content delivery.

An Ongoing Battle

• Minor optimizations prompted us to review and adjust our editorial workflow:

• Using srcset and sizes for images in articles,• Using grunt-perfbudget to track performance,• Measuring changes in traffic and ad impressions,• Reviewing articles for performance before publishing,• PageSpeed >= 98 both on mobile and desktop as a goal.

• Next: WebViews issues, “jumps” to comments, defer Gravatars, move to new servers, <picture>.

HTTP/1.1

• HTTP was designed for connections and bandwidth much different from today.

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• Single request per connection,• Browsers can use max. 6 connections per domain, • Exclusively client-initiated requests,• Uncompressed request and response headers,• Redundant headers,• Optional data compression,• HTTP is slow, HTTPS is even slower.

Delivering The Goods, Paul Irish, https://www.youtube.com/watch?v=R8W_6xWphtw

SPDY / HTTP/2.0

• SPDY, the core of HTTP/2.0, promises speed improvement and decreased network latency.

• JavaScript:var size = window.getComputedStyle(document.body,':after').get PropertyValue('content'); if (size == 'desktop') { // Load some more content. }

• 64% reductions in page load times,• 23% mean page load time improvement on mobile,• Unlimited number of parallel requests per connection,• Quicker slow start and better compression, • Developers can prioritize resources,• Always requires SSL/TLS for security,

• Extension of HTTP/1.1; as such, falls back to HTTP/1.1.

• Requires server-side and client-side implementations.

• Available for Apache 2.2 (mod_spdy),Nginx (ngx_http_spdy_module).

• Requires server-side and client-side implementations.

• Available for IE 11+ (Win 8.1), Chrome 4+, Firefox 13+, Opera 12.1+, Amazon Sink, Android, not Safari.

• Used by Google (Gmail), WordPress.com, CloudFlare, Facebook, Twitter. Different browsers support different versions of SPDY.

“ SmashingMag is the only site I can read on an EDGE connection when commuting in São Paulo, every day. It makes me think why other sites aren’t optimizing for slow connections, too.

— a reader from Brazil

Thank you.