Responsive Design

Recently I attended a Responsive Design workshop headed by industry experts Ethan Marcotte and Karen McGrane. This post is a summary of my notes and key takeaways from an e-commerce website’s point of view.

What is Responsive Design? #

• Design for device size rather than anything else
• Render well in any size screen and device agnostic
• Client-side optimization
• Start with responsive then enhance with adaptive solutions if needed (Bill Scott, PayPal)
• Focused clutter free screen provides more value to not just your mobile but also desktop users

Advantages: #

• Mobile growth (Over 50% usage in Search, Social, and Email)
• Mobile does not cut into Desktop usage time (at least in the US)
• If split into two sites, every bug will need to be fixed twice
• Single code base (for marketing, team, release schedule, etc.)
• Target your resources to work on a single site

User Behaviour: #

• Don’t assume mobile users use mobile devices because they’re “on the go” (there is no mobile use case)
• Localized vs device specific - users use devices in any context
• Access to content - anyway I want it (information available at any context)
• Seamless experience across all devices
• Start a task at one device and finish it in another
• Can access your m-dot website in different context like on desktop (sharing links?)

Versus Adaptive? #

• Does not deliver the same information to everybody
• Adaptive serves something different rather than Responsive
• Dynamic serving from the server-side - targeting
• Can be used for that last 5% of use case responsive does not meet

Adaptive Layouts #

• Device specific layouts for pages or features
• Device detection / smelling

Adaptive Content #

• Structured content stored at a finer grain of granularity
• Personalization

Differences #

Content Targeting #

• Device (OS, Mobile, Desktop, Capabilities, etc.)
• Context (Time, Location, Velocity, Humidity, Temperature, etc.)
• Person (Age, Gender, Lifestage, Language, Relationship, New User, etc.)

Device #

• Using device as a proxy for actual information
• On Orbitz, Mac Users Steered to Pricier Hotels

Context #

• Don’t use device as a proxy for context

Web Design #

• Inherently inspired by print
• The web is responsive by default. We take away the universally accessible aspect of it.

“The control which designers know in the print medium, and often desire in the web medium, is simply a function of the limitation of the printed page. … we must accept the ebb and flow of things.”
John Allsopp, A Dao of Web Design

Responsive Layout #

• Rather than splitting your investment, you linearize your development into feature oriented specialists rather than platform specialists
• Satisfy the main things across the board, value to user
• Snapping vs fluid changes (adaptive fixed width vs responsive design to fill the space)
• Read: “The Illusion of Life”.

Percentages Formula:

target / context = result

target pixel width is proportional to the container context … equals the percentage based result

Fluid Grid #

• Best possible experience, regardless of the screen size
• Use percentages, media queries, flexible images (min-width: 100%), etc.
• Baseline at single column layout and then when the width is big enough, we enhance to a two column layout

Media Queries #

• Design your breakpoints based on what your content is rather than the devices available
• Small layout systems
• Defensive CSS, example: min-width: 50rems since you want the whole text to be in one line
• Sort tasks into Logical Groups
• Conditional Loading
• Progressively enhance your content (showing more vs hiding info at smaller sizes)

Performance #

• display: none is not a content strategy
• Performance is a content strategy problem
• Progressively enhance

Progressive Enhancement #

• Use the small (hint: not necessarily mobile) screen as an ACID test
• Support does not mean “Experience parity”
• Preserve default behaviours such as skip links, and add in enhancements (not part of the core experience)

Content Prioritization #

1. Purpose of the page
2. Name each module
3. Priority of each item
4. Is every item required?

How to Start? #

• Do not begin by creating the container
• Think about the content as being fluid
• Decouple content from the front end (think: how we decouple BE from FE)

Content Maturity #

• Reusable Front End Code (style guide, pattern libraries, modular systems, etc.)
• Content Modeling process (present the content rather than forcing content into a structure)
• Back-End Components (display issues are addressed by delivery applications rather than CMS systems … “well duh” - Chris)

Once you name an object, you shape its future.
For example, if you give it a presentational name, its future will be limited, because it will be confined by its style.
A functional name might work better.

Don’t create content for a specific context

Performance #

• Watch Ethan Marcotte’s presentation
• Bandwidth is slow worldwide (even projected for 2020), you can open your project into markets if you lower your load time
• Initial page load is what matters, the critical path, then you can progressively enhance the site

Design for Performance #

• Know Thine Enemies (Images, JS, and CSS files adds weight)
• Performance Budget (communication between business, design, and development)
• Monitor the health of your sites (even using a grunt tool)
• Check the cost of frameworks

Load What You Need
Because we have no way of reliably knowing the user agent’s bandwidth (even on desktop)

Performance Budget #

1. Look at your competitors
2. Look at your own site
   • Load times across the board of products
   • With varying connection speeds
3. Define an aggressive target
4. Constant prototyping against your Performance Budget
5. Critical path CSS to have it usable on initial page load

If something exceeds you budget? #

• Optimize an existing feature
• Remove an existing feature
• Don’t add the new feature

Image Adaption Checklist #

• iconfont to SVG
• Catalog your images for their purpose so you can omit loading them when you don’t need to
• Conditionally load your images if you’re in a bigger device
• Compressive images (Blow up images into large images with very low quality and then resize it to become a small image using CSS will produce a better image with smaller size footprint)
• Images need a conditionally loadable way of loading images using the <picture> element
• CSS Module system to limit the size to what you need

The Design Pod #

Designers: “Introduce” the comp

Developers: Ask lots of questions

Like a thesis defense

• Discuss how the interface might adapt
• Create a shared understanding of the product
• Prototype out the comp
• Move out of Photoshop and into HTML/CSS asap
• Designing in the browser (or rather Deciding in the browser)
• Verify work “live”
• Refine, refine, refine (iterate, iterate, iterate)

Build a pattern library:

1. Visual inventory of Patterns
2. Naming Modules / Components
3. Develop a shared vocabulary
4. …
5. Profit!

Rolling out Responsive #

Responsive Retrofit #

Mobile Only Responsive (which then takes over the desktop site) #

Pick-a-Page #

Kill with Fire #

Reviewing Responsive Designs #

• Education of the organization (jargon, analysis, false assumptions etc.)
• Device availability (which ties in with device support)
• How to review and evaluate at different breakpoints
• Feedback on prototypes
• Making prototypes always available
• Review process that require static files

Problems: #

• Going against the grain of A/B Testing culture by diverting resources from conversion increasing work
• Cannibalization of traffic when having both instances
• Making the switch from Mobile-first to take over Desktop site
• A/B testing performance cost for having both Desktop and Mobile
• Cost on documentation for visual guides

TL;DR #

• Migration Plan: start with a responsive M-Dot site then progressively enhance it into becoming the “real” website (no separate Desktop website)
• The front end should be malleable to make responsive work
• We cannot differentiate between “mobile” vs “tablet”
• Our designs should respond to the changing needs that people want - Don’t design for devices, design for people
• Define relationships not layout
• Desktop doesn’t mean more, Mobile doesn’t mean less
• Separation of content from form
• Performance > Responsive - since users who can’t even load your site won’t use it
• Getting out of comps and into code faster is beneficial to users
• There is no one best way to roll out responsive design
• Hollistic Usage > Pixel Perfect - it’s okay if the site doesn’t look the same everywhere
• Device agnostic modules that is completely independent from the grid structure

“Responsive is not a project. Responsive is a permanent new way of working.”