RWD Weekly Interview Series II - #4 Chris Coyier

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?

I don't do any client work. I can say that it seems like responsive design is just an assumption. I think that responsive design was an assumption in 2015. Even then, if you delivered a website to a client that was just a zoomed out "desktop" website they would assume it's broken and that you didn't really do your job. Today, even more so. It's just not done.
 

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?

I don't do client work so this probably isn't super relevant for me. If I did, I'm not even sure that I'd mention it, I'd just present them the work and be ready to answer any questions.
 

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?

It's nice to think about how Ethan always defined responsive design:

1. Fluid grids
2. Flexible images
3. Media queries

Those really do feel like the fundamentals, and it's been this way such that the tools for handling them have shaken out nicely. Fluid grids are easy to pull off with CSS grid and setting columns with fractional units. Flexible images are largely handled by img { max-width: 100%; } and now thankfully we have responsive images so we can be responsible about what we're serving. Little tricks like this are great for video. And media queries are still the best tool we have for rejiggering design for the space we have available.
 

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

Remembering to test! The sites that I happen to work on are still primarily desktop sites. Where the industry at large is seeing tons of traffic and usage from small screens (most traffic, in a lot of cases), my sites are still 95%+ desktop. That's not to say I don't build for small screens too, but I'll admit that sometimes I still forget to test things on small screens and end up having to do after-release fixes.

Aside from that, the biggie on everyone's mind is component queries. I like that name too, because "components" is a huge deal on today's web. Everybody is building things from components. Components that don't always know on what page they are going to end up or what size they are going to be. Component queries don't exist today, which is a shame, because we really should be doing CSS work that let's a component adapt to the size that it is rather than the size the page is.
 

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?

Perhaps my least favorite thing about AMP is that it feels like an m-dot to me. If you aren't building your site as directly AMP (hardly anybody does that) that means you're building a second site for AMP. A second code-base. Maybe a second team. It's bound to be a second-class project. Sure, I could just install a WordPress plugin or whatever, but then it's totally un-themed and that doesn't exactly align with business goals (like having a site that looks like our brand), and I imagine it also doesn't for most folks.

Most of the developer dislike of AMP stems from the fact Google dangles a bit carrot to get sites to use it. It's a big carrot: being in the news carousel at the top of search results pages. That drives a crapload of traffic and the only way in is AMP. Google is free to do that, it's their website, but it's a game I just can't play. I don't wanna play it with Apple News, I don't wanna play it with Facebook Instant Articles or whatever that is (was?). If I was a big mega-publisher with all the resources in the world, maybe I could afford to play those games, but me, I'm just gonna make a standards-based website and roll with that. Seems to me things like this come and go and the web hangs around.
 

As a business/product owner, what is the most frustrating thing you find trying to take a product out across today's diverse device landscape?

User expectations are no joke. The bar is pretty high for web products these days. Particularly websites that are somewhat feature-heavy. They need login systems that support social login. They need to look great (if yours doesn't, your competitors will). They need to be smoking fast. They need to solve real problems. They need to be accessible (it's a competitive advantage). You need to build in a way that will keep you nimble and not bog you down in technical debt. Spinning up a blog is perhaps easier than it's ever been, but if you want to compete on the web building a product, you've got a high bar to clear.

Then when you factor in the device landscape, it gets even harder. Some digital experiences still really benefit from being a native app. I always think of just the idea of staying logged in. Native apps just do that in a way the web can't, even if you have a very fancy PWA. The world of build-once ship-natively-everywhere, as much as it is being explored, still hasn't entirely shaken out.
 

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

Building websites from components is really taking hold. There is finally a lot of alignment across the whole stack. Designers are loving design systems, which are often highly component-based. Front-end developers are loving JavaScript frameworks that mandate we build thing from components. Components are often increasingly in charge of their own data and functionality, making them cross over into backend territory. The web is maturing and things like this are starting to shake out.
 

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

I've got a personal website.

Finally

Cheers,

Justin.