WUD Rome 2014 - Delightful UX – Real-Life Responsive Web Design (EN) - Vitaly Friedman
3 likes1,695 views
The document outlines key strategies and principles for real-life responsive web design, emphasizing the importance of a flexible approach to layout, components, and performance. It discusses the concept of progressive reduction, where interfaces adapt to user proficiency over time, and highlights the need to optimize for extreme user cases to enhance overall design efficacy. Additionally, it addresses performance optimization techniques, including responsive images and modular content loading, to improve user experience across various devices and network conditions.
WUD Rome 2014 - Delightful UX – Real-Life Responsive Web Design (EN) - Vitaly Friedman
- 2. Real-Life Responsive Web Design Vitaly Friedman 13/11/2014 • Rome, Italy
- 3. Vitaly Friedman, editor-in-chief and co-founder of SmashingMag
- 30. Patty Toland, FilamentGroup, “Design Consistency for RWD”, https://t.co/Tb0q1gMwQS
- 31. 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
- 32. • 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
- 52. Smart URL Design
- 58. What fascinates me are a few things: how something that got its roots in late 19th century over a course of the century turned into something as established as Teletext. What does it
- 67. “ Your proficiency in a product will decay over time without usage. As such, this proficiency is reflected in experience decays over time. These decays should be avoided at all costs. — Allan Grinshtein
- 68. Progressive Reduction • Usability is a moving target; users get smarter at a product as they keep using it. • An interface should adapt and enable users to become more efficient at using it. • Idea: change the UI as the user moves through different stages of proficiency.
- 70. Progressive Reduction • Every UI regresses without usage. For major features, track and observe their usage. • Create a proficiency profile for every user; as a feature is used more, start reducing the “hand-holding” in a series of levels.
- 71. Progressive Reduction • Assign a proficiency level to each feature and design its variations for each level. • If a user doesn’t use a feature for a long time, UI regresses back to level 1. • If a user uses a feature more, UI keeps increasing levels to the “advanced” mode.
- 80. “ We have clients come to us and say, “We know our average customer. She’s female, 34 years old, with 2.3 kids…” But what we really need to do to design well, is to look at the extremes… — Dan Formosa, “Smart Design”
- 81. “ ...the weakest, or the person with arthritis, or the athlete, or the strongest or the fastest person. Because if we really understand what the extremes are, the middle will take care of itself. — Dan Formosa, “Smart Design”
- 86. Designing for Extremes • Average user is an artificial, static representation of users that don’t exist. • Real users change constantly, reaching different positions, roles and contexts. • Idea: optimize for edge cases first, then converge towards more common cases.
- 91. Skeleton Screens
- 94. Skeleton Screens • Good feedback focuses on the progress; keeps updating current state to ease anxiety. • Blank screens are user experience gaps that disrupt user experience. Progress bars focus on the waiting; focus on the progress instead. • Idea: minimize gaps to reduce friction with “seamless” transitionsand skeleton screens.
- 107. Performance Strategy
- 108. “ There is no difference for the user between a site being down and a site being inaccessible due to loading issues caused by blocking resources or slow networks. — Andy Hume “Real-Life Responsive Redesign”, SmashingConf 2013
- 111. • T-Mobile roaming charges for loading the full front page of Vogue.co.uk, in Moscow: €93,13
- 118. 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.
- 120. “ “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
- 121. 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).
- 122. 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.
- 128. 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> }
- 130. 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 }
- 131. 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.
- 134. • 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 1 HTTP-request to start reading the news.
- 135. • 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.
- 142. SmashingMag’s Refactoring • Drawbacks prompted a focus on performance: • Independent sections with separate WP-installs, • Accessing content was difficult on slow connections, • Question: (once we clean up the front-end), how fast can we be, rather than how fast should we be? • Decoupling JS dependencies (also with ads), • Dealing with annoying Web fonts loading. • Ultimate goal: one code base, one responsive site.
- 143. “ 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
- 144. Performance Strategies • Average page load (onLoad) doesn’t say much about the quality of performance. Metrics: • Visual comparison (against competitors) • Interface response times (<=100ms) • Start render time within 1s on a suboptimal 3G (“above-the-fold” optimization), • Monitor perf. with a private instance of WebPageTest, • Run code against performant budget (Grunt-task).
- 148. SmashingMag’s Modular Load • Consider three types of page content: • Core content (essential HTML+CSS, usable non-JS enhanced experience); • Enhancement (JS, syntax highlighter, full CSS, Web fonts, comments); • Leftovers (analytics, advertising, Gravatar images). • Idea: load Core content first, then Enhancement on DOMContentReady, then Leftovers on Load.
- 150. SmashingMag’s Optimization • Minor optimizations based on a simple principle: optimize content, defer the rest. • Load critical CSS inline and full CSS on load, • Avoid JavaScript libraries (jQuery → JavaScript), • Store Web fonts in localStorage + cookies, • Defer advertising, tracking and all non-critical CSS/JS, • Replaced Respond.js with IE8 stylesheet (fixed-width). • Optimize the critical rendering path for content delivery.
- 157. An Ongoing Battle • Minor optimizations prompted us to review and adjust our editorial workflow: • Using srcset and sizes for images in articles, • Using grunt-perfbudget to track performance, • Measuring changes in traffic and ad impressions, • Reviewing articles for performance before publishing, • PageSpeed >= 98 both on mobile and desktop as a goal. • Next: WebViews issues, “jumps” to comments, defer Gravatars, move to new servers, <picture>.
- 164. 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.
- 165. Delivering The Goods, Paul Irish, https://www.youtube.com/watch?v=R8W_6xWphtw
- 166. 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.
- 168. • Requires server-side and client-side implementations. • Available for Apache 2.2 (mod_spdy), Nginx (ngx_http_spdy_module).
- 169. • 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.
- 170. • Used by Google (Gmail), WordPress.com, CloudFlare, Facebook, Twitter. Different browsers support different versions of SPDY.
- 173. “ SmashingMag is the only site I can read on an EDGE connection when commuting in São Paulo, every day. It makes me think why other sites aren’t optimizing for slow connections, too. — a reader from Brazil
- 175. Thank you.