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
10. Vitaly Friedman, editor-in-chief
 and co-founder of SmashingMag
12. A Little Story
44. Design Systems
46. “Designing for the Web is like visualizing a tesseract. We build experiences by manipulating their shadows. — Tim Brown
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.
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 

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
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
83. “Build smaller, tactical teams that are capable of executing multiple rounds of planning, design, and code quickly and independently. 
 — Trent Walton
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”.
89. Performance Strategy
90. “Who really wants to wait while they are waiting?
 — Mike Krieger
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
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
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
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.
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>
 }
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.
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.
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
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.
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>
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).
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).
155. Conclusion
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