Responsive, it’s how the web should be, it’s how the web was. Not everyone is a convert though, which is fair enough. It’s tricky, and some of the advocates aren’t being as helpful as they think.
Designing the browser is a terrible solution.
Designing in the browser. It’s the next big thing! It’s essential to responsive. If you can’t do it you’re not a real designer. This attitude doesn’t help responsive at all, it’s divisive, unrealistic and hampering design outcomes.
- One person doesn’t scale
The first issue I see which this approach is it’s scalability. If RWD is the future of the web, then it’s going to have to apply to more than just web designer blogs and agency sites, sadly these two categories are disproportionately represented in RWD. In these cases, you can have one person responsible for both design and development, however once the project gets bigger than this, it doesn’t scale.
Having a good working knowledge of HTML and CSS is good for designers. An appreciation of UX, design and typography is good for developers (which is not acknowledged often enough). However it seems like designers have got sick of working with developers so are now trying to do everything themselves.
Responsive should force the process to be a lot more collaborative than that. Designers need to work a lot closer with developers, the process needs to be less waterfall, more agile, in order to produce something beautiful and possible. While I’m advocating separate teams for design and development, the other extreme, when separate companies are responsible for design vs development, is no longer acceptable. Design companies need to realise that front-end development is part of their remit, out-sourcing this will only lead to poorly implemented designs, dissatisfied designers and underwhelming web design.
- Design is being hampered
While some argue designing in the browser is how the design process needs to be, there have been some reactions from the design community which need to be listened to. Knowing too much about the tech limits the design possibilities, it’s too easy to fall into doing the same thing we’ve always done. Creating boxes and then rearranging those boxes on smaller screens is not design. I believe the push for designing in the browser contributes to this problem. Is responsive to blame? No. This is a natural reaction of designers and developers attempting to get to grips with new tech, however we must get back in control.
Tech is our servant not our master, when we put tech first, rearranging boxes is a natural symptom. Separating the design team from the development team is good for everyone, especially design. I believe it’s better for the designers to try to create something without too much thought about how it’s actually going to work, as that pushes the tech further than starting with the tech and working back. Designing in Photoshop or Fireworks does produce constraints (notably fixed width), however it also gives some independence to the tech, which puts design back in control. The question designers should be asking throughout the process is “Can we do this?” not “What are we allowed to do?”.
- Mobile first isn’t for everyone
Another part of what’s holding responsive design back is the mobile first philosophy. Its the right development philosophy but it’s the wrong design philosophy. When you start with the simplest version (small screen) it seems like the desktop design suffers from being too similar to the small screen design, which then ultimately looks like rearranged boxes.
- Reality is…
Now let’s not throw the baby out with the bath water. You can’t make every design decision in Photoshop or Fireworks. However, that doesn’t mean you make no decisions there either. This is a team process. Developers, it’s time to step up, learn some design, become pedantic, and stop trying to make your job easier (read boring). Designers don’t let the tech limit you, push it, and then be prepared to step outside of your toys and negotiate in the browser with developers, they’ve got something to add too.
The false economy of responsive out of the box
There’s so much talk about new CSS libraries, grids, frameworks etc, it’s not helping. In fact it’s sending us down a dead end street. They’re great for prototypes, not for prime time, none of them allow for the inherent flexibility of responsive. I was an absolute convert to using utility styles, ever since seeing a Nicole Sullivan talk I’ve loved the idea of OOCSS. I spent two years working on my own set of utility styles which project by project got better and better, faster and faster. I’ve thrown that work away. It’s doesn’t work for responsive.
- Utility ain’t the future
While I used to have have a .grid_4 class, when I’m using responsive I have no idea whether that item will still be 4 columns wide at a different breakpoint. Or f_left (float:left), will it be floated at a large screen or a small screen? Assuming both isn’t going to work. The only reason this approach may be working for you now is that designers have yet to really push how different each breakpoint can be.
- Let’s be helpful
The problem with a library or framework is that by definition it’s not responsive. It’s not responding to the design, it’s dictating the design. This approach won’t last. I’m all for helping make things easier for people to start doing responsive, however not if it’s a dead-end street. Context styles not utility styles seems like a better approach, which means less code re-use but more flexibility between breakpoints.
Context styles: div class=”nav_secondary”
Utility styles: div class=”f_left grid_3”
Bad browsers are the past?
We’re all very happy that browsers like IE6 and 7 are slowly melting away like a bad dream, but utopia isn’t here yet. We’re still in the wild wild west, the web has yet to stabilise. We all know that testing on real devices is good, however trying to find answers about how to debug all these new browsers is going to take time.
- The old has gone, the new has come
I’m loving that clients are now dismissing IE6, and some of mine are starting to think the same way about IE7, the reality is testing isn’t getting easier. We have more browsers and more versions to test in. Testing each browser, in each version, at each size, takes time, significant time. I had IE7 and IE6 testing down to an art form, I knew the bugs, I knew the fixes. Now I have phones to contend with, Android I’m looking at you.
- In theory it’s good…
The last responsive project I worked on, the site didn’t have enough Android traffic to justify spending the time to test and fix any issues (they’re monitoring this, it will change), and testing was a breeze. I’ve loved testing iOs, every now and then it throws up a wee gotcha but overall an absolute pleasure. The project I’m now working on has significant Android traffic. So I got some Android devices, 3 of them, one Android 2, one phone Android 4, one tablet Android 4. What a debacle. I know feature detection is the way forward but quite frankly Android browser lies, it’s supposed to be CSS3 ready, it’s not. Android is my new nemesis, I’ve had to revert to user-agent detection in order to work around the issues, it’s IE7 and 6 all over again. It’s still the wild wild west, browsers aren’t ready for what I want to throw at them. This isn’t our fault, we’re pushing browsers manufacturers to do things faster than they can keep up. One of these days testing is going to get easier, but we’re not there yet.
- Lets be honest
It’s nothing to do with responsive per se, perhaps more about mobile as a whole but getting complex navigation working on such a wide range of devices is tricky. Adding touch support and not screwing up all your click events is tricky. Animating linear gradients while animating their container is tricky. I could turn around to my designers and start telling them what to do, but I’m not going to. Getting a design which you have no idea how to build and figuring it out is the best part of this job.
I hope you get that I love this, I absolutely believe responsive is the best thing since sliced bread. I love it when a designer says “Not good enough, lets try again”. I love challenges. Sure I’m going to hate moments of it, like when I have to revert to user-agent testing in order to get something working consistently. However, in some ways I think it sorts the men from the boys, anyone can throw some CSS together, there’s 12 ways to do anything. However managing the complexity of multiple breakpoints, complex design and more browsers, means that planning, best practice and experience are needed.
So let’s not dumb it down, libraries don’t solve stupidity, they encourage it. Libraries aren’t the future, they’re just helping us cope with the present, but as soon as designers catch up, we’re in trouble.
Designing in the browser really has nothing to do with responsive, it has everything to do with team size, stop encouraging people to be a silo and start encouraging people to communicate, get better at their craft and work successfully with others.
Let’s stop kidding ourselves the web is mature, things are still pretty ugly, browser testing for one isn’t easy.
I love that this isn’t set in stone. I love that there’s not one way to do stuff. I love that the way to do stuff now won’t be relevant next year. We live in a pretty exciting time, so lets embrace it, warts and all. Let’s keep pushing things until one day some kid you work with has no idea what zoom:1 does.
On a side note, to all the people who complain about the maths!? Quit your job and become a gardener, this isn’t the career for you.