Download code from GitHub
The concept of web design used to be simple—designers would develop content for a popular desktop screen, using a layout which works for most devices to produce well laid-out and cohesive pages.
With changes in technologies and the introduction of mobile devices, the whole experience changed—gone are the days when a static layout would suffice. In its place came a need for content that responded to the available screen real estate, with elements automatically resized or hidden, according to the device being used. This forms the basis for a technique popularized by Ethan Marcotte, which we now know as responsive web design (RWD). Throughout the course of this chapter, we will begin to explore what this means, and understand some of the principles that are key to this concept.
In this chapter, we will cover the following topics:
Getting started with RWD
Understanding the elements of RWD
Understanding the importance of RWD
Exploring how RWD works
Setting up a development workflow
Exploring best practice and common errors
Curious? Let's get started!
If one had to describe RWD in a sentence, then responsive design describes how the content is displayed across various screens and devices such as mobiles, tablets, phablets, or desktops. To understand what this means, let's use water as an example. The property of water is that it takes the shape of the container in which it is poured. It is an approach in which a website or a webpage adjusts its layout according to the size or resolution of the screen dynamically. This ensures that users get the best experience while using the website.
We develop a single website that uses a single code base. This will contain fluid, flexible images, proportion-based grids, fluid images, or videos and CSS3 media queries to work across multiple devices and device resolutions. The key to making them work is the use of percentage values, in place of fixed units such as pixels or ems-based sizes.
The best part of this is that we can use this technique without the knowledge or need of server based/backend solutions; to see it in action, we can use Packt's website as an example. Go ahead and browse https://www.packtpub.com/web-development/mastering-html5-forms; this is what we will see as a desktop view:
The mobile view for the same website shows this, if viewed on a smaller device:
We can clearly see the same core content is being displayed (that is, an image of the book, the buy button, pricing details, and information about the book), but elements such as the menu have been transformed into a single drop-down located in the top-left corner. This is what RWD is all about—producing a flexible design that adapts according to which device we choose to use, in a format that suits the device being used.
Let's try it with another technology site; I am sure some of you are familiar with the A List Apart site (hosted at http://alistapart.com and founded by the well-known Jeffery Zeldman):
Try resizing your browser window. This is a perfect example of how a simple text site can reflow content with minimal changes; in place of the text menu, we now have the hamburger icon (which we will cover later in this chapter):
While the text in this site realigns with minimal difficulty, it seems that the top image doesn't work so well—it hasn't resized as part of the change, so will appear cut off on smaller devices.
Although this may seem a complex task to achieve, in reality it boils down to following some simple principles; how these are implemented will ultimately determine the success of our site. We've seen some in use as part of viewing Packt's and A List Apart's sites at various sizes—let's take a moment to explore the principles of how responsive design works, and why it is an important part of creating a site for the modern Internet.
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:
Rather than tailoring disconnected designs to each of an ever-increasing number of web devices, we can treat them as facets of the same experience. We can design for an optimal viewing experience, but embed standards-based technologies into our designs to make them not only more flexible, but more adaptive to the media that renders them. In short, we need to practice responsive web design.
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:
Divide the width of our site (960px) by 1.618. This gives 593px (rounded to the nearest integer).
Subtract 593px from 960px. This gives 367px.
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.
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.
When designing responsive sites, we can either create our own layout or use a grid system already created for use, such as Bootstrap. The key here though is ensuring that the mechanics of our layout sizes and spacing are set according to the content we want to display for our users, and that when the browser is resized in width, it realigns itself correctly.
For many developers, the standard unit of measure has been pixel values; a key part of responsive design is to make the switch to using percentage and em (or preferably rem) units. The latter scales better than standard pixels, although there is a certain leap of faith needed to get accustomed to working with the replacements!
Two key parts of our layout are of course images and text—the former though can give designers a bit of a headache, as it is not enough to simply use large images and set overflow—hidden to hide the parts that are not visible!
Images in a responsive site must be as flexible as the grid used to host them—for some, this may be a big issue if the site is very content heavy; now is a good time to consider if some of that content is no longer needed, and can be removed from the site. We can of course simply apply display: none to any image which shouldn't be displayed, according to the viewport set. However, this isn't a good idea though, as content still has to be downloaded before styles can be applied; it means we're downloading more than is necessary! Instead, we should assess the level of content, make sure it is fully optimized and then apply percentage values so it can be resized automatically to a suitable size when the browser viewport changes.
With content and media in place, we must turn our attention to media queries—there is a temptation to create queries that suit specific devices, but this can become a maintenance headache.
We can avoid the headache by designing queries based on where the content breaks rather than for specific devices—the trick to this is to start small and gradually enhance the experience, with the use of media queries:
<link rel="stylesheet" media="(max-device-width: 320px)" href="mobile.css" /> <link rel="stylesheet" media="(min-width: 1600px)" href="widescreen.css" />
We should aim for around 75 characters per line, to maintain an optimal length for our content.
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:
It is easier for users to interact with your site, if it is designed to work with multiple devices.
Creating a single site that caters to multiple devices may in itself require more effort, but the flip side of this is that we're only developing one site, not multiple versions.
Constructing a site that works based on how much can be displayed in a specific viewport is a more effective way to render content on screen than relying on browser agent strings, which can be falsified and error prone.
RWD is able to cater to future changes. If we plan our site carefully, we can construct media queries that cater for devices already in use and ones yet to be released for sale.
Accessibility plays a key role in responsive design. Our content should be as intuitive as possible, with every single piece of information easy to access. Responsive design places great emphasis on making our design self-explanatory; there shouldn't be any doubt as to how to access information on the site.
Note
In this context, accessibility refers to making our site available on a wide variety of devices; this should not be confused with the need to cater for individuals with disabilities. Making sites accessible for them is equally important, but is not a primary role in RWD.
Even though our mobile version may not contain the same information (which is perfectly accessible), it nonetheless must be engaging, with appealing colors, legible text (at all sizes), and a design that retains visual harmony and balance with our chosen color scheme.
The success of our site is determined by a host of factors, of which one of these will be how our content is organized in the layout. The content should be organized in such a way that its layout makes it easy to process, is simple and free of clutter, and that we're making full use of the available viewport space for the device we're targeting.
We must also ensure our content is concise—we should aim to get our point across in as few words as possible so that mobile users are not wasting time with downloading redundant content. Keeping our options simple is essential - if we make it too complicated, with lots of links or categories, then this will increase the time it takes for visitors to make decisions, and ultimately only serve to confuse them!
At this point, it is worth pointing out something - over time, you may come across the phrase adaptive design, when talking about responsive design. There is a subtle but key difference between the two, and either can be used as a principle when constructing our site. Let's take a moment to explore what each means, and the differences that might affect how we go about constructing our sites.
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.
Note
For the purpose of this book, we will work on using responsive design throughout all of the examples used within the text.
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:
Much of what we construct won't work in some older browsers—IE9 or below is a good case in point. The question you must ask yourself is: how many people use this for your site? If the percentage is very low, then you can consider dropping them; if not, then you will need to seek a different approach.
Concentrating on using just HTML and CSS does not mean that we're rejecting other tools outright; if we need to use them, then we need to use them. The question we must ask ourselves though is this: do we really need to use them? Or are we just too lazy to go old school and create things from the ground up?
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:
Choosing mobile over desktop: This is not a new idea; it has been around since before responsive design took off as a serious approach to creating sites. The mobile-first concept means that we should develop our content for smaller mobile devices first, before working up to tablets and desktops. At this stage, it is important to be aware of what visitors may be using for your current site; this will help determine which devices we should concentrate on as part of our design.
Breakpoints: Getting these right will be essential to the success of any site we build; not only must we choose the right thresholds for the devices we want to support, but also ensure that the cut-off points do not overlap each other. A common misconception is to develop for standard breakpoints such as desktops or tablets; instead, we should set our breakpoints to kick in when our content breaks within our layout. This screenshot shows the type of thresholds we have to consider in our designs:
The flow of content: When we start designing for smaller screens, content will naturally be squeezed and begin to flow downwards. This may be tricky to grasp as a concept, if you're used to pixels and points when designing, but it will make sense once you get used to how content will flow downwards in responsive design.
Relative units: This is an important concept in responsive design. It's a case of learning how to make the switch from static values to relative units. Calculating values in percentages means that content will always fit, no matter what the viewport size; for example, the size of a
<div>set to 50% means that it will only ever fill 50% of its parent container, no matter what the size of the viewport. It may be a case of building the initial design with static values, but we should try to get into the mindset of converting to use percentages as part of our design process.Max and min values: A part of using relative values means that our browser won't understand what the lower and upper size limits of each element will be. To work around this, we must set
min-widthormax-widthvalues; these will ensure that no matter what width our elements are at, they won't go past the limits set in code.Web fonts or system fonts: If you maintain a desktop version of your site already, and it uses one or more web fonts, then you have an important decision to make: should the mobile site use the same fonts? The reason for asking is because this requires additional content to be downloaded; it will consume extra bandwidth, which will be a concern for devices where this is limited. Bear in mind that anyone using a mobile device is likely to be under time pressure, they will want to do something quickly and with the minimum of fuss, so selecting a non-standard font won't be a useful way forward.
Bitmaps or vector images: When working with responsive designs, a key principle is scalability; we must have images that can easily be resized or swapped for larger or smaller as appropriate. Taking the latter approach on a mobile device isn't wise; a better route would be to consider using vector images. These not only resize without loss of quality, but can also be manipulated using CSS if desired, which reduces the need for separate versions of the same image (provided the vector image has been optimized prior to editing with CSS).
Content strategy: The aim of responsive design is to create the best possible experience, irrespective of the device used to view the site. Part of this centers around content; as a part of developing a strategy, content should always come first. We need to add enough to make our design a useful foundation; we can then add or develop this at a later date, when we add support for larger screens and resolutions.
Sketch and prototype: Once we have worked out our content and a strategy for managing it, it's time to develop the layout. A key part of this should incorporate sketching or wireframing; it will help turn the rough beginnings of a plan into something more solid. Many designers will use PhotoShop, but this is at the risk of wasting lots of billable hours that must be accounted for with the client. Sketching on paper is portable, and has a low visual and content fidelity, which means we can focus on how content interacts, rather than how it looks.
Frameworks: Using a framework in our development can bring several benefits to our development process; it's tried and tested code means that we can cut down on development time, and make use of the grid approach to build and refine our layout around our content. Frameworks will have already been tested across multiple devices, so the debugging time is reduced; we should concentrate on choosing the right framework, based on criteria such as the learning curve required, support, and documentation availability.
Note
A caveat with using frameworks though is their size; if we go down this route, we should choose carefully which one to use, as many are code heavy and adding extra unnecessary code will make our sites slower.
Scalable media: Images and videos are essential for any site; not only do they help add color, they can also convey more in a smaller space. All of our images must be scalable; it doesn't matter if we swap images out as our resolution increases, or we use a scalable format such as SVG. We need to give consideration to sourcing both standard and hi-resolution versions of our images, to cater for those devices that support the latter; these can either be individual or in the form of image sprites. Our media strategy should also consider using icon fonts, which are perfect for small, repeatable elements such as social media logos.
Minification: If we're building sites to work on devices where bandwidth constraints and limited resources may be a factor, then we must consider minifying our CSS and JavaScript content. Minifying should be a standard part of any development workflow. We can reduce the number of HTTP requests to the server and improve response times. When designing responsively, minification becomes more critical, as we are adding more CSS styles (such as media queries) to cater for different viewports. This will inflate the size of our style sheets even further so anything we can do to help reduce the size, will help encourage takeup of our newly developed responsive site on mobile devices.
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:
Use a minimalistic approach: This is very popular at the moment and perfect for responsive design. It reduces the number of elements we have to realign when screen dimensions change; it also makes editing content and elements easier, if our page content is at a minimum.
Always go for a mobile-first strategy: It is essential to consider what the user experience will be like on a mobile device. The proportion of those who own a mobile device or phone is higher than those who own their own PC; we must make sure that content is both viewable and legible on a smaller screen. Once we've nailed this, we can then extend our design for larger screens.
Understand the need for speed: A slow site is a real turn off for customers; a good guideline to aim for when measuring load times is for around 4–5 seconds. There can be many reasons why a site is slow to load, from slow site feeds to poorly optimized hardware, but one of the easier to rectify is large images. Make sure that you've been through all of the media that is loaded, and checked to ensure it has been fully optimized for your site.
Try to keep the site design as clean as possible: Eliminate anything that is not needed to convey your message. It goes without saying, but why use 20 words, when we can get our message across in 10?
Make use of the hamburger icon: No, I'm not referring to food, irrespective of what size it is (sorry, bad joke!). Instead, make use of it as a consistent point of access to your site. Be mindful though that users may not want to have to keep tapping on it to access everything, so if you have menu items that are frequently used more often, then consider exposing these in your site, and hide anything less important under the hamburger icon.
Don't use small button sizes for anything: Bear in mind that many users will use fingers to tap on icons, so any clickable icons should be large enough to allow accurate tapping and reduce any frustration with accidentally tapping the wrong link.
Familiarize yourself with media queries: As we'll see later in Chapter 4, Exploring Media Queries, we can use media queries to control how content is displayed under certain conditions on different devices. These play a key role in responsive design; it's up to us to get the right mix of queries based on what we need to support!
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.
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:
We cannot hope to get support for lots of different devices built into our site in one go. We must focus on a small viewport first, before gradually enlarging it to include support for larger devices and finally desktops.
When working responsively, our focus must be on content first, and not the layout; the reason for this is that our media queries should be built around where content breaks if we change the width of our available viewport. This removes the dependency on building for specific devices, and means that we can build queries that can serve multiple devices.
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.
This initial stage is the same for any sites, but is particularly important for responsive design, given the different viewport sizes we have to support in our site. It's all about getting to know the client and their requirements. We must get an understanding of our client's business, their competitors, and what they are trying to achieve.
It's at this point we should be asking questions such as, "Why would people come to your site?", "What is the main goal you are trying to achieve?", and "Who are your main competitors?" The more we ask, the more we can understand and therefore better advise our clients on the best solution to fit their requirements.
When we've gathered all of the knowledge needed to construct our site, we now need to plan how it will look. We can start with the initial concept, but rather than work on the layout as we might have done before, we should concentrate on the content elements, and creating user stories and the information architecture. We can then put this together in a rudimentary HTML wireframe. At this stage, layout is less critical; it's key that we get the right view of information, before focusing on where it sits on the page.
At this point, we now need to focus on writing our content in textual form. This often under-rated step is probably the most important of the whole process; without it, people won't come to see the site, and there is no point in designing a layout if we don't know what will fill it! A useful tip is to keep styling to a minimum and to concentrate on the content; at least initially, we can see how it will display in a long, continuous format, and if it works for those who use screen readers. Don't worry though, we can always refine the text during the prototyping stage; at this point, we need something to start with, but it will be unlikely we get it right first time.
For our next step, forget using PhotoShop; it takes forever and is a real pain to make corrections quickly! The agile process is about making quick and easy changes and there is no better medium than traditional pen and paper. We can even print off the plain text content and sketch around, it if that helps, it will save us hours of development time, and can even help reduce those occasions when you hit the developer's block of...what now?
With the design sketched, it's time to create a prototype. This is when we can see how the layout will respond to different viewport sizes and allow us to highlight any potential challenges, or react to any issues that are reported by our client. It's good to be aware of the various breakpoints, but ultimately we should let our content determine where these breakpoints should be set in our design.
We might be used to prototyping our design using PhotoShop, but a better alternative is to switch to using a browser. We can use a service such as Proto.io (https://proto.io/) or Froont (http://froont.com/). This gives us extra time to get the harder elements right, such as typography; it also helps to remove any constraints that we might have with tools such as PhotoShop.
Although we may still be at a prototype stage, it's important to introduce testing early on. The number of breakpoints we may end up having in our design means that testing on multiple devices will take time! As an alternative to running a big test and reveal, we can instead perform multiple tests and reveals. This has the benefit of reducing the impact of any rollbacks (if something doesn't fit requirements), but also helps to keep the client involved with the project, as they can see progress take place during development.
The one thing we absolutely must do is to test over multiple devices. It's an expensive proposition to maintain a test suite with these devices, so it's worth asking colleagues, friends, and family to see if they can help test for you. They can at least browse the site and help pinpoint where things don't look right (to use customer parlance). It's up to us to work out where the root cause is, and implement a fix to help improve the user experience.
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:
Failing to allow for touch input: It might seem odd, but failing to allow for touch is surprisingly common! Some users expect a site to simply work, and to have a consistent approach across the board both for desktops and mobiles. This will include any mechanism for activating links (such as buttons). What might work on a desktop client will very likely fail on a mobile device. It is absolutely key that we include something to allow mobile users to navigate around a site using touch. This can be achieved (in the main) with CSS3 styling, so there is no excuse!
Insisting on a consistent navigation: A part of creating a successful site will be to have some form of navigation that retains a consistent look and feel across all pages; it does not mean to say that we have to carry this over to mobile devices though! Navigation on a mobile device will of course act differently; we have the added extra of touch input to cater for, as part of our design. At an absolute minimum, links and buttons, along with our choice of typeface and colors should remain consistent; the size of buttons, our visual layout, and how we click on buttons can change.
Building in links to non-mobile friendly content: How many times have you accessed content via a mobile device, only to find it is a huge image or substantial document that has to be downloaded? I'll bet that this irked you. Make sure your content is suitable for downloading on different devices. On a broadband connection for a desktop, we might think nothing of using 100Kb images; try loading these over a 3G connection, and it is easy to see why we need to reconsider what we've previously used on standard broadband connections.
Ignoring performance: In an age of modern broadband connections, it is easy to be complacent about what is made available for download. If we think desktop first, then we will be building ourselves a real problem when it comes to designing our mobile site! We can't compress a desktop environment into a mobile experience—it won't be efficient, will offer poor user experience, and ultimately lead to a drop in conversions in sales. To avoid issues with performance, we should aim to use a minimalistic or mobile-first approach, as the basis for our site designs.
Testing: A common error to make is not sufficiently testing our solutions on multiple devices, running them prior to release will uncover any UX issues that need to be resolved before making our solution available for general use. A sticking point is likely to be the question of how many devices we test for. If we have access to analytics for an existing desktop version of the site, then this should give us a starting point we can use to double check our design is working as expected. Failing this, we can make use of device emulators in browsers to run some basic checks. We can also use online testing services, such as MobileTest.me (http://mobiletest.me), to ensure our design is working sufficiently to release for wider use.
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.
