For some, the creation of what we now know as RWD is often associated with Ethan Marcotte, although its true origins date from earlier when the site Audi.com was first created, which had an adaptive viewport area as a result of limitations within IE at the time.

If one had to describe what RWD is, then Ethan sums it up perfectly:

In a nutshell, RWD is about presenting an experience for customers on different devices that allows them to interact with your business. It is important to note though that the experience does not have to use the same process; it is more important that the customer can achieve the same result, even though they may arrive using a different route. So, how does RWD work?

RWD is a set of principles we should follow, but the overriding philosophy is about making content fluid. Gone are fixed values, at least for elements on the page; in their place, we use percentage values or em/rem units. Our page layout will use a fluid grid, which resizes automatically depending on the available viewport space.

One key concept that will help determine the success of our site is not one we might automatically associate with responsive design, but nevertheless will help: divine proportion.

Divine proportion, or the Golden Ratio as it is often known, is a way of defining proportions that are aesthetically pleasing—it is perfect for setting the right proportions for a responsive layout. The trick behind it is to use this formula:

Imagine we have a layout that is 960px wide, which we want to split into two parts, called a and b. Divine proportion states that the size of a must be 1.618 times the size of b.

To arrive at our column widths, we must complete the following calculations:

It's a simple formula, but one that will help improve the communication of content for your site—we're not forced to have to use it though; sites are available on the Internet that don't follow this principle. It does mean that they must ensure that the content is still equally balanced, to give that pleasing effect—this isn't so easy!

The important point here though is that we shouldn't be using fixed pixel values for a responsive site; instead, we can use rem units (which resize better) or ideally percentage values.

To translate this into something more meaningful, we can simply work out the resulting column widths as percentages of the original size. In this instance, 593px equates to 62% and 367px is 38%. That would give us something like this:

#wrapper { width: 60rem;}
#sidebar { width: 32%; }
#main { width: 68%; }

Okay, a little theoretical, but hopefully you get the idea! It's a simple formula, but a great way to ensure that we arrive at a layout which is properly balanced; using percentage values (or at the very least rem units), will help make our site responsive at the same time.

Now that we've been introduced to RWD, it's important to understand some of the elements that make up the philosophy of what we know as flexible design. A key part of this is understanding the viewport or visible screen estate available to us; in addition to viewports, we must also consider flexible media, responsive text and grids, and media queries. We will cover each in more detail later in the book, but to start with, let's take a quick overview of the elements that make up RWD.

Controlling the viewport

A key part of RWD is working with the viewport or visible content area on a device. If we're working with desktops, then it is usually the resolution; this is not the case for mobile devices.

There is a temptation to reach for JavaScript (or a library such as jQuery) to set values such as viewport width or height, but there is no need, as we can do this using CSS:

<meta name="viewport" content="width=device-width"> 

or using this directive:

<meta name="viewport" content="width=device-width, initial-scale=1"> 

This means that the browser should render the width of the page to the same width as the browser window—if for example the latter is 480px, then the width of the page will be 480px. To see what a difference that not setting a viewport can have, take a look at this example screenshot:

This example was created from displaying some text in Chrome, in iPhone 6 Plus emulation mode, but without a viewport. Now, let's view the same text, but this time with a viewport directive set:

Even though this is a simple example, do you notice any difference? Yes, the title color has changed, but more importantly the width of our display has increased. This is all part of setting a viewport—browsers frequently assume we want to view content as if we're on a desktop PC. If we don't tell it that the viewport area has been shrunk in size (and that we have not set the scaling correctly), it will try to shoehorn all of the content into a smaller size. This will result in a page that will appear to be zoomed out, which doesn't work very well!

It's critical, therefore, that we set the right viewport for our design, and that we allow it to scale up or down in size, irrespective of the device. We will explore this in more detail, in Chapter 2, Creating Fluid Layouts.

<link rel="stylesheet" media="(max-device-width: 320px)" href="mobile.css" /> 
<link rel="stylesheet" media="(min-width: 1600px)" href="widescreen.css" /> 

So - we've explored how RWD works, and some of the key elements that make up this philosophy; question is, why is it so important to consider using it? There are several benefits to incorporating a responsive capability to our sites, which include the following:

So, what is adaptive design, and how does it differ to responsive design?

