The new rules of the responsive web

Responsive web design has become a near ubiquitous buzzword on the web. Try searching for #rwd on Twitter to find equal parts content and Twitter spam. This is a common phase in the maturing of a new idea. I remember when AJAX was all the rage; the term got driven into the ground. Now, few people talk about AJAX but libraries like jQuery are fully embraced in a developer’s workflow.

This seems to mirror what’s happening to responsive web design. The term is everywhere. A friend of mine is in magazine publishing, she went to a conference recently, and an editor for a well-known new magazine was talking about upcoming trends and mentioned responsive web design. Editors may not be web professionals, but they know the buzzwords.

As responsive web design gained steam, the way we build websites changed. As the term moves from buzzword into a common part of every web design project, the way we work as web professionals needs to change. With this in mind, we need to lay some new ground rules for how we work.

Rule 1: Don’t stop at “squishy”

When somebody tells you to “check out this responsive site”, what’s the first thing you do? You probably scale the window to see how the layout changes. I’m probably not going to open it in my phone and tablet and start changing orientations or start running page speed tests. I scale the browser and move on with my day. This is our experience as designers and developers, but not as users. When I visit a site as a user, I have no patience. I don’t care if the site squishes nicely; I just want the thing I want.

“Squishy” is a linear scaling of a website. Does the site go from skinny to fat? Instead of linear scaling, responsive web design should focus on establishing a site core and progressively loading from there, based on capabilities. Imagine a site that had to be built for a tiny cellphone running IE7 on an EDGE network. That should be your core site and then scale up based on screen size and capabilities.

Rule 2: Don’t look for an easy way out

Responsive web design is complicated. That’s just how it is. I wish there were something I could tell you to make it easy, but there isn’t. Most people have responded to responsive web design by adding something to their workflows, whether it’s a new deliverable or just going to a developer and asking whether their design will work responsively.

I have a friend who’s working on a responsive site for a client. She’s building the site in Photoshop in desktop size. After a few mockups on some pages, she wanted to show what the site would look like in a tablet and a smartphone, so she did those mockups too. After presenting to the client, she was given some creative tweaks. There are about 50 PSD files for this site at this point. It takes her a few days to revise the layouts.

Trying to add new designs alone will result in a time consuming and inconsistent process. One of the best ways to solve this is by prototyping your wireframes and presenting those to your client. This gives you a deliverable to speak directly to the site’s layout without simultaneously talking about the design. Foundation by ZURB is a great tool for building prototypes quickly.

Simply adding prototypes into your workflow won’t be enough though. In order to succeed in building responsive sites, you need to adjust, which brings us to the next rule.

Rule 3: Embrace change

When I first started building websites, I used two tools, Photoshop and GoLive. Now I have at least six programs that I absolutely require in order to build a site. I still use Photoshop for creating graphic elements, but I mostly design in the browser with Sublime Text 2 and I use Safari’s developer tools to inspect elements on my iOS 6. I also use Codekit to compile my pre-processed CSS and Terminal for version control in Git.

Responsive web design also means changing the way you design. Instead of laying out an entire page in Photoshop, I use Samantha Warren’s Style Tiles to articulate visual design. By designing a site’s visual brand and interface elements outside of an actual layout, you can communicate design directly and combine it with the layout from the prototype to create your responsive site in the browser.

CSS preprocessors are also huge help in any responsive workflow. To put it simply, preprocessors can be used to untangle some of the complication of building a site and ease a lot of the repetition inherit to working in CSS. I personally prefer SCSS, but LESS is a better alternative for some as it has a lower barrier of entry and has better documentation.

Rule 4: Remember your roots

HTML and CSS are inherently responsive. From the inception of HTML, the web was intended to be flexible enough to work on any hardware with an Internet connection. It wasn’t until we as designers and developers moved towards fixed layouts that this changed. In trying to impose fixed dimensions on websites, we constricted the web to desktop computers.

Summary

The responsive web is one that abstracts what you have to say from how you say it. Take, for example, NPR’s recent move to an API driven content model. By moving to an API for providing content, NPR has been able to manage its collection of apps and sites in a consistent way. The only thing that changes is the presentation layer.

This is what the responsive web should be all about. Figuring out what it is you have to say, and letting how you say it be driven by that. Design is about meeting a need in a way that is visually pleasing, but also that works to meet the needs of the user.

This is what the responsive web is all about, the user - creating websites that work for the people that use them, however they access the content. Making sites that can refactor themselves for small screens is just the beginning.

(courtesy: www.webdesignerdepot.com)