$30 off During Our Annual Pro Sale. View Details »

Real-Life Responsive Web Design

Real-Life Responsive Web Design

Responsive Web design challenges Web designers to adapt a new mindset to their design processes as well as techniques they are using in design and code. This talk provides an overview of various practical techniques, tips and tricks from real-life projects and discusses performance considerations for lightweight responsive design.

Vitaly Friedman

May 31, 2014
Tweet

More Decks by Vitaly Friedman

Other Decks in Design

Transcript

  1. Real-Life Responsive
    Web Design
    Vitaly Friedman
    31/05/2014 • Sofia, Web Summit

    View Slide

  2. View Slide

  3. View Slide

  4. View Slide

  5. View Slide

  6. View Slide

  7. View Slide

  8. View Slide

  9. View Slide

  10. Vitaly Friedman, editor-in-chief

    and co-founder of SmashingMag

    View Slide

  11. View Slide

  12. A Little Story

    View Slide

  13. View Slide

  14. View Slide

  15. View Slide

  16. View Slide

  17. View Slide

  18. View Slide

  19. View Slide

  20. View Slide

  21. View Slide

  22. View Slide

  23. View Slide

  24. View Slide

  25. View Slide

  26. View Slide

  27. View Slide

  28. View Slide

  29. View Slide

  30. View Slide

  31. View Slide

  32. View Slide

  33. View Slide

  34. View Slide

  35. View Slide

  36. View Slide

  37. View Slide

  38. View Slide

  39. View Slide

  40. View Slide

  41. View Slide

  42. View Slide

  43. View Slide

  44. Design Systems

    View Slide

  45. View Slide

  46. “Designing for the Web is like
    visualizing a tesseract. We build
    experiences by manipulating their
    shadows.
    — Tim Brown

    View Slide

  47. View Slide

  48. Responsive Design is an appropriate
    tool for “multi-dimensional” designs.

    View Slide

  49. It’s a new mindset that requires us to
    rethink and extend our practices.

    View Slide

  50. View Slide

  51. View Slide

  52. “If you’re used to designing fixed-
    width layouts, it’s going to be really,
    really hard to get your head around
    designing and building in a fluid
    way… at first.

    — Elliot Jay Stocks

    http://elliotjaystocks.com/blog/responsive-web-design-the-war-has-not-yet-been-won/

    View Slide

  53. “...Once you overcome that initial
    struggle of adapting to a new
    process, designing and building
    responsive sites needn’t take any
    longer, or cost any more money.

    — Elliot Jay Stocks

    http://elliotjaystocks.com/blog/responsive-web-design-the-war-has-not-yet-been-won/

    View Slide

  54. Responsive Considerations
    • Components


    Flexible grid

    Typography

    Navigation

    Accessible form controls

    Carousels

    Tabbed navigation

    Responsive tables

    Accordions

    Media lists

    Drop-downs

    Pagination

    Data tables

    Buttons

    Icon fonts 

    • Strategy

    Responsive images

    Responsive typography

    Accessibility architecture

    Legacy browser support

    i18n/l10n tolerance

    Performance budget

    Interaction/Animations

    Responsive advertising 


    View Slide

  55. • Strategy

    Responsive images

    Responsive typography

    Accessibility architecture

    Legacy browser support

    i18n/l10n tolerance

    Performance budget

    Interaction/Animations

    Responsive advertising 

    • Layouts

    Homepage layout

    Subpage layout

    Article index layout

    Article layout

    Product index layout

    Product detail layout

    Sign up flow

    Checkout flow
    • Components


    Flexible grid

    Typography

    Navigation

    Accessible form controls

    Carousels

    Tabbed navigation

    Responsive tables

    Accordions

    Media lists

    Drop-downs

    Pagination

    Data tables

    Buttons

    Icon fonts 


    View Slide

  56. View Slide

  57. View Slide

  58. View Slide

  59. View Slide

  60. View Slide

  61. View Slide

  62. View Slide

  63. View Slide

  64. View Slide

  65. View Slide

  66. View Slide

  67. View Slide

  68. View Slide

  69. View Slide

  70. View Slide

  71. View Slide

  72. Design Workflow

    View Slide

  73. “The design process is weird and
    complicated because it involves
    people and organisations, which
    often are weird and complicated.

    — Mark Boulton

    View Slide

  74. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  75. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  76. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  77. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  78. View Slide

  79. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  80. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  81. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

    View Slide

  82. View Slide

  83. “Build smaller, tactical teams that
    are capable of executing multiple
    rounds of planning, design, and
    code quickly and independently.

    — Trent Walton

    View Slide

  84. View Slide

  85. Responsive Workflow
    • Instead of dividing teams into skill sets, build
    complementary teams, focused on small tasks.
    1. A project starts with building “all-round”-teams;
    2. Think mobile first = commitment to the content,
    3. Produce style tiles, first modules in Photoshop,
    4. Build prototypes in the browser asap,
    5. Atoms first; modules, organisms later,
    6. Collaboration as “in-browser design pairing”.
    7. Clients sign off new deliverables:

    View Slide

  86. Responsive Workflow
    • Style guides and prototypes,
    • Core content/functionality priority lists,
    • Performance and UX budgets,
    • Legacy browser support,
    • Responsive images strategy.
    7. Clients sign off new deliverables:
    3. Produce style tiles, first modules in Photoshop,
    4. Build prototypes in the browser asap,
    5. Atoms first; modules, organisms later,
    6. Collaboration as “in-browser design pairing”.

    View Slide

  87. View Slide

  88. View Slide

  89. Performance Strategy

    View Slide

  90. “Who really wants to wait while
    they are waiting?

    — Mike Krieger

    View Slide

  91. View Slide

  92. View Slide

  93. • T-Mobile roaming charges for loading the

    full front page of Vogue.co.uk, in Moscow: €93,13
    Tim Kadlec’s performance experiment @ SmashingConf 2013

    View Slide

  94. View Slide

  95. Performance Budget
    • Idea: always include performance in project
    documents—e.g. proposals and design briefs.
    • Set a “budget” on your site and don’t allow the
    site to exceed it (number of requests, page size).
    • 550–750 Kb, at most 20 HTTP-requests,
    • start rendering < 1.1s on DSL 16000 from Sofia,
    • start rendering < 2s on 3G from Sofia,
    • important content in the first 14 Kb.

    View Slide

  96. Performance Budget
    • Idea: always include performance in project
    documents—e.g. proposals and design briefs.
    • Set a “budget” on your site and don’t allow the
    site to exceed it (number of requests, page size).
    • Don’t add the new feature.
    • Optimize the new feature to fit the budget or
    • Remove an existing feature or
    • When adding a feature, consider 3 options:
    • 550–750 Kb, at most 20 HTTP-requests,
    • start rendering < 1.1s on DSL 16000 from Sofia,

    View Slide

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

    View Slide

  98. Performance Strategies
    • Average page load (onLoad) doesn’t say much
    about the quality of performance. Metrics:
    • Visual comparison (against competitors)

    • Interface response times (<=100ms)
    • WebPageSpeed’s Speed Index (“above-the-fold”)
    • Task-oriented performance, e.g. at what point is the
    form functional? When can the tab interface be used?
    • Task completion metrics (UX perspective)
    • Critical-path view in the first 14 Kb
    • Speed Index <= 1000

    View Slide

  99. View Slide

  100. 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.
    Andy Hume’s “Real-Life Responsive Web Design” @ SmashingConf 2013

    View Slide

  101. View Slide

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

    View Slide

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

    View Slide

  104. “We don’t need to render the entire
    page in one second; we just need to
    render the “above the fold” content.

    — Ilya Grigorik

    “Optimizing The Critical Path”, http://www.lukew.com/ff/entry.asp?1756

    View Slide

  105. The Guardian’s Modular Load
    • Consider at least three types of page 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.

    View Slide

  106. View Slide

  107. View Slide

  108. View Slide

  109. View Slide

  110. View Slide

  111. View Slide

  112. The Guardian Redesign
    • Time to first byte: request to start of a
    response, normally HTML, includes latency.
    • DomContentReady: content begins to display,
    but not necessarily useful content.
    • Load: full page loaded, incl. scripts and images.
    All extra scripts and assets load after Load.

    View Slide

  113. The Guardian’s Modular Load
    • Load JS into a browser asynchronously.

    While JS is being downloaded, browser still

    can parse the document and show content.
    • HTML/JS (for modern browsers):

    @if(isModernBrowser) {


    }

    View Slide

  114. View Slide

  115. BBC’s isModernBrowser( )
    • 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

    }


    View Slide

  116. BBC’s isModernBrowser( )
    • 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.

    View Slide

  117. View Slide

  118. View Slide

  119. “The key metrics was the page load
    time, or more specifically the time
    to page render until the “first”
    news appear on the users’ screen
    (specifically, above the fold.)

    — Andy Hume

    “Real-Life Responsive Redesign”, SmashingConf 2013

    View Slide

  120. • A median start render time for an uncached page:

    0.798 seconds (iPhone 4, 3G, 1.6Mps, 300ms RTT).
    • Guardian users need to successfully complete

    one HTTP-request to read the news

    View Slide

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

    View Slide

  122. View Slide

  123. View Slide

  124. “Progressive enhancement is often
    considered in terms of technology
    support—what happens to users
    who don’t have JavaScript. But it’s
    at least as important to consider it
    in terms of technology failure…

    — Andy Hume

    “Real-Life Responsive Redesign”, SmashingConf 2013

    View Slide

  125. “…It’s the best way to make our
    sites resilient to failure because a
    mobile user went into a tunnel, or
    a corporate firewall decided to
    strip all JS, or the mobile operator
    decided to compress JavaScript
    going through its network.

    — Andy Hume

    “Real-Life Responsive Redesign”, SmashingConf 2013

    View Slide

  126. “There is no difference for the user
    between a site being down and a
    site being inaccessible due to the
    lack of JavaScript because of the
    network issues.

    — Andy Hume

    “Real-Life Responsive Redesign”, SmashingConf 2013

    View Slide

  127. View Slide

  128. View Slide

  129. View Slide

  130. View Slide

  131. View Slide

  132. View Slide

  133. HTTP/1.1
    • HTTP was designed for connections and
    bandwidth much different from today.
    • 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.

    View Slide

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

    View Slide

  135. SPDY / HTTP/2.0
    • SPDY, the core of HTTP/2.0, promises speed
    improvement and decreased network latency.
    • 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.

    View Slide

  136. View Slide

  137. • Requires server-side and client-side implementations.
    • Available for Apache 2.2 (mod_spdy),

    Nginx (ngx_http_spdy_module).

    View Slide

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

    View Slide

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

    View Slide

  140. Gmail’s Lazy Loading
    • Idea: let browsers download all of the JS right
    away, but evaluate it “on demand”, i.e. when
    users need a particular feature.
    • Much of the downloaded JS is commented out,
    and when needed uncommented and eval-ed.
    • Gmail’s case:

    200 Kb of JS -> 2600 ms page load

    200 Kb of JS (lazy loaded) -> 240 ms page load

    View Slide

  141. Gmail’s Lazy Loading
    • 
