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.

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