Why coding and design don’t mix, and news of two new Zen Garden submissions.
The focus on browsers lately has been good for thinking about what’s important for users and developers, and what lies ahead, but you can only prattle on so much before realizing it’s just an intellectual discussion. While the technology may change, it’s only a means to an end and what really counts is how you use it. Moving on to another subject near and dear to my heart: design.
Scott Steffens posted a thoughtful response to the interview that bears consideration. He argues that the designer is the best person to plan the layout and interaction, and one of his strongest points is that a designer who doesn’t know the code can’t possibly know what is or isn’’t possible to achieve.
I believe to a certain degree, he’s right. When designing for a technological medium, you have to consider the technology and make sure you understand its strengths and limitations.
This holds true for any medium — if you paint a picture with oil paints, you study concepts like fat over lean and get used to working with malleable paint that doesn’t dry for days or weeks. If you don’t know any of this going in, and all you’ve used in the past are watercolours, you will quickly get frustrated in your efforts. The result won’t be pretty. Different methods of creation have their strengths and weaknesses, you need to know what they are before you can use them effectively.
But the problem, jumping back to the coding focus, is when you start adapting your layout to fit a design you know you can code. The tools are getting in the way of your creativity.
Consider old–school table layouts. The laborious process of chopping up images for each cell, then tediously aligning them row by row and adding up colspans and the like is a very mechanical process. Tools are available that allow a designer to accomplish almost anything they need to with these methods. A good handle on the code will only improve this process, and while there are surely layouts that cannot be handled effectively through these automatic tools, for many purposes they get you 80 or 90% of the way there.
The remaining few percent is what will distinguish a good web designer from a pixel–jockey. The former understands relative font sizing, window scaling, and clean code. The latter cares more about the visuals and can satisfactorily call their work complete without ever having to touch that last 10%. Some will say that’s good enough, others will deride them for leaving the job unfinished.
Currently no such choice exists for CSS–based design. Which, some argue, is a good thing because it prevents those who fall into the latter category from mucking with it too seriously. Which, I’d argue, is precisely why a project like the Zen Garden was necessary, to show the latter category what they’re missing out on.
Having a visual CSS editor isn’t going to make the world a better place. It will enable people who code improperly to continue doing so. It still won’t make better designers of the coders using CSS now. But it will make life easier for people who wish to have it both ways. §
And speaking of design, do not miss the two excellent new Zen Garden submissions: “Wrapped in Burlap” by John Simons and “What Lies Beneath” by Micheal Pick. You may remember Mike’s previous submission, “Dead or Alive”. These two designs are phenomenally creative examples of how radically different the same designer can approach the same problem. There’s some incredible talent in this one, and if you’re in the New York area, do peruse his portfolio. §