Back in October, Jeffrey Zeldman tweeted something that I strongly agree with:
Real web designers write code. Always have, always will. #aea
This sparked many conversations including these two tweets from Chris Shiflett:
According to @zeldman, real web designers write code. (I think he means HTML and CSS, not PHP, Perl, and Python.) What do you think?
I’ve now asked, separately, whether developers and designers should know HTML and CSS. In both cases, most think they should. Interesting.
To which I responded (brackets added):
@shiflett IMHO, the demarcation between web developers and web designers should be POSH [Plain Old Semantic HTML]. That’s what both need to know.
I have a pretty strong opinion about this. You could say that I have the luxury of working with an excellent designer who implements all of his own CSS—even tackling much of the JavaScript coding on websites we build. To be clear: he is a designer, not a developer—working in both print (which is more technical than you might think) and web.
The typical process is summarized well in Marco Tabini’s PHP Advent 2009 post on CSS and Other People:
From a developer’s perspective, “design work” means having to deal with the often hated, sometimes impossible, and always challenging task of translating a designer’s comp into a combination of HTML and CSS that will render properly on browsers that are often at complete odds with one another.
In my opinion, that process is broken. Why is it assumed that because HTML and CSS are “code” it should be a developer’s job to implement these? Any decent designer is already familiar with the concept of separating presentation and content with style sheets (which are supported in Adobe InDesign, QuarkXPress, and even PageMaker and Microsoft Word). Is learning HTML and CSS, both declarative languages, considered too hard for designers?
Let’s take a look at comps and the dreaded “s” word—slicing. As Marco pointed out, trying to “slice” a comp into HTML and CSS is “sometimes impossible” and “always challenging.” If a designer is only providing a comp, and not the HTML and CSS, it is very likely that the designer does not have a solid understanding of things like progressive enhancement, browser compatibility, and even what is possible on the web.
The use of a comp generally assumes that design is purely visual and that all representations of the web page should look exactly like the comp. How should the content be presented to screen readers, to mobile devices, and in print? Sure, you could provide comps for each of these scenarios but this is not scalable and you quickly risk violating the “One Web” concept. Thinking of a web page through the lens of only one specific visual representation of that page is very limiting.
Do you agree that the typical process is broken? If so, what are the barriers to fixing this process? Do we need better trained web designers? Do organizations need to be educated on how to better structure their web teams? This problem will eventually self-correct. My prediction is that teams with web designers that know HTML and CSS will create better websites and web applications and be more successful than teams using the old process.
4 Comments
I whole-heartedly agree that the designers should know HTML/CSS themselves. Those two things are less about the "programming" of the site and more about the "structure". When designers creating their comps, they're creating a structure – the layout of the data and various elements in the page. It only makes sense that they would be the ones to make sure that image correctly translates into a well-structured website. Really, there's no excuse for them not to do it.
On the flip side, I think all web developers (the ones writing the code) should know HTML and CSS too. There's so many places that, if they had to go running back to the designer to fix something every time, the project would be stalled constantly. By knowing this dynamic duo of web layouts, the developers are also able to use the CSS "toolkit" the designer has given them and reuse parts of the site (buttons, background images, etc).
@enygma Thanks for your comments! I tend to be somewhat of a purist about the issue. Having POSH as the demarcation point and not needing to know any CSS has freed up brain space for other useful stuff (the day I forget all of the CSS I know I'll be very happy!). You brought up the concept of a CSS "toolkit" which I really like. Another way to think of this "toolkit" is as a set of microformats and poshformats worked on together by the designer and developer. This way the designer has setup reusable parts that the developer can use — but purely through semantic HTML. Again, I admit to being somewhat of purist about this and there probably are situations where it's useful for the developer to know CSS.
Great article on a topic of some importance. How far downstream that interface between the "designer" and the "developer" occurs can play a significant role in the success and the pace of the project.
I agree with your conclusion that designers that go beyond the comp, creating good POSH and CSS themselves, are much more valuable than those that do not, and will ultimately produce far better web sites.
Sadly, the vast majority of web designers with whom I have interacted have been either uninterested or incapable of that level of mastery. For them, it's just make a pretty picture and lob the PSD file over the wall for me to convert to html/css. [And I'm terrible at it. Takes me forever, and there is always some little IE bug that trips me up.]
It's always a blessing to work with a designer who has solid downstream POSH/CSS skills. In fact, for those designers, the whole idea of the comp itself is now increasingly suspect.
In summary, when you find such a designer, hug him/her tight and never let him/her go. 😉
Thanks for posting this very informative article. I have learned a lot. Cheers to a wonderful 2010!
website design New York City