hype the hype

The web development community has grown considerably these past few years. While definitely not a bad thing, it introduces a couple of fresh problems that need to be dealt with. One of those problems is visibility. Everyone wants to be noticed and with more and more people competing for attention there has been a surge in boiler plates, mini frameworks, code projects and artificial hypes, ... whatever is necessary to make your work feel big and important. Where you used to just share a bit of code in a blog article, you now need a project on github with a fancy version number and a snappy project name, otherwise people won't pick it up.

All this hyping has lead us to a less critical perception of some of the tools we promote so vehemently. Last week I caught an audio interview between Jeffrey Zeldman and Faruk Ates discussing modernizr. I say "discussing", but what I real mean is promotional talk. They didn't even raise the issue of partial/faulty browser implementations of new features, instead they sold the framework as universally future-proof. I guess you just can't be critical of your own work anymore or people will look elsewhere. Stuff like this bothers me, which is why I think it is time to point at some of the dangers of responsive design. Because even though the concept of responsive design holds a lot of promise, it can go horribly wrong too if you're not careful.

responsive

So what is responsive design? Well, leave out all the subtleties, cut out the buts and ifs and what Joe Average remembers is my site looks different on my phone. In reality though, things are a bit more complex. The idea of responsive (in contrast with adaptive) design is to define a couple of different contexts up front. Think of it as having several cubes with different sizes where your site should be made to fit in. For each cube you need to decide how to reorganize your webpage so it fits as nicely as possible.

To accomplish this we use css media queries. Using a list of possible parameters we define a set of contexts. For each context we (over)write some css rules to change the structure and visualization of certain components. We can even add some fancy javascript if needed to make the transitions between different states a little easier. As you can see, the whole concept of responsive design leans on the flexibility of the css media queries, which at this time is rather poor. You can play around with dimensions, orientation and color depth (yay!), but that's about it.

translating mobile to media queries

So going back to our example of developing a site for mobile devices, where do we start? Well, the "mobile" experience is usually defined by three parameters that differ greatly from the desktop experience. The most visible is screen estate, the second (and equally important) one is performance and the third one is interaction. Looking at the media query options we have though, there's only widths and heights to toy around with.

So targeting "mobile" in responsive design is actually defined by browser/device dimensions. There is no way to decide anything based on connection speed or means of interaction. If you target on device width/height you are somewhat limiting yourself to industry standards (hoping there won't be any exotic variations out there), but if you target on browser width/height you run into the chance of changing the desktop experience too (which can be very bothersom, unnecessary and unwanted).

but that is not all

There are more glaring issue though. Trying to figure out how to define the right amount of different contexts can be quite tricky. I've seen sites that shift layouts every 50 pixels or so, which is damn annoying. But when only defining two separate contexts, you might be limiting yourself a little too much. On top of that, deciding what components to cut and what components to move around is another really tricky issue. Of course these are mostly trademark UI problems, but when done wrong or when handled by people not fully competent to tackle the task, the results can be disastrous for your site.

Another interesting problem revolves around big screen sizes. Nowadays responsive design is mostly targeted at fitting sites in small screen estates, but there's a whole range of possibilities to fill up redundant space on large displays. At least, if such a thing is actually possible without confusing/annoying the hell out of your users with each design transition.

For now I believe it is best to try and match a design per device. This pretty much eliminates the use of browser widths/heights in media queries, but I just don't think it's a good idea to throw around the design of a single site on a single device during a single browser session. When I resize my browser window I'm not hoping to see any structural or visual changes on a webpage, and whenever that does happen I'm usually disappointed with the result.

If we're not careful with this and the current tred continues, I hope they will start introducing browser plugins for ignoring media queries soon.

conclusion

Responsive design is a grave responsibility. You are deciding how and how much of your site a user will see in his current context. It's the first time a designer has to decide on a set of different contexts, where before we just had to deal with the limitations of our tools. This adds a lot of new responsibilities to the task of designing a website and if you get it wrong it can effectively ruin the whole experience of an otherwise good site.

Technically media queries are still very limited and even though the concept of responsive design holds a lot of potential, I'm sure it's way too early to tag it as the new industry standard. For now it works quite well when the use cases lay far apart and are easily distinguishable, but whenever people try to show off more complex stuff the concept falters and the result is nothing more than an impressive tech demo massacring an otherwise decent site.