Responsive design is about making one design fit many devices—it requires us to create the optimal viewing solution for a site, no matter which device we care to use. This means that we should not have to resize, scroll, or pan more than is absolutely necessary; if for example our page width doesn't fit the screen we're using, then our design isn't right! Ultimately though, we can view responsive design as a ball that grows or shrinks in size automatically, to fit several sizes of hoops.

Staying with the hoop analogy, adaptive design works on the principle that we have multiple layouts that are available for use; the browser will select the right one to use, based on detecting which type of device is in use. In this instance, we would be putting several different balls through different sized hoops, depending on the size of hoop in use. The key difference though is that responsive design focuses on client-side development; adaptive design in the main uses server-side detection to display the best-fitting page, based on the device being used to browse the site.

Now that we understand the importance of using RWD and how it differs from adaptive design, let's really begin on our journey; our first step is to get our development environment prepared for use. At this point, you might be expecting to download lots of different plugins or be using libraries such as jQuery. You might be in for a little surprise!

Okay, we've covered enough general background; time to get more practical!

There are many tools available to help us, when constructing responsive sites; this of course includes tools such as JavaScript or jQuery, but also plugins such as FitVids (to manage videos, responsively) or ResponsiveSlides for creating responsive carousels.

However, we're not going to use any of them. All we need is a text editor and a browser, and nothing more! We're not going to download anything as part of completing the exercises in this book.

Yes, I hear those exclamations of incredulity. I must have lost my marbles, I hear you say. There is a very good reason for this approach though; let me explain:

On too many occasions, I see instances where we simply reach for the latest plugin to help us achieve a result. Ordinarily, there is nothing wrong with this; after all, time pressures frequently mean that we can't afford the time to take a more considered approach.

However, I believe we've become lazy. There is no need for many of the tools that are available, when building responsive sites. It's time to go back to basics; throughout the course of this book, we're going to prove that we can build the basics of responsive functionality, with nothing more than a simple text editor and a browser for viewing.

There are some caveats to this approach though, that we should bear in mind:

With that aside, there are a couple of administration tasks we need to complete first; we need a project area to store our content. I would recommend creating a folder somewhere on your PC or Mac to store files; I will for the purposes of this book assume you've called it B03568, and that it is stored on the C: drive. If you've stored it somewhere else, then adjust accordingly.

Next up, we will need a copy of the code download that accompanies this book—there will be instances where we won't cover some of the more mundane content, but focus on the really important content; we can get those less critical files from the code download.

