New Adventures in Responsive Web Design

With HTTP/2, Service Workers, Responsive Images, Flexbox, SVG and Font Loading APIs now available in browsers, we all are still trying to figure out just the right strategy for designing and building responsive websites just in time. We want to use all of these technologies, but how can we use them efficiently, and how do we achieve it within a reasonable amount of time?

In this talk, Vitaly Friedman, editor-in-chief of Smashing Magazine, will be looking into a strategy for crafting fast, resilient and flexible responsive design systems by utilising all of those wonderful shiny web technologies we have available today.

He’ll also talk about dealing with legacy browsers and will cover a few dirty little techniques that might ensure that your responsive websites stay relevant, flexible and accessible in years to come.

“This is not best practices… this is maybe bad practices! This is new stuff.” Smashing Mag has been getting a redesign; and they have done a lot of work on the technical side to get the result they want.

The presentation will be RESPONSIVE ADVENTURES… this will be a game, who wants to go EASY/MEDIUM/HARDCORE? (crowd overwhelmingly votes HARDCORE)

Level 1: Storytelling.

Design process is weird because it’s for people who are also weird (squiggle process). But it’s really more like a set of paths and dead ends.

On the web today, it all boils down to one single thing: outstanding storytelling through great art direction.

When we think about storytelling, we tend to think of fairy tales and not the interface of the Uber application. “I don’t feel like I’m involved in the story…” But then with Mailchimp, Vitaly does feel involved, they have a really engaging brand. He’d switch from Uber without a worry, but leaving Mailchimp would be emotional and need a really big motivation.

We have a lot of commandments about design. Thou shalt not… thou shall… your design process ends up bouncing between all the rules. But can we break the rules and make something memorable?

Example:

  • Bloomberg Businessweek Design 2016 – madly animated, breaks all the rules… the conference sold out in six minutes.
  • aftershock.cc – it’s memorable, you don’t have to go to that level but take some inspiration from breaking out of the rules.
  • hansbrinker.com/amsterdam – terrible hotel that made use of being the worst hotel, they hired a comedian to write stupid copy and just own it.
  • storytrail.co – they take one thing, the line, and use it everywhere. They build a design around that one unusual feature.

Level 2: the system

We want wonderful design, but we also have problems like supporting 7 different languages. How do you support that? Simple things like dates can change per language. The language may be LTR or RTL. How do you make all this work? If you optimise for any one language you will get problems in another.

(slide of very-long German word breaking out of a box)

The crucial asset is building “neutral”, configurable components which can be easily extended and adjusted.

BBC News used .json files for configuration, capturing things like the language, the direction, the social media networks to show. Their SCSS had things like…

$russian = true;

@if $russian {}

Contextual style could then happen based on language direction, known quirks of the language like being particularly short or long. They had a flip mixin that could choose things like left/right floats.

Bonus level for extra points

Who has played with the battery status API? It lets you work out how much battery the user’s device has left. You can load without animation and video if the user’s battery is low. You could have a ‘night mode’ for low battery && not charging.

Level 4: hover

Is there a way to reliably detect if the user can hover? With CSS4 there is a hover media query which works out the primary input. Together with supports you can tailor your styles to the user’s device.

Level 5: selectors

We know the fancy CSS selectors but are we using the simple and powerful things like :not()?

Example: cats in boxes showing primary/secondary/tertiary hierarchy… uses the quantity selector (quantityqueries.com)

Selectors start getting hard to read… remember that they are parsed right-to-left!

li:nth-child(n+6)

…six or more items

li:nth-child(n+6):first-child ~ li {}

…adding the general sibling selector allows you to find the condition then select everything around it.

li:nth-child(3n):first-child ~ li {}

…find the sets divisible by three

Range selector – use multiple nth-child selectors to find a range of elements.

Progressive Web Apps

There are things to consider, eg. offline-first might be a bit weird, but nothing will beat offline storage for performance. People probably don’t really expect your website to work offline, but they’ll like the speed.

Most people don’t install lots of apps, they have a small number of apps and then they don’t have room. Also retention of apps is low – people often stop using an app after a couple of weeks. Mobile web usage is growing twice as fast as app usage.

examples of good PWAs: Flipkart, Konga, eXtra Electronics, 5miles, AliExpress. Washington Post saw 5x increase in user engagement.

You should ask – should you switch your design language on each platform? Should iOS and Android look the same? Should you go fullscreen, standalone or leave the full browser chrome (display-mode)?

Stat to remember: 2/1000 of mobile users tap share buttons. Two out of a thousand.

But while not every user will add your app to their homescreen, everyone who visits will install it and get the service workers.

Be really careful about using push notifications – most people (52%) find them annoying!

Service workers

Service workers behave as a proxy. They take very little resources to start up.

A common offline strategy is quite simple: explicitly cache static resources, cache the homepage in case network fails, for other pages have a ‘fallback’ offline page.

You just need to register a service worker and define its scope (probably / so it applies everywhere). Install the service worker. Cap the cache of your serviceworker.js at 24 hours. Populate offline cache. Then activate the service worker. Now you are ready to intercept requests, with the fetch event.

Search: “pragmatic guide to service workers”, it has lots of great copy and paste code; “frontend performance checklist 2017” on Smashing.

the end

Don’t be afraid to get into this. Go out and break the web, so we can repair it in a few weeks!