I do PSD Conversions for a living. In other words, I turn photoshop designs into websites – and I’ve sliced over one hundred. I’m (somewhat) of an expert when it comes to creating custom themes for WordPress.
1996 – 2010 / The Good ‘Ol Days
Before responsive web design, I only had to write one set of code. Websites were normally designed to fit large 17-inch CRT monitors at 1024×768 resolution, and my job was easy.
2010 – 2012 / My site looks crappy on my iPhone
Thanks to Steve Jobs and this article by Ethan Marcotte, my TSC (time spent coding) has almost doubled. Both mobile devices and that article single-handedly changed the landscape of modern web design. And when the giant eye of Google declared, “if your site doesn’t gracefully degrade to mobile, we’ll unleash the orcs!”
Thus, responsive web design was here to stay. At first, it was, make sure the site looks OK on my iPhone. No problem. A second set of CSS code via media queries. Kind of a pain in the ass, but I like getting paid.
2013 – ? / “Hey Greg, we want this sidebar widget, which normally does ABC on desktop – to do XYZ on the iPhone”
At this point, I’m already writing two sets of code, so why not a third right!?
Somehow, clients just expect us designers to become the white wizard of middle earth and conjure up mobile sites too. Well, responsive web design doesn’t equal mobile. Let me say it again: RESPONSIVE WEB DESIGN DOES NOT EQUAL MOBILE!
Responsive web design means I will optimize your web site for mobile viewing. In essence, your site will gracefully degrade to smaller screens.
Notice I didn’t say, gracefully enhance? That’s my whole point. Responsive web design is accomplished by using both fluid grids and images via CSS3 media queries. That doesn’t mean the client is allowed to send me a responsive PSD with a very different design. That my friend is a mobile site and yoouuu shaaaalllll not passsssss!
To wrap up
My job is to make your site looks good on mobile devices – not summon a giant eagle to fly your website off into the mobile functionality sunset.
If I (the coder) have to “enhance” the functionality of your website (based on screen width), and if that functionality is so important to you, then I suggest you pony up – and pay for a separate mobile site.
I’m not just grumpy at clients. After all, who can blame them for trying to squeeze a little something extra out during these “tough economic times”. I’m also grumpy at those responsible for scoping contracts. Times are changing. The web moves really fast, so it’s more important than ever to manage expectations.
Potential Clients: Remember, responsive does not equal mobile.
Those responsible for scoping: Tell those potential clients EXACTLY what responsive web design is – or better yet, tell them what it isn’t.
I basically agree with everything you’ve written here, but that wouldn’t have made me comment in and of itself. The Middle Earth references, on the other hand? Be still, my geeky heart! Loved the article all the more for them.
Amen. Scope of Amen: Everything I’ve ever thought about developing for browser differences in 1997, followed by moving to CSS, then followed by moving to a fluid grid (which only made sense) only to be comshawed at a later date by the “mobile-movement.” Le sigh. Thank you Greg.
I respectfully disagree with your assertion that responsive design is (or should be) about making a site “gracefully degrade” on smaller screens, or that progressive enhancement is a different concept than responsive design. The whole notion of progressive enhancement is to start with the most basic technologies, and then allow browsers to enhance things as they are able, right? So why wouldn’t larger, more complex layouts simply be another enhancement that are added when able?
For example, it annoys me that most people implement responsive design by first writing the CSS for the highest width, and then sprinkle in media queries with “max-width” rules that shift things around as the window shrinks. The progressive enhancement approach would go in the other direction… start with a single-column design that works pretty well, then add media queries with “min-width” rules that shift things around as the windows gets bigger. It’s a different way of approaching the design to be sure, but is often doable without too much extra work, and often results in a better mobile experience.
Will – since writing this blog post I am now a believer in “Progressive Enhancement”. Coupled with a Sass mixin (http://css-tricks.com/naming-media-queries/), it’s really a no brainer to start with mobile and work your way up.
🙂 cool. And I definitely like the idea of decoupling breakpoints from the exact width of today’s popular devices. The content should break wherever it makes sense… just start resizing the browser and see where things start to feel a little too cramped, or too spaced out, and that’s where you should put a breakpoint. I think I would confuse myself with some of those naming schemes, but then again I do use generated names for my CSS colors.
Here is the exact mixin we use at WDS, (the widths may vary depending on the project) but the names don’t change.
It’s easy to remember
The funny thing about responsive sites and mobile sites is that, when mobile browsing, I hate them! Horrible things most of the time.
Responsive sites tend to push all sidebars below the content and mobile specific sites tend to leave half the desktop content out of the page. I can’t be the only guy who reaches for the ‘desktop version’ every time he meets a mobile ‘friendly’ theme or mobile specific site.
Still, responsive design adds to the fun of being a web developer. Tell you what I do like: seeing how some developers use media queries for fun. I’m sure I recall seeing a website that cycles through words of a phrase or through letters of the alphabet as the browser screen is resized.