In keeping with the Roach's desire to look after all his subjects…er fans… equally, the Roach has been most troubled by the fact that his site is not best viewed on various smartphones. His first response to this problem was to remain unresponsive, and question the smartness of smartphones instead. But then that is not a user-friendly approach, and deeply troubled the usability evangelist within him. Hence over the last month, he's been digging deep into a concept called Responsive Web Design.

Responsive Web Design (RWD) says whatever you create should be usable on any device and at any resolution, without requiring you to create separate versions of the site/app tailored for them. It has its roots in Fluid Grid Systems and Progressive Enhancement, and is currently the buzzword doing the rounds.

But there is a problem with the knowledge-based industry. Given the intangible nature of everything we work on, we have become the masters of marketing things that don't really exist. We are dream merchants, almost, and hype is our best friend - until it's time for us to live up to our claims. One man's hype becomes another man's headache very quickly then.

I suspect RWD - at least what is being called RWD today, has suffered a bit of this.

As a concept, RWD sounds great - you design and build web applications/sites without being influenced by the device a user may use it on - so you basically are not restricting your design to work well on a few devices, thereby being able to cater to everyone on any device. Apart from allowing you to make your app/site universally great for everyone, it's also supposed help save money as it doesn't require you to make new versions of your site every time someone like the departed Mr. Jobs comes up with a new form-factor, or his dreaded competition launches a new smartphone boasting a new screen size and/or resolution.

But you'll run into a few issues when you actually try putting the concept into practice. I learnt the hard way, as I bravely embarked on creating an application for maintaining my accounts (one of my favorite pastimes) that I could also use on my tiny Blackberry screen…

1. Designing without context is nigh impossible.

Not surprising at all, given that design is all about context. With a good design, you are designing for a particular problem or task, a particular environment, a particular set of people, and even a particular state of mind! Design also aims to cater to probabilities, and not possibilities, so in many ways RWD goes against everything I learned during my Usability Analyst training.

Perhaps it's just because I am new to the concept, but I felt trying to design without thinking of some kind of dimensional constraints left me staring at a blank sheet even after several hours. If you start sketching your first low-fidelity wireframe, you are in effect condemning yourself to a fixed layout that goes against RWD's fluid layout philosophy.

If you already have a site suited for desktops, and start trying to adapt that to work on smaller screens - then that's an approach that can lend some structure to your thinking. Or if you try designing for a tiny screen to begin with, things can get easier. But as long as your content is not just a bunch of paragraphs, I think some sort of device context is important.

I got around to finally coming up with something by first putting down what I would've done for a regular site, then rearranging it to fit within a restrictive mobile screen. Some people say it's best to design assuming a mobile device first, and then see how you can scale this design to bigger screens - an approach that comes from the Progressive Enhancement thinking. I personally find this restrictive and prefer to think of the super-set of content first, and then strip it down as required - this way, you don't end up missing out on something important.

I also feel that if you want to cater well to a large difference in screen sizes, it's better to make 2 or 3 sets of wireframes, to represent the different classes of devices (desktops/tablets/phones). You'll see why I say this by the end of this article…

The way you code the site can allow a fluid layout with breakpoints that rearrange content as required to match these wireframes. But I find this reliance on resolution for a design approach that attempts to be resolution independent to be a little ironic…

2. RWD assumes resolution is the key.

At least currently, the magic ingredient that drives Responsive sites is CSS3 media queries. Media queries are used to figure out what the screen resolution of the device you are using is, and to adjust some key parameters like the body font size accordingly. Seems logical, but what do you do when you come up against the new Galaxy S4, that has a full-HD resolution screen like my 46 inch TV, but squished into a 5 inch display?

All sizes to scale, including the Roach.

Starting to see how this can be quite a problem?

In my opinion, the actual screen height and width is what matters, along with how far it is from your eyes, how good your eyes are, and how fat your fingers are. A web-app should be able to figure out these things, and adapt the size of the content, buttons and navigation links to best suit your eyes and pointing device. Unfortunately there seems to be no way to capture a device's actual screen dimensions currently. Till we have something like this, I don't think anything you build can be truly responsive.

3. Interactions are out of scope.

Speaking of buttons and navigation - RWD currently focuses a lot on content, and seems to forget interactions. The fact is, desktops, laptops, and netbooks, and some phones like older Blackberrys provide users with a mouse pointer to select things. A mouse pointer, while reviled by the touch-screen tribe, allows for smaller targets, and interactive states triggered on mouse-over, which make no sense on a touchscreen. With a mouse pointer, you don't have to worry about the user's hand obscuring what they are clicking on either. So the way you design interactions for a touch-capable and a non-touch device ought to be completely different.

Then there's the stylus, and voice commands with Google Glass, and who knows what else will come in the future.

At least currently, there is no way to detect what the user is using to interact with your interface, and so you can't really make an app that works perfectly on everything, everywhere, like RWD aims for, without a degree of tailoring.

4. RWD works fine for text - but pictures? And performance?

Sure your text will scale nicely along with your fluid layout. But what about the images around it? Sure you can set your image to scale as well with a neat trick of setting the width to 100% and not specifying the height. But do you think serving up a 500x500 pixel image for a screen where it gets scaled down to 100x100 is fine? What a terrible waste! And it will definitely impact performance/load times on phones. There is some hope with Scalable Vector Graphics, but I doubt that will work for anything other than simple line-drawings like the type the Roach creates for his site.

Another problem is that everything you can see when on a desktop site is probably not needed when viewing it on a mobile. Yet, just like the large images, all this extra markup would still get sent to your mobile device over a slower connection, only to be hidden.

Clearly, RWD in its current avatar is far from ideal… and then it gets worse!

5. Responsive tables? Checkmate.

I could still ignore or work around most of the points I have raised so far; and so continued to soldier on, struggling with ems and percentages as I tried to put together my responsive Rupee Roach application. And then I ran into something that felt like I had just been hit by a size-9 Bata slipper. Being a Roach, that is not a good feeling to have.

I had a table that showed a whole bunch of info about my extensive (and thoroughly imaginary) investment portfolio - a wide table that could not be made to fit on a mobile screen no matter how you squished the data. What was required was a complete reorganization of the rows.

There are a few solutions people have come up with which seek to rearrange the columns to look like a set of fields in a form, but this is far from ideal and would not work when you have a whole lot of rows in your table.

Do you have a table for two (screen sizes)?

This last problem really got me thinking. Is RWD everything it is supposed to be? Like I mentioned in my first complaint, I had to end up designing how the app should look on a mobile, and how it should look on a desktop, because it was information and control-heavy, and not just a bunch of paragraphs that could get gradually rearranged into the required number of columns that the pixel-width of my screen allowed.

The RWD tutorials and solutions doing the rounds today just don't cut it when it comes to highly interactive things like applications - the examples are often based on really simple pages with static content, and I think that's because RWD doesn't work well for anything else.

I also think what is being called RWD today is more a "technical solution" that tries to solve the problem of catering to different screen resolutions, and is not a design solution, despite the D in RWD. I base this again on my Rupee Roach accounting app example - RWD doesn't understand context.

When I use the app on my desktop, I will probably spend long hours looking at pretty graphs that show me my spending trends, my missed saving targets, and getting an overall picture of my financial portfolio, while probably feeding a mild form of megalomania. I'd probably use it on my phone just to record expenses before I forget them. Sure, I could still want to look at the trends and stuff on my phone, but that would not be what I would be using it for most of the time. RWD can't address stuff like that.

So, as a concept, RWD is interesting. But is it the answer to everything, to be used everywhere, like the current hype around it suggests? The Roach disagrees.