RWD Weekly #411 Interview Series with Brad Frost

Hello and welcome to RWD Weekly Newsletter edition #411 and the continuation of the interview series.

This week we’re going to Brad Frost and ask him the same seven questions that we’ve asked our guests in the past.

Brad was one of the first people I interviewed when this newsletter was still in its infancy, and again as the podcast was getting off its feet. He has a way of looking at problems and finding simple yet groundbreaking solutions and shares it all with the community freely.

A quick sponsor message and then let’s see what Brad has to say.

Sponsor

TLDR Newsletter – Byte Sized News for Techies

TLDR is a daily, curated newsletter with links and TLDRs of the most interesting stories in tech, science, and programming! See a sample edition.

The Interview

How do you find working with clients these days? Is responsive something that you have to sell in any more or does everyone get it now?

By this point, responsive design is a given when talking with clients about doing any new work. I work with a lot of giant companies, so their language around responsive design can still be a bit cringy (“We will support ‘desktop’ and ‘mobile’!”), but the overall expectation is that any web work involves creating a singular responsive web experience.

What is it that you find the hardest when speaking with clients from a site design/build point of view, and how do you go about explaining why it is important?

Most — well, nearly all — all of my work entails creating design systems. At this moment, everyone is trying to create a design system. The hardest thing I have to deal with is teams misinterpreting atomic design and suggesting that in order to create a design system they have to create a library of components in isolation. Organizations think they have to hit pause on their product work and focus on creating a component library. This is a mistake. Atomic design entails creating components, yes, but crucially also actual product screens at the same time. It’s not a one-then-the-other thing. Reusable components are created by way of building real products, with each subsequent pilot project making the component library more comprehensive and accelerating the product work.

So much has changed since Ethan’s eureka moment, what are your go to implementation methods for responsive sites? How do you handle layout, typography, images, video etc?

Oh boy, that’s a big question. Each one of those things (layout, typography, images, video, etc) all have their own unique considerations. I’d say now that CSS Grid is here (along with our trusty friend Flexbox), layout has gotten a lot smoother. Establishing a common set of layout patterns using repeat notation has been tremendously helpful.

Typography has always been tricky, but I think we finally cracked the code on it. My colleague Dan Mall wrote a great article about how we established a solid typography system. One thing he doesn’t cover in it is that we set up Sass mixins to accept a $responsive boolean to switch responsive behavior on or off. In certain cases, you want the typography size/treatment to be consistent across the resolution spectrum, but in other cases you need the type to adapt across screen sizes. For instance, you may want to have a heading in a passage of text that is medium-large-ish on small screens, but larger on large screens. But you also have a card component’s heading that you want to treat consistently across the resolution spectrum. Having a flag that enables both of those behaviors is pretty slick.

Images have been helped along by srcset and picture elements for sure, and bundling those up as components in a design system has been really helpful from an ergonomic standpoint. Same goes with video.

But yeah, at the end of the day, each topic around web development has their own unique responsive considerations, and I’m increasingly finding there isn’t a one-size-fits-all solution out there for each topic. It just takes a lot of implementation and iteration to land on patterns you feel good about.

What are the top three issues you’re still facing when building a responsive site?

A big one is lack of container queries. I really want the ability to create fully flexible self-contained components and then drop them into any layout and have them Just Work. Alas, that isn’t possible right now without a (polyfill).

Another one (that’s related to the above issue) is creating layout and component systems that other designers/developers will use in novel and unforeseen ways. It’s fairly easy to create page layouts and responsive layout components when you’re doing the product work yourself, but it’s a lot more challenging to build abstract layout patterns that may get used in other products you as an individual aren’t working on.

And I’ll say a third big issue is still the fact that static design tools continue to be terrible at representing real responsive behavior. We still work with a lot of designers that are creating “mobile” and “desktop” comps, which contain a whole bunch of incongruent/unrealistic design decisions. “Hmmm, maybe I’ll just hide this whole section. Let’s just move this on top of this. Let’s tuck everything behind this button.” So much of our work involves revisiting these comps and helping educate designers on how things really play out in the browser.

We started off with lots of m.dot.sites when mobile arrived. Google was a huge part of changing that approach by saying that all content should be found on a single URL. One true source. In recent years Google have incentivized the AMP Framework as a way to provide a new/better experience to mobile users. What are your thoughts?

I don’t like AMP. Thankfully, others have summed things up quite nicely so I’ll just say that I agree with what others have said.

Prediction time. What are we going to see towards the end of 2020 and into 2021?

Predictions are always hard, so take it all with a grain of salt. I think that we’re increasingly going to see static design tools make progress in pulling in coded components (a la Modulz) so that the disconnect between design and development isn’t so large. This is wishful thinking, but I’d love to see some progress made on container queries. I also think web components will (hopefully) start to gain some traction as a native way of creating component-driven frontend code.

Thank you so much for your time, if our readers want to learn more from you where can they track you down?

My home base is my personal website, where I blog about web design and other stuff. I’m also on Twitter, and you can read/buy my book Atomic Design over here.