Responsive Web Design was an idea formed from this article on A List Apart by Ethan Marcotte. The core of it is based around these 3 principles:

1. Media queries allow the page to use different CSS style rules based on characteristics of the device the site is being displayed on, most commonly the width of the browser.
2. The fluid grid concept calls for page element sizing to be in relative units like percentages or ems, rather than absolute units like pixels or points.
3. Flexible images are also sized in relative units (up to 100%), so as to prevent them from displaying outside their containing element.

If you want to read into this further, in particular the early stages of RWD, then I’d recommend reading these two book from A Book Apart:

It’s almost 3 years since that initial article, and around 18 months since those books; the fast-paced nature of this industry means responsive web design has evolved a little. Here’s how we at Mixd define it:

“A responsively designed website is flexible to the conditions in which it will be viewed, in order to offer every user an optimised experience.”

The Mixd Definition

From that statement we have five technical points:

• Be device agnostic
• Be fluid
• Build mobile first
• Be resolution independent
• Optimise

Device Agnosticism

Today’s device market is already massive, and it’s only getting larger.

Credit: Brad Frost – http://www.flickr.com/photos/brad_frost/7387824246/

To build a website that specifically caters for every single device would be a monumental, ongoing task; and certainly one that isn’t cost effective. Instead, a much more manageable way is to build generically, forgetting about individual devices and building fluidly.

Changes in layout are introduced by eye when you feel the design begins to ‘break’, not pandering to the dimensions of certain devices. The introduction of breakpoints could be down to anything really, but typically it’s done to provide a better reading experience, or to make more appropriate use of available space.

Fluidity

“The web has always been fluid; we’ve just wasted a good number of years forcing fixed pixels onto an inherently responsive framework.”

Elliot Jay Stocks

Fluidity is only way to ensure that a user receives an experience catered to their device. Once you start inserting static px values, you add rigidity to a website; which is either going to unnecessarily narrow the content container or cause it to spill beyond the viewport.

Values like em and % flow with a changing viewport, making elements adapt to the widths they encounter.

Mobile First

This is where your site’s breakpoints are applied incrementally, starting at the lowest, so changes to structure and form are applied as the viewport gets progressively bigger. As more horizontal space becomes available, it may make sense for elements to sit beside each other instead of being stacked vertically.

Beyond that, mobile first is also a mind-set, an approach. With the understanding that phones have a limited screen size and sometimes limited functionality, it forces you to focus on your site’s core content, to review it’s hierarchies and set some priorities.

Resolution Independence

In regards to the web, resolution used to be pretty one dimensional, it used to be just 72ppi. A growing trend amongst manufacturers nowadays is to increase the pixel density of their products; the result is that in certain situations, old image practices aren’t cutting it anymore.

A common example would be looking at a website on the newer iPhone or iPad. Because their pixel density is higher than 72ppi, assets that look sharp on other devices now look slightly blurred.

• .png
• .svg
• The SVG logo is considerably sharper on an iPhone 4

Optimisation

The widespread adoption of broadband created a stagnant period where the vast majority of connection speeds were assumed as “fast”. Whilst this created opportunities to create richer online experiences, it also provided the environment for web developers to become sloppy. The result is that web pages were, and sometimes still are, ‘heavy’. Heavy with unminified CSS, bloated JavaScript libraries and uncompressed images; all contributing to a page weight and HTTP request count that is simply unacceptable.

Once we started viewing the web on mobile devices, the game changed drastically. Our comfortable high-speeds, whilst still prevalent, are now considered to be the best case scenario; we’re now faced with users visiting on 4G, 3G, GPRS (o) and Edge (E). The obvious problem is that heavy webpages and slow connections simply don’t mix; they make websites load painfully slow, often frustrating the user.

Even our perception of devices / connectivity patterns have begun to warp. Phones and tablets make use of the slower ‘mobile’ connections, but they also use wifi. Laptops and netbooks could be connected via. wired or wifi*, but they could also be using 3G via. a dongle or tethered smartphone.

Whilst it can hint towards connection speed, viewport width can’t give us a guaranteed indication; all we can do is recognise that these bad connections exist, and build accordingly. The first steps to this ensuring CSS and JS scripts are minified and written efficiently, that images are losslessly compressed and of appropriate size, that nothing is loaded unnecessarily and that caching is configured correctly on the server.

It’s also good to remember that whilst we’re doing all of this for the bad connections, the good connections will benefit as well; what was once OK becomes noticeably fast.

• ImageOptim & Smush.it
• Google Page Speed, Pingdom & Mobitest
• CodeKit

img {
    max-width: 100%;
}

The Process

As well as changing technical aspects of the web, responsive web design has also brought doubts and questioning upon the process as a whole.

Everyone’s process differs slightly, but typically it would flow from planning / scope, wireframing, mock-ups created in applications like Fireworks and Photoshop. Once the client was happy, the design would go to a front-end developer to begin building. The clash between this process and responsive web design is that these mock-ups only offer a single snapshot of how the website will be laid out. Certain elements – like fonts and colour – remain the same, but the grid will change drastically across devices.

“Designers waste a lots of time creating fully fleshed-out comps of what a website could look like. It’s an increasingly pathetic process that makes less and less sense in this multi-device age.”

Brad Frost

To cope with so many device width considerations, it can be more valuable to invest more of our time into the sketching / wireframing phase, and to present these alongside style tiles to communicate the “look and feel”.

Sketching / Wireframing

Sketches and wireframes are low-tech. Generally, it’s using pencil and paper to get your ideas out of your head and infront of your peers. It opens up discussion amongst your team, and allows you to develop good ideas without committing too much time.

• Dotted Paper
• Moleskine Notebooks (Squared Paper)

Style Tiles

Style tiles act as the middle-ground between wireframes and mock-ups. They’re not too sketchy to cause misinterpretation, nor are they too precise that they introduce rigidity into the design. Generally, they’ll be a collection of colours into a palette and typographical choices to give a look and feel without committing any particular structure or grid.

• styletil.es
• Proto

Style Guides

Style guides still aren’t as precise as mock-ups, but they are the beginnings of a design’s foundation. They tend to introduce common web elements, like form inputs and buttons, prompts and alerts and text. They may even go as far as real-life in-browser comps, showing a small nugget of a page and demonstrating how it interacts with other elements. Nothing is set in stone just yet, but the design is beginning to take shape.

A style tile for the Washington Examiner

Design ‘in the browser’

This is a technique where a designer/developer jumps straight into HTML/CSS to begin forming the design in code, instead of an application. The attractiveness of this approach is that it is a real representation of the end-product; it’s rounded corners done in CSS3 and text rendered by a browser. It also gives the opportunity to show how elements respond to the viewport, and how they flow around each other.

This approach isn’t for everyone, but it’s certainly an interesting way of getting results and shouldn’t be shunned.

Frameworks

Frameworks are great for when you’re first exploring responsive web design. With the use of a few preset classes, it’ll allow you to quickly see how the underlying code works. Here’s a few that I’ve worked with:

• Inuit CSS
• Get Skeleton
• 1140 Grid
• Golden Grid
• Golden Grid

I’d personally only recommend these frameworks as a learning tool, and not a crutch for your actual designs. The more you understand how RWD works, the more you’ll come to realise that you can do it all yourself with much less code and not restrict yourself to what the framework makes possible.