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.

B3d6434763caa0ef5dc4b792662c49f7?s=128

Vitaly Friedman

May 31, 2014
Tweet

Transcript

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

    Summit
  2. None
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. Vitaly Friedman, editor-in-chief
 and co-founder of SmashingMag

  11. None
  12. A Little Story

  13. None
  14. None
  15. None
  16. None
  17. None
  18. None
  19. None
  20. None
  21. None
  22. None
  23. None
  24. None
  25. None
  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. None
  33. None
  34. None
  35. None
  36. None
  37. None
  38. None
  39. None
  40. None
  41. None
  42. None
  43. None
  44. Design Systems

  45. None
  46. “Designing for the Web is like visualizing a tesseract. We

    build experiences by manipulating their shadows. — Tim Brown
  47. None
  48. Responsive Design is an appropriate tool for “multi-dimensional” designs.

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

    extend our practices.
  50. None
  51. None
  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/
  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/
  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 

  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 

  56. None
  57. None
  58. None
  59. None
  60. None
  61. None
  62. None
  63. None
  64. None
  65. None
  66. None
  67. None
  68. None
  69. None
  70. None
  71. None
  72. Design Workflow

  73. “The design process is weird and complicated because it involves

    people and organisations, which often are weird and complicated. 
 — Mark Boulton
  74. https://speakerdeck.com/bencallahan/workflow-on-rwd-projects

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

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

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

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

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

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

  82. None
  83. “Build smaller, tactical teams that are capable of executing multiple

    rounds of planning, design, and code quickly and independently. 
 — Trent Walton
  84. None
  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:
  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”.
  87. None
  88. None
  89. Performance Strategy

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

    Mike Krieger
  91. None
  92. None
  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
  94. None
  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.
  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,
  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
  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
  99. None
  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
  101. None
  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
  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).
  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
  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.
  106. None
  107. None
  108. None
  109. None
  110. None
  111. None
  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.
  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) {
 <script src="enhanced.js" async defer></script>
 }
  114. None
  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
 }

  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.
  117. None
  118. None
  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
  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
  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.
  122. None
  123. None
  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
  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
  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
  127. None
  128. None
  129. None
  130. None
  131. None
  132. None
  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.
  134. Delivering The Goods, Paul Irish, https://www.youtube.com/watch?v=R8W_6xWphtw

  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.
  136. None
  137. • Requires server-side and client-side implementations. • Available for Apache

    2.2 (mod_spdy),
 Nginx (ngx_http_spdy_module).
  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.
  139. • Used by Google (Gmail), WordPress.com, CloudFlare, Facebook, Twitter. Different

    browsers support different versions of SPDY.
  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
  141. Gmail’s Lazy Loading • <script id="lazy">
 // Make sure you

    strip out (or replace) comment blocks in your JavaScript first.
 /* JavaScript of lazy module */
 </script>
 
 <script>
 function lazyLoad() {
 var lazyElement = document.getElementById('lazy'); var lazyElementBody = lazyElement.innerHTML;
 var jsCode = stripOutCommentBlock(lazyElementBody); eval(jsCode); }
 </script>
 
 <div onclick=lazyLoad()>Lazy Load</div>
  142. None
  143. None
  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).
  145. None
  146. None
  147. None
  148. None
  149. None
  150. None
  151. None
  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).
  153. None
  154. None
  155. Conclusion

  156. None
  157. None
  158. www.smashingbook.com

  159. www.the-mobile-book.com

  160. Thank you.

  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

  162. None