Published 2015 by Smashing Magazine GmbH, Freiburg. Germany.
Printed in the EU.
ISBN (Print): 978-3-945749-21-0.
ISBN (Amazon Kindle): 978-3-945749-27-2.
Cover Design by Jessica Hische.
Cover Illustrations by Guillaume Kurkdjian.
Layout and Typesetting by Markus Seyfferth.
Editing and Quality Control by Vitaly Friedman.
Copyediting and Proofreading by Owen Gregory.
eBook Production by Cosima Mielke.
Syntax Highlighting: Prism by Lea Verou.
The book has been written and reviewed by Andrew Clarke, Ben Callahan, Chris Coyier, Dan Mall, Dmitry Baranovskiy, Eileen Webb, Emily Gray, Jake Archibald, James Williamson, Lisa Maria Martin, Marko Dugonji, Sara Soueidan, Viljami Salminen, Vitaly Friedman and Zoe Mickley Gillenwater.
A Responsive Way Forward
By Vitaly Friedman
Responsive design hasnt made things easier, has it? The flourishing diversity of web landscape from form factors to connection types to input modes to browsers has only amplified the unpredictability of user experiences on the web. This unpredictability is remarkably difficult to tackle unless you embrace the inherent fluidity of the web as a guiding principle in your work. In many cases, going responsive seems like the most reasonable strategy for covering the entire spectrum of user experiences, ranging from tiny viewports to ultra-wide HD screens, with a wonderfully convenient, and often deceptively sneaky one-codebase-for-everything approach.
Weve learned by now that responsive design is much more than that. Responsive design affects everything and everybody in the design process, and in practice, more often than not, a few media queries, fluid grids and flexible images just arent enough. Screen considerations alone arent enough either. We have to entirely rethink and relearn our design practices, tools and processes, adapt new technologies and break down complexity of UI components, deal with performance issues and hostile rendering environments and apply content choreography to keep priorities and structure intact.
As a result, the craft of designing and building websites has become complex and elaborate, often difficult to estimate, test and support; and it seems that everybody is still trying to figure out just the right techniques within just the right design workflow to create fast, scalable and flexible design systems. Responsive design aint easy, but it doesnt mean that it has to be difficult if you have a good process in place, with a knowledgeable team, and a versatile set of reliable design patterns.
When we set out to create this book, we wanted to explore just that: design workflows, front-end techniques, UX strategies and design patterns that would help web designers and developers get better results, faster. The result lies in your hands now: a compendium of techniques, strategies and patterns that work well in real-life responsive designs written by well-respected designers and developers spending every day crafting and maintaining responsive websites on both small and large scales. Think of it as a handbook with practical guidelines and precise pointers that will help you tackle any level of complexity in responsive design, intelligently and efficiently.
As you can see, the book isnt particularly small, and we hope that youll discover quite a few useful gems in here. All links mentioned in the book are also collected on www.smashing-links.com . We hope that by the time you flip over the last page, youll feel empowered to craft accessible, fast and flexible responsive websites that will stand the test of time and unpredictability whatever devices come next. Happy reading!
Vitaly, editor-in-chief of Smashing Magazine
The Modern Responsive Designers Workflow
By Dan Mall
In our industry, we are often subject to three things: titles, tools, and output. We sort ourselves into buckets based on our job titles: designers, developers, content strategists, information architects, and others. Its often cleaner that way. We sort ourselves by tools as well. Designers use things like Photoshop and Sketch, and developers use things like Sublime and CodePen. If you walk by somebodys desk, and theyre using Omnigraffle, its likely theyre an information architect.
Were also categorized by output: designers are expected to produce comps; developers are expected to write code. Our deliverables and output are severely outdated, limiting the squishy, giddy, icky, amazing, multi-device world that we live in.
Were good at placing ourselves within these specific buckets, but what often goes wrong in projects happens within gaps between the job descriptions and deliverables lists.
When I started my design collaborative called SuperFriendly, I was determined to find a new set of tools and outputs to better suit the people who hire us and to better serve their customers. I had a few specific goals in mind that I wanted to achieve, goals that would make my workflow more productive and more efficient.
First, I wanted to figure out how to achieve the highest fidelity in the shortest amount of time. The second goal was to remove abstractions wherever possible, so I could clearly see what I was designing and building. The third goal was to ensure that during the process, all deliverables would come with conversation.
To this end, I found that I often prioritized frameworks over processes. As an industry, we talk a lot about processes, but I find it more useful to think about what frameworks I want to put in place.
Consider this example. A Newtons cradle is a process. Its a repeatable system thats optimized for efficiency, not innovation. It always starts the same way: you lift a sphere on one of the ends, release it, it hits the one next to it, and it continues in that system. It doesnt deviate from that system. Theres nothing surprising about it; theres nothing unexpected about it. Thats what its good for.
By contrast, a football field is a framework. Every game is the same length; its played on the same type of field; it follows the same rules. Everyone knows where out-of-bounds is, and everyone knows where the goals are. Yet what happens within the ninety minutes is a surprise every time.
I wasnt looking for a process for my agency I was in search of a new framework. One that would work well with my workflow. After a lot of experimentation, failing and trying again, I found what works very well within general project constraints, at least for me. This is exactly what this chapter is about: a couple of things that I found in my responsive design workflow, with a few techniques and ideas that have proved useful in my own work.
Planning
The first piece of that framework might sound remarkably unremarkable: designers should be more involved in planning. Conducting interviews are a great way to start planning.