Yes, I hate responsive design. And I say that as someone who codes almost all my new sites responsively. I do it because it’s what clients think they want and because it’s what Google expects. But I still hate it.
When Web-enabled devices first came out, I jumped right on the “m” subdomain bandwagon. For those of you who don’t remember it, that was back when we did the sensible thing and coded mobile versions of our sites and put them on “m” subdomains. So this site’s mobile version would have been “m.geekonthehill.com.” Mobile users would go to the “m” subdomain. Everyone else would go to the root or “www” site.
I thought that was a great solution. Mobile browsers were very rudimentary back then and data speeds were slow; so a version of a site that was stripped of unnecessary images, scripts, and other elements that would slow down a mobile user’s browsing, waste their data, or crash their browsers could be banished, while still rendering the important content. It was a very good way to meet the needs of both desktop and mobile users.
Another advantage of the “m” subdomain was that when implemented in an optional way (that is, not forcing either the mobile or desktop versions based on browser, connection, or viewport sniffing, but letting the user decide), desktop users who were on dialup, ISDN, slow DSL, mobile tethers, or 3G routers or hotspots could select the mobile versions to speed up their experiences and/or reduce their data consumption. Yes, mobile sites looked a bit goofy and sparse on desktop browsers, but many users on slow connections preferred that experience to waiting ages for every page to load (or wasting their data if they were on 3G routers).
In terms of what I call critical content — the information that users went to the sites to obtain in the first place — that could be easily synchronized by drawing it from the same databases or files as those that fed the desktop versions, and using CSS and scripting to adapt the content to the mobile screens. But the rest of the elements of the mobile design would be isolated from the desktop version to prevent “heavy” elements from being downloaded if they weren’t going to be displayed anyway, and to substitute “lighter” elements such as lower-resolution header images to speed up browsing and to be considerate of mobile users’ data usage.
Conversely, using the “m” subdomains also allowed the desktop versions to be as pretty and fancy as a designer liked, as well as to retain elements like horizontal or vertical menus and hover effects that either detract from the mobile experience or simply don’t work at all.
Yes, some of this can be done using responsive design, but it’s always a compromise. It also wastes a lot of time trying to figure out not only how to reshape the experience so it either works or disappears in all viewports and on all devices, but also how to be mindful of data usage. Ideally, the designer not only wants the rendered site to suit the browser in question, but to avoid wasting the mobile visitor’s data to download elements that are unnecessary for that experience.
I’ve been coding responsively for about five or six years, and I suppose I’m as competent at it as most designers. The sites respond predictably in various viewports and on various devices. But they’re not as pretty as I would like them to be. They lack artistic elements that I know how to implement and which I think would enhance the sites, but which I can’t use because either there’s no way to scale them to mobile, or because they’d look like shit if I did.There are some things that work on big screens that don’t work on small screens. It’s really that simple.
If I code the heavier or desktop-optimized elements to disappear on mobile viewports, then I get complaints from clients (and occasionally users) that the desktop and mobile versions “aren’t the same” as the desktop versions. How stupid is that? That’s like complaining that a Kia Soul isn’t “the same as” a tractor-trailer. Of course they’re different. But as long as the essential content is there on all the versions, why the complaints? If you want to see the desktop version, use a computer. If not, you’re still getting the important content on your postage stamp-sized phone browser. So what’s your beef?
Another problem with responsive design is that it requires the use of more JavaScript than I personally like to use. I used to be a computer technician, and I’ve seen what computers that are infected with malware or otherwise ailing can do to JavaScript. On a dedicated mobile site, I can keep the scripting completely server-side. That’s not an option on a responsive site.
Ad blockers can also play havoc with client-side scripting. I’ve written menus, for example, that dumb-ass ad blockers blocked because they were too stupid to distinguish a navigation menu from an ad. On my own ad-monetized sites, I just leave them that way. If people want to block my ads, fuck ’em. I really don’t want them wasting my bandwidth anyway, so not being able to navigate the site is a plus. But on client sites that don’t even have ads, I have to dumb down the client-side scripting so that it doesn’t trigger ad blockers. It’s one more annoyance that I could live without.
If I had my way, we’d still be using the “m” subdomain for mobile sites. In my opinion, it allowed designers to do what we should be doing: designing sites that are optimized to work well in every user’s environment while being mindful of things like browser limitations, speed consideration, and data caps. Those are things that we can do only partly and imperfectly using responsive design. It’s always a compromise. It all-too-often results in the desktop versions being ugly and uninspiring, the mobile versions being wasteful in terms of data use, and all versions being bogged down by JavaScript that would be unnecessary if the different versions were independent and discrete.
But I guess that’s what people want nowadays. The one-size-fits-all mentality has become so pervasive that it infects even the way electrons are moved around in cyberspace. Personally, I pine for the days before “ugly” was considered a design statement, and when designers considered both appearance and data efficiency in building sites that were optimized for every user’s experience.
Richard