I recently reworked the responsive code on our own website and the occasion ‘occasioned’ some thoughts…

Since 2010 or so ‘Responsive Website Design’ or ‘RWD’ has been a raging topic in the world of interweb design. The idea that a website’s appearance can be seamlessly tailored to suit the resolution and layout of multiple devices – desktop monitors, phones, tablets, etc – is at the heart of RWD. More broadly, it’s really the idea that our designs on the web must be perceived as device independent. I think it’s fair to say that RWD is as much as State of Mind as a technique.

I’ve now built RWD techniques into both client websites and our own, using various techniques and I offer the following takeaway observations:

1. Like every trend in digital, once the concept takes root within the client community, everyone starts asking for it, yet no one understands it. I can’t believe I just wrote that but, sadly, it’s a truism. Once RWD became popularized, nearly every client of ours now asks that their new site be ‘responsive’ on mobile. Definitionally, this request carries much risk for the designer. There is no universally agreed upon notions of what websites should ‘look’ like on mobile vs. desktop. Sure, there are some obvious issues to address (like navigation elements working correctly in smaller, touch-based situations) but this issue, like many, boils down to subjective decisions regarding art direction and function, as well as real world limitations on budget. RWD creates yet another pool of quicksand for, especially, smaller firms who are trying to design something memorable on a limited budget. (More on this in Item 3.)
2. Ethan Marcotte is right. When I first set out to write the responsive code for our own site, I used what’s called The Goldilocks Approach. This approach differs somewhat from that recommended by Ethan Marcotte, who first popularized RW, in that Goldilocks uses ‘ems’ to declare widths within different device resolutions, where Marcotte outlines a system which uses percentage-based widths. While I’m sure Goldilocks can work, I found lots of problems as I tested the system on mobile. Basically, I found that different devices interpreted fixed ‘em-width’ based designs very differently and I got a lot of weird visual results. For this reason, I re-wrote the code using the better-known width-based approach, which really works very predictably across devices. I guess that $22.50 was pretty well spent.
3. It really costs a lot. One of my chronic annoyances about trends in website development is that those trends get preached as must-have, Holy Grail sorts of things when, in reality, cost is given little consideration with regards to practical applications. Most of the ‘big ideas’ in our industry come out of big agency work with larger clients. RWD, doubtless, is great for clients like the Boston Globe. In my own experience, I note that it took an additional 40 hours to code a reasonably smallish site like ours for RWD. In my humble estimation, RWD, properly implemented, can easily add an additional 30% to a development budget. The problem with this is that, the same clients that came to us two or three years ago with a twenty thousand dollar budget haven’t increased the budget to suit the requirement of an RWD-enabled design. Hence, my final thought…
4. Frameworks might be the answer on a budget. For small, but custom clients, I’ve started building sites off of Bootstrap. I’ve written about Bootstrap before and, yes, it does have its limitations. Mainly those are pegged as the ‘sameness’ which a lot of Bootstrap sites seem to possess. But, really, that phenomenon is a symptom of designer/developer laziness and not a flaw of the framework, I feel. People have done marvelous work on Bootstrap and the framework can be easily customized. Just like a fully ‘bespoke’ site, you can always write unique JavaScript, tinker with breakpoints, etc. And the beauty of the framework is that the client gets to notch off their ‘RWD’ requirement and can view the site at various test resolutions during the development process.