99% of Web Design Books are Not

Most books that claim to be about web design aren’t about web design at all. They’re about publishing in HTML and CSS, which by and large has little to do with the problems of the users we’re supposed to be designing for.

I was in a Barnes and Noble this weekend looking at web design books. There were lots of them! I saw old favorites like Eric Meyer’s CSS: The Definitive Guide and new favorites like Dan Cederholm’s Bulletproof Web Design. I have a collection of these books, and my life has been made easier by them. I’m grateful for that.

But these aren’t really design books, per se. They’re more like books about web development, a similar and related field but not quite the same. They’re books about how to publish web sites in HTML and CSS. That’s publishing, not design.

And those are just the cream of the crop. There are countless others whose tables of contents look exactly alike. How many more books do we need showing us how to create table-less layouts in CSS? 10, 20…50? If you want that many books on the subject, you can get them! And every once in a while a new book will come along that adds to the discussion. But the number of books that simply echo each other is growing…fast. You can get multiple titles each from New Riders, O’Reilly, Sitepoint, and dozens of other publishers. Two Sitepoint titles that I looked at were both 500 pages each…all on HTML and CSS. They were brand new books on years old subjects for which dozens of titles have already been printed! How much more can be written on these subjects? Didn’t Eric Meyer lick this stuff years ago?

HTML and CSS ain’t easy

Part of the problem is that HTML and CSS ain’t easy. No matter what people tell you, the CSS layout scheme is not for the faint of heart. Figuring out absolute positioning and floating elements takes months and lots of trial and error. I’m still having to stop myself and say…OK…where was the last relative or absolutely positioned element in the tree above this one? Oh…that’s why this layout is broken! Doh! Perhaps this is partly why there are so many books on the subject.

For years now I’ve claimed that when IE comes out with display:table support that half of the developers out there will switch back to table-based layouts. This way, they can get the layouts they want easily and not have to answer to those folks who claim that it’s unprofessional to use tables for layout because it’s not semantically correct. What they don’t tell you is that no user agent in the world gives a damn what you use for layout…so you might as well use what you want. What they also don’t tell you is that there is absolutely no correlation between table-less layouts and creating a successful design that people are happy to use.

Unfortunately, however, IE7 doesn’t seem to be getting display:table support, so I guess I’ll have to wait a little longer to see if my prediction comes true.

Sometimes technology influences design

Sometimes publishing technology influences the design of the publication. For example, I design interfaces differently knowing what I know about how to make them display well in browsers. The nuances here are many. Sometimes I create content boxes with obvious handles for CSS properties like border, padding, and margin. Sometimes I use text sizes that will be easy to replicate in CSS font properties. Sometimes I even lay out entire navigation bars knowing that I can use a certain technique to make them semantically-correct list items. Ugh. This is work that I shouldn’t have to do, I don’t want to do, and it takes up too much of my time. Talk about a separation of content and style? We need a separation between content, style, and user agent.

Design ain’t easy, either

Maybe we see a glut of “web design” books focusing on technology because design is such a difficult topic to pin down. “What is design?” seems to be a universal question that any designer can give you an opinion on.

To me, design is about solving problems. But not the problems of designers, the problems of users. It’s a not-so-subtle distinction. And I’m not saying that we shouldn’t have these discussions…obviously we need to know the technical details of how to publish. But the inordinate amount of time we spend focusing on technology is wasteful…imagine if we could shave off 50% of the time we spend publishing…would we use that time to focus more on the other problems?

The problems that matter are the ones that aren’t ours. They’re the ones that live in a different context than the one we find ourselves in. Our context is one of a designer and publisher. The users’ is one of goals and activities. They don’t care about browsers compatibility or semantically correct…anything. They care about paying bills, purchasing toilet paper, being entertained, and getting the latest news. That’s their problem set. It doesn’t include HTML or CSS.

Design is as designers do

I’m not one to get hung up on nomenclature. Usually, when I see the words “web design” I understand that it probably means “web development”. But I wonder: is this hurting the web design profession? If readers and publishers continue to use the words “web design” to refer to HTML and CSS publishing, and countless more books get published on the subject, what effect will it have on those of us who consider ourselves web designers?

Should I continue to call myself a web designer even though that might mean to someone that I write code? I don’t want that. I want people to know that I help figure out what goes on the page depending on the needs of their users, how the interface should act to help solve their user’s problems, and how their users will be more happy as a result. That’s the type of web design that I do. And it’s a long way off from writing code. Writing code is only a means to an end. In the future I might be writing some other dialect of XML, or even some completely different language or publishing structure. But even then web design will still be about solving somebody else’s problems, no matter what 99% of the web design books say.