A question that comes up here time, and time again is “should we go responsive?” followed by “what are the pros and cons?”. Of late, this comes on the order of nearly every project. As such we thought it warranted a quick blurb on why this technology is a bit more than a passing trend and rather a way it “should” be done moving forward.
First, let’s cover what it is for anyone who does not already know. In short, it is a single base of code that will determine the device you are on and make visual, and often times information architecture, changes accordingly. Said another way, this means that if you are viewing a website on a mobile device or a desktop you can, and often will, view different versions of the same site. Enter pro point number one, and likely the most important, that we only have one website to worry about. The admin (who often times has no clue what the back-end looks like, much less cares how it was made) will look to tick the site update off their to-do list as quickly as possible. Multiple code bases means multiple points of entry and likely means things get missed. If it all comes from the same place, problem solved.
This dovetails with the second biggest benefit which is a planned-ahead strategy for what the visual vernacular of your site truly is. This means defining elements ahead of time (by a designer and/or information architect instead of a project manager or other admin with very little, if any, vested interest in the visual output of the site). Loosely translated this means that no matter what comes up, micro-site, form element, contest, and the like, the site already “knows” what to do and responds accordingly. No guess work, just right.
Last, and likely more important to the non-tech folks around, is the SEO benefit. Not having multiple code locations for various devices means that each SEO’d URL is identical so there is absolutely no guessing where things are going. Think back links here folks. It is hard enough to get them regularly but not think of trying to get one for url.com, one for m.url.com, etc. No thanks.
There are cons too. Let’s start with the biggest one; cost. Making a responsive site is a lot more work both mentally and tactically so yes, this costs more. More templates, more involved information architecture, more design layout decisions, more of everything. Depending on what you are doing and how complex it is, it could be a lot more. The bigger your site, the more it will cost to make responsive.
The changed effort also means that this is far different from your “typical” experience so it is bound to ruffle feathers. Imagine if we said to you, “this is going to cost more but also the process you have followed for the last 10 iterations of your website will also be different.”. Now imagine trying to relay that news to your boss who likely barely understood the last 10 iterations of your website. Not a great proposition. This is the largest stumbling block we see.
Next let’s talk download time. All of a site’s assets are downloaded regardless of what device we are talking about. As mentioned earlier, not everything is shown and the sites do often look very different but the fact remains all of the data is still there. This could mean extended download times on a mobile device.
In the end however the cons are far outweighed by the pros for a few reasons. One, this is the inevitable “right” way to build sites we will see until a different production paradigm is crafted. When technology changes again, we will no doubt get a new “right” but for the foreseeable future, this is by far the most superior production methodology available. By extension, the higher cost of initial production, just as an example, will be mitigated over time due to the fact that there is only one code base to keep up. This means that all future changes are avoided as they are done through the responsive system already in place.
Every project is different to be sure so on your next project, this consideration should be high, very high, on your priority list.
