Some really great CSS tips from Rich on sizing display text for multiple viewports.
Excellent guidelines from GDS on providing services that work well on mobile. The watchwords are:
- responsive design,
- progressive enhancement,
- open data, and
- emerging technology (service workers, notifications, etc.).
Native and hybrid apps are rarely justified.
This uses generated content in CSS to make the
aria-label attributes visible on small screens—clever!
This crystallises something I’ve been thinking about for a while. There’s a fundamental philosophical idea underpinning CSS reset or normalise boilerplate that feels at odds with the belief that it’s perfectly fine for websites to look different in different browsers and devices.
This is what Nick Sherman has been banging on about for years, and now the time has come for variable fonts …as long as typographers, browser makers, and standards bodies get behind it.
More details on Ev’s blog.
I’m no fan of mega menus, and if a site were being designed from scratch, I’d do everything I could to avoid them, but on some existing projects they’re an unavoidable necessity (the design equivalent of technical debt). In those situations, this looks like a really nice, responsive approach.
The Search For The Holy Grail: How I Ended Up With Element Queries, And How You Can Use Them Today – Smashing Magazine
One way of implementing the growing/shrinking navigation pattern—an alternative to just shoving everything behind a hamburger icon.
Vitaly takes a look at some of the more unusual patterns used in responsive designed.
Progressive web apps – let’s not repeat the errors from the beginning of responsive web design | justmarkup
Those who cannot remember the past are doomed to repeat it:
When people learned about responsive design, there were many wrong assumptions. The iPhone and early Android phones all had the same screen size (320x480px) and people thought it is a good idea to change the design based on these device-specific sizes.
We wouldn’t do that now, right? We wouldn’t attempt to create something that’s supposed to be a progressive web app, only to make it device-specific, right?
We are still at the beginning of learning about the best ways to build Progressive Web Apps. I hope it will make many more people aware of progressive enhancement. I hope that nobody makes the error again and concentrates on the device part.
Dave explains the thinking behind his responsive table pattern I linked to a while back. He’s at pains to point out that you should always make sure a pre-made pattern is right for you instead of just deploying it no-questions-asked:
Using prefabricated, road tested solutions from Apple’s Human Interface Guidelines, Google’s Material Design, Twitter’s Bootstrap, and Brad Frost’s Responsive Patterns is always a good place to start, but don’t settle there. My biggest advice would be to turn off the 27” display and use your sites and projects on your phone, there’s lots of low hanging fruit that could give way to new patterns, tailor-suited to your content.
Ariel and Lisa have redesigned the excellent Spacehack site and it’s looking stellar!
Here’s a nice little pattern from Dave—showing data tables one column at a time on smaller screens.
This could be a handy replacement for some Google Charts images of graphs. It uses SVG and is responsive by default.
I bet it wouldn’t be too tricky to use this to make some sparklines.
Two (similar) patterns for responsive navigation that don’t involve sweeping everything behind a hamburger icon.
When I’ve experimented with auto-overflowing horizontal patterns like this, I’ve found that a judiciously-placed box shadow can give a nice affordance.
Just recently on a Clearleft project, some of us were discussing whether there was a reason not to use
rems instead of
ems for media queries. Apart from one older browser implementation difference, we couldn’t come up with much.
Some in-depth research here supports the use of
em values for media queries. Very good to know.
Really interesting to see how Jason, Lyza, and co. are handling the process side of responsive design by using Agile sprints. This is how we’re doing it at Clearleft too.
There’s a really good point in here about starting with small-screen sketching:
For most of the sprint, we focus on small screens. We’re often asked how things will work on wider screens early in a sprint, but we try to resist thinking about that yet.
If you’ve managed to organize your life to fit inside a New York City apartment, you’re not going to have any trouble adjusting to a big house in the suburbs. The same is true of responsive designs.
If you nail the small screen design, the larger sizes will be easy by comparison.
A very handy tool for figuring out breakpoints for responsive images.
Upload an image in its largest size, play around with the settings, and then generate the breakpoints, the markup, and the resized images for each breakpoint.
A larger screen is now a progressive enhancement. Hell, with things like Siri and Google Now and Amazon’s Echo, we’re getting to the point where even a screen is an enhancement.