Responsive Interview with Vitaly Friedman

Vitaly Friedman is known by just about everyone in our field. If the name doesn’t ring any bells for you then perhaps you’ll recognise his title: Editor in Chief of Smashing Magazine. When Vitaly isn’t busy with the magazine he is delivering Responsive Design Workshops around the world. Luckily we
managed to catch him during some down time and asked him a few responsive questions.

For those readers that might not know who you are can you give us a bit of an overview as to who you are and what you do?

Well, I am Vitaly, that guy who is known for two things: founding Smashing Magazine, an online magazine for designers and developers, and never finishing my talks and workshops on Responsive Web Design in time. I am not too proud of it, but that’s just how I am and I’ve kind of learned to just go with it. Also, I love beautiful content and don’t give up easily. I work as editor-in-chief of Smashing Magazine in the lovely city of Freiburg, Germany, along with my dear colleagues Iris, Cosima and Markus in the Editorial Team.

What was the best implementation of responsive web design you’ve seen in 2013/14 and why?

If I had to pick one, I’d say that The Guardian’s implementation of responsive design was in my opinion one of the primer examples of Responsive Web design done well. The problem is that due to ads and tracking codes, the performance on desktop is worse than on mobile, but the work done for mobile is just remarkable. I applaud the efforts of the Guardian team, and it shows that progressive enhancement is one of the finest ways to approach Responsive Web Design. Andy Hume  talked about the Guardian work in his SmashingConf talk last year: https://vimeo.com/77967591. Also, the full Guardian front-end code is available on GitHub, so feel free to start playing with it right away.

What are two responsive web design frameworks/plugins/shims/etc that you recommend/couldn’t live without? If you steer clear of the code, what are two tools/workflows/processes you include in your design process that you couldn’t live without?

Well, I wouldn’t include any scripts, frameworks, or plugins by default. If there is a reason to include them, sure, but definitely not by default. For legacy browsers, we can just send them a fixed-width layout and we don’t need to mimic responsive behaviour for them. If I had to choose, I would consider Ajax-Include Pattern by Filamentgroup and Fixed-Nav by Viljami (https://github.com/adtile/fixed-nav/). Apart from that, obviously Sass/Grunt speed up the workflow immensely, and many larger companies that I worked with benefited from the atomic approach and style guides. It’s also a good idea to watch out for Living Styleguides ( https://github.com/hagenburger/livingstyleguide ‎ + http://alistapart.com/blog/post/getting-started-with-pattern-libraries) and grunt-styleguide (https://github.com/indieisaconcept/grunt-styleguide) to generate style guides on the fly as you write your documentation in CSS/SCSS.

What is the one thing with responsive web design you would like to see improved?

Well, obviously performance. There is a lot of debate about responsive websites being not very flexible and bloated by default, but this is what we as designers and developers have to tackle. And there are ways of making fast, responsible responsive websites — it has been done. So it’s our turn now to look closely at how it’s done properly, study these examples and implement them in our work. The other thing I’d love to see happening is a cross-browser support for prefetch, pre rendering, DNS prefetch and other “prebrowsing” techniques as Steve Souders calls them.

Besides, I would love to see more discussions about the maintenance and debugging of responsive websites, especially once major changes are introduced to the layout, I’d love to see element media queries, and I’d love us to focus on tactics, strategies and Web standards for responsive HTML email.

Also, I am looking forward to see more websites using SPDY and the upcoming HTTP/2.0 protocol to deliver content faster. The future looks bright.

If you could offer one piece of advice around responsive web design, what would it be?

Performance budgets can work like a miracle. I wouldn’t want to see lots of tweets about this, but if your client is resistant to care about performance, here is a little trick that works for some developers out there in the wild: take two websites, the client’s website and the competitor’s website, preload/precache the competitor’s website hard in the cache (and localStorage) and run it agains the uncached client’s website. Nobody wants to be slow, and the moment the client sees the difference, they’ll want a fast website, and they’ll want a good performance. Obviously, you don’t tell them that a competitor’s website has been precached…

This is cheeky, but it creates a mutual understanding about the importance of performance, and if you then create a graph placing loading time against traffic in real-time, the client will see the correlation between both, so many decisions will have to be reconsidered for the purpose of performance, which I believe is a very, very good thing!

That’s all of our regular questions. Our bonus questions are courtesy of Mike Kus.

How do you go about maintaining a brand experience on a mobile device?

That’s a very interesting question! I guess since the content is heavily prioritised on mobile, the only option to provide and maintain a brand experience is to use color and typefaces meaningfully and consistently. I love playing with subtle hints and details such as a 2px thick border or smooth transitions on click/touch to indicate the brand experience. There is not much room for major experiments on a mobile device, but by using little “signatures” of the brand identity — these little details I talked about — you sparkle the elements of the experience so it (hopefully) remains recognizable and doesn’t draw too much attention to itself.

What your strategy when it comes to images on different device resolutions?

We are using Grunt to automate the management of images on Smashing Magazine. So far we decided to deliver one single (heavily optimized, non-Retina-optimized) image to all devices (width 500px), we provide links to high-resolution images and we also store original and high-resolution images for our eBooks and printed books separately. We’ve been playing with loading images via JavaScript or post-loading them after everything else has loaded, but so far it caused too much JavaScript overhead. Because most articles have just a few images (4–5 images, around 50–70 Kb each, with a link to a larger view), we don’t use any sophisticated scripts for image delivery (yet). Besides, we have lots of images in the library for all our older articles, so we need a solid strategy on how to manage them.

But we are playing with different solutions all the time, and we are considering loading images with Ajax-Pattern Include pattern, starting with new articles only first and working backwards to optimize older articles as well. So we might see some changes coming over the next couple of months, especially now that <picture> element is being implemented in browsers.

Thanks

A huge thanks to Vitaly for taking time out to share his knowledge with us all. If you want to know more about Smashing’s approach to a mobile first world you should check out “The Mobile Book”.