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.
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.
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.
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.
<!– Some Content –>
<!– Other Content–>
<!– 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
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
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 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.
Testing – All over again
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.
Latest posts by Kyle Pennell (see all)
- Falling Back in Love with the Front End: An Interview with Azat Mardan - May 18, 2017
- How WebRTC Has Changed Web Communication - May 11, 2017
- The Angular CLI: A Simple Way to Fire up an Angular 2 Project - April 18, 2017