Finally, do you have a text editor that you like using? If not, then you might like to look at Sublime Text 3; it is our preferred editor of choice. The real benefit of using it means we can add plugins, such as the REM-PX (available from https://packagecontrol.io/packages/REM%20PX), which is perfect for converting from pixel to rem-based values! (We will cover this more in later chapters).

Okay, onwards we go; the next stage in our journey is to consider a suitable strategy for creating our responsive sites. There is nothing outrageously complex about this, it is more about making some sensible choices as to what approach we should use which bests fit our solution. Let's take a moment to explore what this means in practice.

As a developer, I am sure you will be wanting to get stuck into creating your next masterpiece, right? Sounds familiar; after all, that is what helps to pay the bills…

Before we can get into writing code, we must develop some form of strategy, this can be as simple or as complex as befits our requirements. Although there is something to be said for defining ground rules, I've never been one for rigid principles; instead, developing a set of guidelines and principles to follow means that we can be flexible about our approach, while still retaining a sense of consistency.

There are a few guidelines that we should try to incorporate into our development process, these are more about helping to reduce any lack of clarity when developing responsive sites for the first time:

As developers, we should have some form of strategy in place when creating our sites; it should not be so rigid as to prevent us changing direction if our existing plans are not working. Whichever way we decide to go, we should always consider an element of best practice in our development workflow; there are a few tips we could use right about now, so let's take a look in more detail.

Best practices...ugh...what a phrase!

This is a phrase that is used and abused to death; the irony is that when it is used, it isn't always used correctly either! This said, there are some pointers we can use to help with designing our responsive sites; let's take a look at a few:

There are plenty more best practices we can follow, but we shouldn't simply follow them blindly; apart from the risk of our sites losing any stand-out appeal (that is, all being the same), not all best practice necessarily applies or is even accurate.

Instead, it is worth researching what others have done online; over time, you will begin to see common threads—these are the threads that should form the basis for any discussions you may have with regards to the design of your site.

There are some practices we should follow, not necessarily because they are best practices, but borne more out of common sense; a great example is touch. When we are designing for touch, there are some pointers which we should use that will influence our design, so let's take a look at these in more detail.

Designing for touch

Although there are lots of tips and pointers we can use to help improve our responsive development, there is one subject that is worth exploring in more detail—touch.

Why? The answer is simple—working responsively is not just about writing code; anyone can write code. The difference though, and that which separates great developers from the crowd, is the thought given to how that site looks and works. Care paid at this point will separate exceptional sites from the also-rans; to get a feel for the kind of decisions and thoughts one might go through, let's take a look at what we might have to consider when designing for touch:

• Aim to use the corners. On small screens, the lower left corner is frequently the easiest to access; for tablets, the top corners work better. We must consider putting any call to action buttons in these locations, and adapt our designs to realign automatically if different devices are used.
• Don't make the buttons too small. A good guideline for tap targets (including buttons) is usually around 44 points (or 3.68rem).
• Avoid placing items too closely together to prevent someone accessing the wrong item by mistake. A good starting point for spacing to avoid interface errors is a minimum of 23pt (or 1.92rem).
• Use natural interactions and create navigation that works well with common hand gestures, such as swiping. This screenshot shows some of the example hand gestures we can use, and that we must allow for when constructing our sites:

Source: The Next Web (http://www.thenextweb.com)

Hover stages are a no-no in responsive design—these do not exist. Any calls to action should be based around tapping, so make sure your design takes this factor into consideration.

Phew, there are a few things to think of there! The key thing though is that while writing code is easy, creating an effective responsive design takes time and resources, and should always be a continuous affair, so our designs can stay fresh and up to date.

It's time for us to move on to a different subject, now that we've explored some of the guidelines and tips we can use to help with responsive development, it's time for us to consider our workflow. We may already have an established one for producing standard sites, making a shift to incorporate responsive design may require us making some changes to our processes, so let's go and explore what a typical workflow could look like when working with responsive design.

Before we start on our workflow, let me ask you a question:

Does your workflow process consist of steps such as planning, creating static wireframes, building static designs, adding code then testing, and finally launching your site? Sounds familiar?

If so, then be prepared for a change; using the waterfall process (to which these steps align), doesn't work so well when creating responsive sites; working responsively is all about being agile, as illustrated by the developer Viljami Salminen from 2012:

Source: Viljami Salminen, 2012

Although his design dates from 2012, it is still perfectly valid today; before you all put your hands up in horror, let me explain why a waterfall process doesn't work for responsive design:

Our development process needs to be iterative, and focus chiefly on text and media before constructing the layout. Throughout the process, we should keep in constant contact with our client, as part of each iteration; gone are the days of working towards the big reveal! With all of this in mind, let's go through Viljami's illustration in more detail.

With the best will in the world, we are only human; there will be times when we make a mistake! As the playwright Oscar Wilde once said, "...to err once is human, to err twice is careless." Well, in the hope that we don't go that far, there are some common errors that are regularly made when working responsively; let's take a look at the top five candidates:

These common issues can easily be solved with some simple changes to our development workflow process, building at least some of these steps to avoid the grief we may get from these errors, early on, will save a lot of heartache later during development!

The philosophy that is RWD opens up lots of opportunities for us as designers. With the advent of mobile and other internet-capable devices, it is important to not only make the switch, but also understand how to get it right. We've covered a number of useful topics around RWD, so let's take a moment to reflect on what you've learned in this chapter.

We kicked off with a gentle introduction to RWD, before exploring the basic principles behind making our sites responsive and understanding some of the key elements that make up RWD.

We then moved on to explore the importance of RWD as a set of guiding principles we can follow; we explored how this compares to adaptive design, and that while responsive design can be harder to implement, it is worth the effort over time.

Next up came a look at strategy—we covered the importance of getting this right, along with the different elements that should be considered when making the move toward working responsively. We took a look at some of the best practices that we can follow and called out designing for touch as a key part of these guidelines, to illustrate some of the decisions we need to make during development.

We then rounded out the chapter with an extensive look at creating a development workflow. We explored how we may have to make changes to our existing processes, and some of the topics that have to be incorporated into our development, before discussing some of the points where we might trip us up, if we don't take care over our designs!

Phew, there's a lot of detail there! The great thing though is that we've covered a lot of the strategic considerations we need to make; it's time to put some of this into practice and start building content and layouts. Let's move on and start looking at how we can build flexible grid layouts. This will be the subject of the next chapter in our journey.