I hate responsive design.

Before you get your pitchforks and start lighting torches, let me do some explaining.

To be clear: I hate responsive design as a user. And I don’t hate everything about it. But there are a number of responsive design tropes that are inexplicably popular, all of which seem actively hostile to my browsing behavior.

So I’m gonna complain about them. Brace yourselves.

(Disclaimer: whatever free WordPress theme I’m currently using probably does some of the things I’m complaining about. I disclaim all responsibility for this.)

First, some context

The development of responsive design came about for a lot of reasons, but I find myself tying its ubiquity to a few specific things.

The first thing that comes to mind was a spate of practitioners sharing and writing about Google’s 2009 Browser Size tool, which helpfully reminded us that, yes, resolutions below 1024×768 still exist and a lot of people still browse at that resolution.

Second, the heartache associated with designing and maintaining multiple versions of a website and using a tool like WURFL to handle device detection and trigger appropriate redirects (and other device detection sadness in general).

And then the iPad came along with its desktop-like resolution and just screwed everything up even worse — not to mention the endless proliferation of devices with different quirks and expectations when it came to rendering web pages.

Anyway, responsive design is good because it sidesteps most of these issues. Responsive frameworks allow you to design a site with one set of design principles plus a little bit of extra dressing, and yield a site that will work at any resolution on just about any modern browser. It solves the problem of multiple devices and multiple resolutions pretty elegantly. So that’s good.

The anti-patterns

But responsive design seems to have inspired a number of design patterns that are Just Plain Bad, and also bizarrely widespread. And they’re so bad that I’m inclined to call them anti-patterns. This term is usually reserved for software engineering, but I think it fits here. In his 1998 book Process Patterns, Scott W. Ambler gives the following somewhat oversimplified but generally reasonable definition of anti-patterns:

… common approaches to solving recurring problems that prove to be ineffective.

…which I think is a match.

Before we launch into the tirade proper, a little more context: I’m almost always browsing websites on a desktop or laptop PC running Windows. I’m an inveterate keyboard navigator. I tend to have about 60 browser tabs open at any given time. I do a lot of link sharing. This might influence the level of attention that I give to these design patterns in particular, but I think the criticisms hold regardless.

The other thing to keep in mind is that these tropes, while prevalent in responsive design, are for the most part not intrinsic to it. I do think that they emerge from some bigger picture responsive design notions (e.g., “mobile first”) that are either misapplied or taken too far.

1. Fixed site headers

Let me begin by saying that I get fixed site headers. It makes perfect sense, especially in a mobile environment. Your branding stays in the window, you get to have your site menu handy all the time, those useless social-sharing buttons are easy to access. It’s not unreasonable.

But fixed site headers seem to bring out the worst in designers. First, there’s the cutesy animations that often occur when switching between the full site header, when you’re at the top of the page, and the scrolling version.

The part that really burns my bacon is that the site header is screwing up scrolling with the spacebar/pagedown keys. Browsers have a pretty standard approach to keyboard scrolling, which usually keeps 3 lines of text from the bottom of the page visible at the top when you spacebar-scroll. But in responsive websites, the whole browser window tends to scroll while the site header is position:fixed, floating over the body. So when you scroll in one-screen increments using the keyboard, some of the text that should have been visible is effectively hidden behind the site header. For many sites this isn’t enough to obscure new text as it comes in (though it’s enough to be disorienting), but some sites have a site header that’s so tall that new lines of text get hidden as you page through.

This is made worse if the site also has a fixed footer. For some goddamn reason.

Offenders: Just about everyone.

The fix: First, don’t make your site header change size as I scroll. That’s just obnoxious. Second, don’t float the header over the scroll area. Why not make just the article body be the portion that scrolls rather than the whole window? (There might be a valid CSS reason why this isn’t reasonable — I’m not a CSS expert.)

Medium does a kind of nice alternative. The site header hides itself when you scroll — until you start scrolling up. Then the site header appears again. It actually drives me nuts visually (surprised?), and I’ve got some issues wit the implementation, but it’s a reasonable compromise.

