The Cost of Implementing Responsive Web Design Later

Follow us on LinkedIn for our latest data and tips!

, , , ,

The Cost of Implementing Responsive Web Design Later

Dr Evil

I’ve done more than a few responsive website implementations and there are two ways that it can happen. A site can be coded responsively or you can be tasked with doing a retrofit to make a fixed-width site responsive.

Is it better to get a desktop site out quicker and then work on making it responsive as a “phase 2”? Having done both I can say that it’s a good idea to start with responsive in mind. Doing a retrofit is usually a frustrating and expensive process. Let’s look at how.

Ramping up

The first cost you’re going to encounter when implementing responsive web design (RWD) later is getting familiar with the codebase. This is true for both new developers and the project’s original developers. When you revisit past code it takes some time to get back “into the groove”.

In addition to that, you’re thinking a lot differently than you would on a mobile-first project. Normally you think of how you’re going to build or how you’re going to add on to or expand on what’s there. Now, once you’ve wrapped your head around what’s going on, you have to think in terms of fundamentally breaking down and changing how the code works. It’s a major refactor.

Style gutting

It’s easy to make the connection of time saved in your head if you’ve already got all the styles for the desktop or largest version of your site. However, we run into hidden costs when it turns out that we have to disassemble all of those styles and reassemble them in the correct order. The advantage is similar to having all of your puzzle pieces in the same box but not pieced together.

Disassembly is needed to make sure the styles are mobile first. Otherwise, you’re going to have to undo a lot of styles for the mobile view. (Ask someone who’s done it how fun that is!) What this proces looks like is slicing out specific rules and relocating them in media queries. It’s a tedious task.

Not just styles

When you think of what makes a site responsive you probably think of the CSS. It is what makes a site look the way it does and CSS is the most important part of making a site responsive, but it’s not the only thing. Forgetting other aspects can really break the user experience.

Markup requirements

Out of HTML, CSS, and JavaScript, my brain automatically ranks HTML as being the easiest and most straightforward. You put the words and pictures you want to be on the page into the HTML document and you wrap them in tags that describe the kind of content that it is. While that is true, you also have to account for structure and layout when you write HMTL.

Once you start thinking of how the CSS is going to affect the markup, it changes how you might write it. This is especially true when creating responsively. You have to consider that the module you’re structuring may appear four different ways and on three different parts of the page. Here’s a small example.

<section class="main-content">
    <!-- Some Content -->

<section class="secondary-content">
    <!-- Other Content-->

<aside class="side-module">
    <!-- tangential content -->

Let’s look at this as if this as if it’s the original markup to a site we’re retroactively making responsive. From the markup it looks like `main-content` and `secondary-content` will be the focus of the page and `side-module` will float to the side – let’s assume the CSS reflects that.

Now that it’s time to make this responsive, the new mocks show that the smallest version the site becomes single-column and `side-module` will sit between `main-content` and `secondary-content`.

While the solution here is simple, real-world pages are not usually this simple and added complexity will bring more complex problems. If we had approached this mobile first, it wouldn’t have been a problem. It would have just been a requirement that we factor into our original structure.

Retrofitting a site will introduce you to lots of similar issues. (And if you have to do a retrofit where you’re not allowed to touch the markup, all I can say is I’ve been there and I am very sorry.)

Responsive JavaScript

Responsive web design changes the way you think about web pages. Since you’re trying to accommodate as many devices as you reasonably can, you have to consider how people interact with your site. You also have to consider (please forgive the pedantry of this sentence) how your site interacts with them.

Sometimes there are behaviors that only make sense at the desktop level and sometimes it’s the other way around. Your scripts need to be aware of the context and know when to fire and when to not. Having this built in from the beginning is handy. Building it in later is really just refactoring, which is very normal for writing code, but doing something right the first time is always preferred.

To give a recent example of this, while working with Zumba for a responsive redesign of their site, we had a module that needed to stick to the bottom of the window until you scrolled down and it fell into position. We would not want that on mobile since real estate is limited, so we stopped it from happening on mobile widths. Using a tool like mediaCheck makes this relatively simple, but the hidden cost on a retrofit is that all of your JavaScript has to be audited for similar problems.

Testing – All over again

Remember all those hours of testing, and bug fixes, and more testing? Get ready to do it all over again. You’ve just introduced new code into all three layers of your site: HTML, CSS, and JavaScript. It’s bound to cause problems that must be fixed before launch.

Are you supporting IE8? As you may know, it doesn’t do media queries. IE8 users will either get just mobile styles or you’ll need a way to serve the styles enclosed in media queries. There are several solutions you can use for this, but it’s better to do them from the ground up.

It’s more than it seems

As stated earlier, what makes a site responsive is not just style. So doing it after the fact means you are probably altering a lot of what you started out with. Did you really just update your codebase or is it more likely that you made a new site? The cost will probably look more like the latter.

Having done both ground-up responsive sites and retrofits, I can say coming to a clean slate is much more comfortable.