Responsive web design is a technique; a means to an end. Nothing more. It is not the Alpha and Omega, a magic bullet to create the perfect user experience in all situations.But at the same time it is a very powerful set of techniques. It offers front-end developers easy-to-master methods (essentially just HTML and CSS) of offering a more compelling visual user experience, regardless of the browser viewport size viewing it. It might be a TV, smartphone, tablet or virtual wrist browser; a responsive web design won’t care. Admittedly, there is no virtual wrist browser I’m aware of, but I’m convinced a responsive design would have the best chance of looking good on that too. The thing is, a good responsive design doesn’t (or shouldn’t) make assumptions about the device. It doesn’t just cater for 320px and 768px widths because they are the breakpoints of the current iPopular devices. It should offer the best possible experience whatever canvas size it’s viewed on.
In addition, it’s worth noting that a responsive web design relies on a single code base, rather than separate distinct ones, as is usually the case when going the ‘device experiences’ route. This can be a good or a bad thing – it’s all about what you’re trying to achieve. It may seem like a cop-out, but there’s no automatic right or wrong way to build something.
Despite this, although responsive web design isn’t necessarily always the right choice, I’d argue in the absence of something better, or without a compelling reason not to, it should be the default choice. The fact is that the amount of differing devices accessing the web is growing. That’s a trend that shows every indication of continuing. As a developer, do you have some capability to respond to that situation and offer a better experience for users on all devices? If not, learning the techniques of responsive web design offers you some capability to do so for a meagre learning curve. For that reason alone, it is worthy of your attention.
However, the important thing is this: a responsive web design isn’t the only way to provide a great user experience for users across different devices, and ultimately, that’s all we should be attempting to do. Our users visit our sites or applications for something. Let’s just allow them to do that in the fastest and most pleasurable manner we can. How well a site or application allows users to do what they came to do is important, not how we built the experience. Plus the layout presented is merely one aspect of building a good experience for users. Site speed for example, is arguably just as important, yet doesn’t get the attention it perhaps deserves.
However, just as our techniques should adapt and change, acknowledge that the things we build are temporary. People often liken building websites to architecture. The notion being that they are attempting to build something that will last. It’s a noble notion. But how many sites you built five years ago are still in the same form? Would you build them the same if you had to rebuild them now? Would you build them the same way in even two years time?
We’re not architects. The things we build won’t last: accept that. We build sand castles. They are here for mere moments, marvelled at and enjoyed if we are very lucky, then washed away. That doesn’t mean we shouldn’t strive to build things more beautifully and functionally than those that have gone before, and employ the best practice ways in which to do so. But do it because doing so makes it easier for you to build what you need, easier for fellow developers to extend your work, and ultimately because it makes the user experience better. Don’t labour under the illusion that what you build and how you built it will stand the test of time: it won’t. So just use the tools available to you to get the job done.
What we use to build websites and applications for the plethora of possible devices is ultimately unimportant. That we have some means to build them at all, and that people can hopefully use and enjoy them, however transient they may be, is.