With so many well designed websites out there, it’s not enough to be good — you have to be great. Visual design alone can just go so far — what you could be aiming for is creating delightful user experiences. Rich, beautiful, smooth experiences that help you stand out and ensure that the user is in the flow. In this talk, we’ll discuss a few tips and techniques and examples of how to make it work and captivate users — for good.

2. Real-Life Responsive
Web Design
Vitaly Friedman
13/11/2014 • Rome, Italy

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

5. Design Systems

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

55. http://global.burton.com
/on/demandware.store
/Sites-Burton_GLOBAL-Site
/default
/Home-Show
/index.html

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

66. Progressive Reduction

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.

78. Designing for Extremes

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.