On the tools of our trade
This year I’ve been making a conscious effort to change my tune when discussing particular methodologies and tools used in our fine art of website making.
When we launched Passenger Focus at Browser I wrote “A Responsive Design Case Study” and for me it’s the best article I’ve ever written on this blog. I present my design and front-end development practice with the actual results to show (a rare occurrence). This is so important when advising a particular methodology. In this case rather than telling people that a separate “mobile” websites is a bad idea, I’m showing that a single responsive website design works wonders.
Tools on the other hand are a means to an end. The final website is all that matters once completed. It’s perfectly ok to have an opinion on how to get there — I fully encourage sharing ideas — but don’t tell me I need to do something a certain way simply because it works for you. Show me how and I may reconsider my practice.
Last month Andy Clarke wrote about his and David Roessli’s work on the new ISO website. Not only does he discuss the process and show the final outcome, he also allows you to download the build. I know that Andy uses the LESS preprocessor and is an advocate for “designing in the browser” — a tool and a technique I find difficult to use and even understand — but how can I argue that he’s doing something wrong? I can’t. It has evidentially worked for him. By sharing his experience he gives reason to heed his opinion, as assertive as that may be. Even better would be to present the facts and allow the reader to make up their own mind.
Daniel Eden is not a fan of CSS preprocessors. He’s very vocal on his distaste for them. That’s cool, it doesn’t stop him making websites his way. What I do take exception to is comments like this (emphasis mine):
People don’t seem to get it when I tell them that it feels to me like if you’re relying on tools like LESS or SASS, you’re going to cause yourself problems and enforce potentially bad habits. You don’t need tools — you just need to write better CSS.
Dan’s arguments are weak. He even resigns himself to the fact that he’s not well versed in preprocessor usage:
Your arguments are weak.
I know they are. I also know that I’ve probably been using these tools completely the wrong way. On top of that, I know I’ve not been working on a large-scale site, where these tools most likely come into their own a lot more.
Fair enough, he raises several well documented bad habits in which preprocessors are used poorly but what does that prove, that every user of said tool is merely “faffing around”? What is true is this:
The bottom line is — as it is with most things — it depends. It depends on the size of the project, the number of people on the team, and a huge variety of other variables. All I know is that I don’t like them. But maybe I’m doing it wrong. I just feel like the long, hard, stupid way makes more sense to me.
“It depends”. Of course it does, so why bother trying to convince people they’re doing something the wrong way by using a tool. That they “don’t need tools”? Many people do in fact find these tools helpful otherwise they wouldn’t be using them.
Unless you have a very compelling argument — potential misuse is not one — don’t try to argue against a tool simply because it doesn’t fit your workflow. Instead, present what you’ve done and how you achieved it. Present a genuine case and make suggestions with humility, then I might reconsider what’s in my toolbox.
