Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

No content

Slide 3

Slide 3 text

No content

Slide 4

Slide 4 text

No content

Slide 5

Slide 5 text

No content

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

No content

Slide 8

Slide 8 text

No content

Slide 9

Slide 9 text

No content

Slide 10

Slide 10 text

Vitaly Friedman, editor-in-chief
 and co-founder of SmashingMag

Slide 11

Slide 11 text

No content

Slide 12

Slide 12 text

A Little Story

Slide 13

Slide 13 text

No content

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

No content

Slide 17

Slide 17 text

No content

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

No content

Slide 20

Slide 20 text

No content

Slide 21

Slide 21 text

No content

Slide 22

Slide 22 text

No content

Slide 23

Slide 23 text

No content

Slide 24

Slide 24 text

No content

Slide 25

Slide 25 text

No content

Slide 26

Slide 26 text

No content

Slide 27

Slide 27 text

No content

Slide 28

Slide 28 text

No content

Slide 29

Slide 29 text

No content

Slide 30

Slide 30 text

No content

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

No content

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

No content

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

No content

Slide 37

Slide 37 text

No content

Slide 38

Slide 38 text

No content

Slide 39

Slide 39 text

No content

Slide 40

Slide 40 text

No content

Slide 41

Slide 41 text

No content

Slide 42

Slide 42 text

No content

Slide 43

Slide 43 text

No content

Slide 44

Slide 44 text

Design Systems

Slide 45

Slide 45 text

No content

Slide 46

Slide 46 text

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

Slide 47

Slide 47 text

No content

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

No content

Slide 51

Slide 51 text

No content

Slide 52

Slide 52 text

“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/

Slide 53

Slide 53 text

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

Slide 54

Slide 54 text

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 


Slide 55

Slide 55 text

• 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 


Slide 56

Slide 56 text

No content

Slide 57

Slide 57 text

No content

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

No content

Slide 60

Slide 60 text

No content

Slide 61

Slide 61 text

No content

Slide 62

Slide 62 text

No content

Slide 63

Slide 63 text

No content

Slide 64

Slide 64 text

No content

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

No content

Slide 67

Slide 67 text

No content

Slide 68

Slide 68 text

No content

Slide 69

Slide 69 text

No content

Slide 70

Slide 70 text

No content

Slide 71

Slide 71 text

No content

Slide 72

Slide 72 text

Design Workflow

Slide 73

Slide 73 text

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

Slide 74

Slide 74 text

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

Slide 75

Slide 75 text

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

Slide 76

Slide 76 text

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

Slide 77

Slide 77 text

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

Slide 78

Slide 78 text

No content

Slide 79

Slide 79 text

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

Slide 80

Slide 80 text

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

Slide 81

Slide 81 text

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

Slide 82

Slide 82 text

No content

Slide 83

Slide 83 text

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

Slide 84

Slide 84 text

No content

Slide 85

Slide 85 text

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:

Slide 86

Slide 86 text

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”.

Slide 87

Slide 87 text

No content

Slide 88

Slide 88 text

No content

Slide 89

Slide 89 text

Performance Strategy

Slide 90

Slide 90 text

“Who really wants to wait while they are waiting?
 — Mike Krieger

Slide 91

Slide 91 text

No content

Slide 92

Slide 92 text

No content

Slide 93

Slide 93 text

• 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

Slide 94

Slide 94 text

No content

Slide 95

Slide 95 text

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.

Slide 96

Slide 96 text

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,

Slide 97

Slide 97 text

“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

Slide 98

Slide 98 text

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

Slide 99

Slide 99 text

No content

Slide 100

Slide 100 text

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

Slide 101

Slide 101 text

No content

Slide 102

Slide 102 text

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

Slide 103

Slide 103 text

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

Slide 104

Slide 104 text

“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

Slide 105

Slide 105 text

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.

Slide 106

Slide 106 text

No content

Slide 107

Slide 107 text

No content

Slide 108

Slide 108 text

No content

Slide 109

Slide 109 text

No content

Slide 110

Slide 110 text

No content

Slide 111

Slide 111 text

No content

Slide 112

Slide 112 text

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.

Slide 113

Slide 113 text

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) {
 
 }

Slide 114

Slide 114 text

No content

Slide 115

Slide 115 text

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
 }


Slide 116

Slide 116 text

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.

Slide 117

Slide 117 text

No content

Slide 118

Slide 118 text

No content

Slide 119

Slide 119 text

“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

Slide 120

Slide 120 text

• 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

Slide 121

Slide 121 text

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

Slide 122

Slide 122 text

No content

Slide 123

Slide 123 text

No content

Slide 124

Slide 124 text

“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

Slide 125

Slide 125 text

“…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

Slide 126

Slide 126 text

“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

Slide 127

Slide 127 text

No content

Slide 128

Slide 128 text

No content

Slide 129

Slide 129 text

No content

Slide 130

Slide 130 text

No content

Slide 131

Slide 131 text

No content

Slide 132

Slide 132 text

No content

Slide 133

Slide 133 text

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.

Slide 134

Slide 134 text

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

Slide 135

Slide 135 text

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.

Slide 136

Slide 136 text

No content

Slide 137

Slide 137 text

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

Slide 138

Slide 138 text

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

Slide 139

Slide 139 text

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

Slide 140

Slide 140 text

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

Slide 141

Slide 141 text

Gmail’s Lazy Loading • 
 // Make sure you strip out (or replace) comment blocks in your JavaScript first.
 /* JavaScript of lazy module */
 
 
 
 function lazyLoad() {
 var lazyElement = document.getElementById('lazy'); var lazyElementBody = lazyElement.innerHTML;
 var jsCode = stripOutCommentBlock(lazyElementBody); eval(jsCode); }
 
 

Lazy Load

Slide 142

Slide 142 text

No content

Slide 143

Slide 143 text

No content

Slide 144

Slide 144 text

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

Slide 145

Slide 145 text

No content

Slide 146

Slide 146 text

No content

Slide 147

Slide 147 text

No content

Slide 148

Slide 148 text

No content

Slide 149

Slide 149 text

No content

Slide 150

Slide 150 text

No content

Slide 151

Slide 151 text

No content

Slide 152

Slide 152 text

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

Slide 153

Slide 153 text

No content

Slide 154

Slide 154 text

No content

Slide 155

Slide 155 text

Conclusion

Slide 156

Slide 156 text

No content

Slide 157

Slide 157 text

No content

Slide 158

Slide 158 text

www.smashingbook.com

Slide 159

Slide 159 text

www.the-mobile-book.com

Slide 160

Slide 160 text

Thank you.

Slide 161

Slide 161 text

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


Slide 162

Slide 162 text

No content