I was extremely excited for this book. I know a lot of programmers who feel like they can futz around with Photoshop or HTML or what not, but don't really know why they're doing what they're doing or how to approach design problems. They always bemoan the lack of background knowledge of design concepts. So, when I saw this book was being released, I rushed out to my local B&N and grabbed it (Amazon was backordered for weeks, which spoke to how good I thought this would be!).
I thought I'd get a really good introduction to design concepts, accompanied by really solid, cohesive examples of either how to use this in a design or examples of the concept in action and why it's a good use of it. What I got instead was a scattershot of sort of interesting concepts, a few examples, and a bunch of other random stuff. Maybe I'm more persnickety about books than the other reviewers, but if we're reading the same book, we must have totally different definitions of a good teaching book.
Most of the information in there just struck me as weird and disjointed. I won't cover all the my issues with the book (some of them are just simply pedantic...), but I'll share a few examples. There's a (by page count) huge amount of space spent on Roman/Greek typography (something the author spent a lot of time researching in school as we're told in his back cover bio, inside bio, introduction, first chapter, and a few other times), but a tiny bit of information on selecting fonts for designs, type proportion, and so on. There's also a long rant on why Comic Sans is a bad font (even going so far as presenting a number of really technical arguments as to why it sucks), but completely neglects the most important point about font choice which is context. He bizarrely somewhat indicts the font being used on things like a teacher's party invitation, which seems like a perfect application of a whimsical font like that. Yes, it sucks for body text because of its design and proportions, but he doesn't say that. What he says instead is about 4 pages of technical design jargon that my programmer friends are going to gloss over. He totally missed his audience.
Then there's a whole 10 or so page section on search engine optimization. I get that it's also part of design considerations when working on the web, but in a book that's supposed to cover background design concepts to shore up a programmer's understanding of design fundamentals, it seems like a weird choice to spend 2% of the book's mass on. Plus, 10 pages is rather poor coverage of a pretty sticky topic.
The last one I'll point is the chapter on color. It does have a good bit more useful information in it than others (especially with regards to color math; really useful when working in HTML), but it also has a lot of page-filling fluff. He spends a ton of pages showing the various types of color schemes (tetradic, triadic, analogous, etc.), but he puts one per page with no context. Basically it's just "Here's the way it works, OK moving on."
And that's basically my big issue with this book. He points to a lot of interesting stuff, but doesn't tie very much of it back to actually doing things with it. He rarely even points to where this stuff is useful past a passing mention or a hastily introduced bullet point list.
I don't really blame the author for my issues with this book. Of course, he's not blameless, but I think all the information it's lacking is in his brain. He obviously knows a lot about design and is *almost* there with relaying it really well to developers. I fault his development editor for doing a terrible job of asking the right questions and getting the right answers when he was reading the drafts of the book. A good editor would have caught the audience issues and constantly been asking "How does this chapter make our readers more awesome at design as programmers?" Instead, it seems they were taking a nap or something.
Again, I was really excited and maybe that skewed my expectations. I'm just pretty disappointed with it.