<br/>// Make sure you strip out (or replace) comment<br/>blocks in your JavaScript first.
<br/>/* JavaScript of lazy module */
<br/>


    
<br/>function lazyLoad() {
<br/>var lazyElement = document.getElementById('lazy');<br/>var lazyElementBody = lazyElement.innerHTML;
<br/>var jsCode = stripOutCommentBlock(lazyElementBody);<br/>eval(jsCode); }
<br/>


    Lazy Load

    View Slide

  142. View Slide

  143. View Slide

  144. The Two-Click Social Widget
    • Load social widgets only when user explicitly
    chooses to take that action to share content.
    • Idea: load small social icons by default, and
    load the FB, Twitter and G+ widgets on click.
    • Cuts down on bandwidth and on latency.

    (FB button alone weighs 120 Kb + 4 requests).

    View Slide

  145. View Slide

  146. View Slide

  147. View Slide

  148. View Slide

  149. View Slide

  150. View Slide

  151. View Slide

  152. YouTube Player On Demand
    • YouTube video player will be downloaded
    even if the visitor doesn’t watch a video.
    • Idea: display a thumbnail of a YouTube video
    with a “play” icon overlay. Load player on click.
    • Cuts down on bandwidth and on latency.

    (YouTube player weights 390 Kb + 12 requests).

    View Slide

  153. View Slide

  154. View Slide

  155. Conclusion

    View Slide

  156. View Slide

  157. View Slide

  158. www.smashingbook.com

    View Slide

  159. www.the-mobile-book.com

    View Slide

  160. Thank you.

    View Slide

  161. Image credits
    • Front cover: Geometric Wallpapers

    by Simon C Page (http://simoncpage.co.uk/
    blog/2012/03/ipad-hd-retina-wallpaper/)
    • Homer Simpsons: http://smashed.by/homer

    • Sections illustrations: “bisous les copains”,
    by Guillaume Kurkdjian (http://
    bisouslescopains.tumblr.com/)

    • Hypercube: http://en.academic.ru, Wikipedia


    View Slide

  162. View Slide