2. Intercepting keyboard navigation

Whose bright idea was it to make the left and right buttons navigate between articles? There’s so much wrong with this one that I don’t know where to begin. Here’s a hint: No one ever wants to navigate through articles using the left and right arrow keys. No one. (Yes, I’m sure there are people who do want to do this, but if you navigate between articles using the left and right arrow keys, you are dead to me.)

This one is just a basic error/error-recovery disaster. I’m often scrolling using the up and down arrows, or the pageup/pagedown keys that live to the upper left and upper right of the arrow key cluster. It’s easy to accidentally hit the right arrow key when I meant to hit pagedown. And if I accidentally press and hold the right arrow key when I meant to use the down arrow, I get to enjoy my browser doing a seizure-inducing journey through all of today’s articles.

(I don’t know, is this some mobile-oriented thing? Do sites let you swipe left and right between articles and they are trying to bring that to keyboard users? I don’t often  browse websites on touch devices, but when I do, I don’t want to switch between articles with a swipe.)

Variations: Some websites, in particular New York Times, don’t just scroll the browser window when I hit spacebar or pagedown. Instead, the site captures the keyboard input and triggers a javascript-animated scroll effect. It’s laggy and slow. Don’t do it.

Google also loves to mess with keyboard input. In Gmail, even with its keyboard navigation features turned off, using the arrow keys does a kind of cursor-based navigation through your email instead of scrolling. Look, I turned Gmail’s keyboard navigation off for a reason. And the other day, I managed to accidentally cause the same thing to happen in a Google search. (Luckily, it doesn’t seem to do it by default, and I’m really not sure how I caused it to happen in the first place.)

Offenders: NYMag, The New York Times, Google. To be fair, designers seem to be getting this one now. A lot of sites that used to do this (Gawker Media was an early offender) don’t seem to do it anymore.

The fix: Don’t. Just don’t.

3. Infinite scroll with dynamic URL changes

To be clear, sometimes having dynamic URL changes in an infinite scroll setting would be highly desirable (I’m looking at you, Summon). But it needs to be done with care.

The offending behavior looks like this on a newspaper or magazine website: you reach the bottom of an article, and the site just keeps going on to… another article? And the URL changed? I was just about to copy-paste that URL.

Also, this seriously messes with browser history. If I scroll down and a URL change gets triggered, all of a sudden hitting the back button doesn’t do what I expect. It gets worse if you try to scroll back up to retrieve the original URL, then decide to use the browser back button.

Offenders: Bloomberg, The Intercept.

The fix: Again, just don’t do it. If I want to navigate to a new article, I’ll click something. If you want to make a recommendation for another article, put a link at the bottom, but don’t load in a new article.

Honorable mention: Dynamic picture and text loading

This is another one I get. It makes sense in mobile. You load a page, and the pictures don’t load until you scroll to them. Sometimes parts of the text below the fold don’t load until you scroll. If I were paying by the megabyte, I wouldn’t want to load pictures until I got to them either, especially if I never ended up reading the article.

But I’m a wifi user. And I often pre-load articles to read later (remember the 60 browser tabs?). And “later,” in this case, often means while I’m on the bus, with spotty or nonexistent wifi.

To be fair, I can suffer through the lack of loaded pictures (sometimes). But not loading the text? That just seems ridiculous. Especially when the web server has already delivered about 15 megabytes of ad-network javascript.

Who gets it right?

NPR. Of course. There’s the nearly inevitable sidebar in non-mobile view, but other than that, no header, no infinite scroll, no other funny business. Just clean web design that looks good and works well at any screen size.

Parting thoughts

To be fair, responsive design as a paradigm on the web is still relatively new, and I’m sure there are web designers who are far smarter than me who are working on striking the right balance when it comes to features like the above. That said, it’s still unclear to me whether responsive design as a whole, as it’s currently implemented, is the Way to Go for streamlined universal development on the web. I don’t have any bright ideas for alternatives, but I do have (sigh) the optimistic sense that one way or another the user experience on the modern web will tend towards the better.