The Design of Sites, Second Edition

Joe Kauzlarich writes "The 'pattern' book has become a familiar genre for frequent readers of technical manuals. The idea is to sift through mountains of architectural or design schemes and then to categorize and catalogue the most frequent ideas and present their strengths and weaknesses. This type of book has been a success in software engineering, but can it translate to website design, where designers have everyday and frequent access to other designs? At worst, these books provide a common industry vocabulary (assuming it was read by everyone in the industry). How many people knew what a factory method referred to before Erich Gamma's Design Patterns was released? At best, as in the case of that 'original' software design patterns book, mountains of complex ideas are archived into a single reference and will sit within arm's reach for the rest of your life. So, is the web design discipline full of patterns that evade common sense?" Read below for the rest of Joe's review.

The Design of Sites, Second Edition
author	Douglas K. Van Duyne; James A. Landay; Jason I. Hong
pages	982 Pages
publisher	Prentice Hall
rating	6/10
reviewer	Joe Kauzlarich
ISBN	0131345559
summary	Catalogue of Website Design Patterns

Initially, I was amazed by the sheer scope and the amount of work that must've been put into this book. Almost 1000 pages — and not just a bunch of screenshots either. Most of the book is well-organized text. The screenshots are full-color, as is everything else in the book. Each section has a different-colored bleed, making it easy to locate the chapter you're looking for. Furthermore, the patterns are extensively cross-referenced throughout the book, and references appear in colored marginal bullets. Even the table of contents has descriptive section headings and a small summary of each section. The design of the book itself gets an eleven out of ten. The book itself is a living catalogue of technical reference design patterns. Kudos to the book's designer on this one.

As far as content, the book describes 117 distinct patterns in 13 categories. This includes patterns related to marginal topics such as mobile devices, accessibility and content creation (i.e. copywriting 101). Like most pattern books, it's a good idea to initially browse the book before using it as a reference so that you'll know what to look for when you need to pick it up again. On my initial browsing, it seemed to contain nothing particularly surprising — this has been the case with many great pattern books such as Martin Fowler's Refactoring or another of his books, Patterns of Enterprise Application Architecture, so I was not going to discredit it on this basis alone: a pattern book's true value shows itself when you're stuck on a problem and turn to it for a moment of shining clarity. Let's see if The Design of Sites lives up to this promise...

Trial #1: a business website that is not e-commerce, but a 'glorified yellow pages' type of site. I have a lot of information that needs to be accessed not only in its hierarchical organization, which can go to three levels deep, but should also guide the reader on what should be read next: a separate 'linked-list' that 'jumps' branches in the original hierarchy.

Given this amount of content and this double-organization, we wanted each page to present access to the site's information without overwhelming the reader. I open up the book to Part A, 'Site Genres', to locate the particular genre of website I'm working on. I find it: 'Valuable Company Sites.' I read some good information on layout. I see a paragraph titled 'other patterns to consider,' which points me to pattern B1, 'Multiple Ways to Navigate.' A-ha! The book's exceptional design allows me to locate pattern B1 in 3 seconds flat. It is hear I realize the true value of the book: there are no 'right' answers in design, only guidelines:

" ...we have identified two things that drive customers to action: intention and impulse (these can be thought of as goal and trigger, or need and desire). Neither intentional nor impulsive behavior is inherently good or bad, but a site that omits intention-based navigation might feel shallow and quirky, and one that omits impulse-based navigation might seem boring."

Good advice. Though I already have a hierarchical organization (intentional browsing) and recommended organization (impulse browsing), which gives users options on what to read next, I now have an idea of what sort of balance I want in the areas of navigation.

This was not exactly a mind-blowing discovery, but it did give me some confidence in the choices I eventually made and, furthermore, gave me valid reasons for making those choices, in case the client or a team-member were to question those choices later on.

Trial #2: Working on a website for a freelance graphic designer, I encounter a problem whereby each image in the portfolio can be categorized either by project/campaign or by design-type. For example, a logo, a business card, poster and website are all part of a single campaign, but we also want the ability to list all logos from separate campaigns. Again we have an organizational dilemma, but this time for a different type of site and a fundamentally different type of dilemma.

Again, I turn to the first section 'Site Genres' to locate the type of site I'm working on. It's not exactly a business site, but more of an on-line portfolio. The closest seems to be pattern A9, 'Stimulating Arts and Entertainment.' When I turn to it, I discover I was correct: the authors discuss the 'art gallery' site, though it doesn't exactly cover the aspect that I'm looking for. So I've encountered the book's first notable omission: nothing along the lines of an 'online portfolio' or 'interactive resume' genre of site design, which would encompass all creative freelancer sites as well as the usual rock band websites, etc. They differ from the 'Valuable Company Website' in that personal expression and design creativity take center stage. These sites have a general similarity in aesthetic in that they purposely avoid the business-like design. You won't see many pull-down or left-side navigation menus on a standard band website. The menus are typically integrated into a central graphic of some sort and this puts heavy constraints on the web designer while trying to effectively organize information without sacrificing the expressive purposes of the site.

The book offers no obvious guidelines for dealing with this sort of problem and here's why: it doesn't take into account the various constraints imposed by the client nor does it attempt to offer reconciliations between the design and the underlying organization of the data.

In my trial #2 we had the thumbnail images organized in two ways, either by design-type (poster, logo, business card) or by campaign ("Going Out of Business Sale", "Grand Opening", "Johnson's Automotive Website"), both organization-types having fairly equal weight. How do we allow the user to switch between organization types and keep the site consistent? The book doesn't touch these types of questions in a direct way.

The book offers a comprehensive aggregate of guidelines for user-interface patterns, User-centered, and 'psychological' perspectives. It covers most of the bases: content creation, page layout, organization of component elements, web application design, hints of 'Web 2.0' patterns, and ideas for functional pages such as searching, content submission, 'Marginal' topics like localization and accessibility that you may not want to buy a separate book for but, nonetheless, need to know about. It has a great overall design, easy to use as a reference and easy on the eyes, a long and detailed exposition on the utility of polling and seeking advice from your target audience, including sample forms to present them with. It is overall, very well-written and hardly a sentence wasted.

While 99% of the patterns themselves are common knowledge to most users of the internet and to most decent web designers, it is the expository text that forms the real meat of the book and contains the wealth of insight. This is by far the book's value. Posing as a patterns book is misleading; this book is really just a very good general guide to web design. As a pattern book, it's flawed, because almost every 'pattern' is just a guideline for effectively presenting information, not an elusive insight or 'trick of the trade' in itself, such what as Erich Gamma's (et al) original 'Design Patterns' brought us. There are mountains of outstanding tips and bits of advice throughout the book, but if you've already achieved a decent level of competency in design, then you're not going to be using the book very often and when you do, you might not get the depth of advice you're seeking.

On the other hand, the book gives beginner-to-intermediate-level designers everything they need to get started or fill in the gaps. The Design of Sites would also make an outstanding text book and is likely to be one of the best general guides to web design on the market.

I'll give it a 6 out of 10, judging a book on its utility as a design patterns books (just as you would give The Illiad a possible 2 out of 10 if Homer presented it to me as a historical text and I expected as much). As an introduction to web design, it easily deserves at least 9 points out of 10.

---

You can purchase The Design of Sites, Second Edition from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

if you want insight into web page design...

[AltGrendel]

...check out the web pages that suck [webpagesthatsuck.com] web site. There's a lot of good advice there and who knows, your site may be listed there.

Re:

[BlueParrot]

...check out the web pages that suck web site. There's a lot of good advice there and who knows, your site may be listed there.

Sure, but is there a way to nominate that site for having a completely broken DHTML interface with pointless animations? Also, if you are writing a page about other pages that suck, it should at least validate...

Re:

[klenwell]

Sure, but is there a way to nominate that site for having a completely broken DHTML interface with pointless animations? Also, if you are writing a page about other pages that suck, it should at least validate...

Really, that site sucked enough itself that I didn't even have to look at any of the sites it listed.

Re:

[AltGrendel]

I case you haven't figured it out, it's deliberate [webpagesthatsuck.com].

Re:

[Fallingcow]

So, it's supposed to render with an error that appears to be the result of having a pair of divs that are too wide stuck in a fixed-width container, which causes everything under the header to render
in
a
line
down
the
page
rather than side-by-side, causing the main content to appear outside of what I assume was meant to be its background and instead on a dark grey one that causes that black text to be nearly unreadable? And causes the footer copyright info to pop to a spot near the top of the page, next to the m

Re:

[JAS0NH0NG]

Part of the reason we wrote our book The Design of Sites was in reaction to things like "web pages that suck." There's a lot of information out there about bad web sites, but not as many practical examples and details on how to create good ones.

Re:

[Doctor Memory]

Really? I've visited that site two or three times, and each time I got the impression that the site designer was a cranky ten-year-old that needed a nap. Sure, there are some seriously hurting web sites out there, but he's got so many little nitpicks that virtually no site with any content to speak of could pass as a "not sucky" site. And then he just throws out "Oh, this site doesn't pass the test either", like I should pay attention to somebody who points out other sites' flaws but can't be bothered to

Re:

[SamSim]

Also, I don't know whether it's supposed to be ironic, but the site itself is an excellent example of a web page that sucks. I mean, look at the sidebar which descends a full screen further than the main content column, for example.

Theres only one principle of web design : KISS

[unity100]

Keep It Simple, Stupid - for those of you that still didnt know

GoF is a classic, of course....

[tcopeland]

...but it's interesting to see Stu Halloway's thoughts on design patterns [relevancellc.com]. I heard that he once gave a talk where he said something to the effect of "The 'Design Patterns' book should have been named 'Ways to Work Around C++ Language Limitations'".

Re:

[Bill Dog]

He must be either a dynamic typing zealot or a C++ hater. The GoF book, for those who don't know, has its examples in C++ and Smalltalk. I vaguely recall there being an occasional comment stating when one of either the class or object version of a pattern had an implementation in C++ but none was required in Smalltalk, due to its choice of typing approach.

Re:

[kendor]

I've found studying GoF-esque design patterns to be enormously useful for my learning, with two cavaets. First, the GoF book was NOT the best book for my learning, and I doubt it should be the first that people glom on to: more on this in a bit. Second, I rarely apply patterns directly.

For me the study of design patterns could be named, "abstracting your programming: better and smarter" or "useful ways to think about programming" or "OO is not overrated: the right way to use the object oriented paradigm.

Re:

[Nazlfrag]

The GoF wrote a terse and succinct technical manual. Most books don't contain such a density of concepts and information. There's not really enough examples given to make it all click together, so additional reading would be good. All of the books you recommend are excellent. I'd advise reading them alongside GoF though, not before. Additionally, find some code, real world implementations beat book examples any day.

Patterns are 'best practices'

[mikedeanklein]

'Patterns'/best practices can be applied to anything...walking your dog, owning kids, etc.

step 1

[brunascle]

step 1: dont let web designers touch the HTML markup. their job belongs in the CSS file. all the designers should be doing to HTML is adding class= or wrapping stuff inside <div> and <span> tags.

dont destroy the content just to to make it look pretty in IE.

Re:

[kiso]

unfortunately, this is not the case in the real world. you spend time writing a pure XHTML+CSS but: 1. The client wants eye-candy effects, look&feel or page design which cannot be implemented with pure XHTML+CSS. do some workarounds. 2. One of the popular browsers does not support one or more CSS selectors, do some workarounds (more often) so, unless the browsers stop interpreting the standards their own way, it's easier to come up with a quick & dirty HTML markup with tables and stuff, which will

Re:

[foniksonik]

step 2: don't let programmers touch the html markup. their job belongs in the class files defining functions and database queries. All the programmers should be doing is writing business logic that outputs the desired raw data.

don't destroy the markup with endless looping table structures because that's all you know how to code for... and it's easy.

step 0: hire an interactive director to create wireframes and a functional spec for both the designers and the programmers to follow. Then all will go smoothly u

Re:

[bit trollent]

step 2: don't let programmers touch the html markup. their job belongs in the class files defining functions and database queries. All the programmers should be doing is writing business logic that outputs the desired raw data.

Uhhuh. And what about interactive software? You know, where a repeater displays data which can be modified and used in a variety of ways. Should you still stick the developer in his little cubby hole of ouputting raw data?

And why is it you want to stick the dev in his hole? Becau

Re:

[foniksonik]

SO when I want to create a horizontal list out of your table of data and now I can't because it's stuck in a table instead of an unordered list which lets me decide how to display it I should thank you for your maintainable code?

Or when it comes time to debug why content isn't lining up correctly on a page and I have to muck through some spaghetti code of if/else madness with endless tr,td constructs and colspans that don't do anything anymore... or when you've decided that some application really should be

Re:

[bit trollent]

SO when I want to create a horizontal list out of your table of data

Change the templates in the repeater [ondotnet.com].

should thank you for your maintainable code?

Yes.

Or when it comes time to debug why content isn't lining up correctly on a page and I have to muck through some spaghetti code of if/else madness with endless tr,td constructs and colspans that don't do anything anymore

Your post is basically a rant against the same kind of bad programming that I also complain about. The same code would suck

Re:

[yurigoul]

I agree! Of course I use tables, it all has to do with Murpheys law: if anything can go wrong it will at some point. If I have to do xhtml + css the zen garden way i might get a beautifull site but they are using a lot of energy in finding tricks to render their sites in all browsers the way they want them to and those tricks may or may not work in future browser releases. But i can do most of it if not all while using tables and a minumum amount of energy to get it rendered correctly in all browsers for

Re:

[Bogtha]

On the contrary, web designers should be messing with the HTML, as they are the ones most qualified to do it. I suspect you are using "web designer" as a synonym for "graphic designer", but they are really two separate roles.

A graphic designer should be responsible for how a website looks. He needs certain domain-specific knowledge, so that he doesn't do anything silly like assume that words take up a fixed amount of space, but he should be concerned with how things look and not touch code.

A web de

Re:

[ThePromenader]

Web designers should do a good long bout of coding before they sit down to design a site - it would save everyone in the team a lot of trouble. Also, a bit more attention should be paid to ergonomics - web browsing remains instinctive (big red button marked "here"! Oh, click click! Underline == link! Just what is that menu doing and where will it take me?) and design should be steeped more in that than... design itself.

I agree with the above - good design is a mix of all web trades (namely design (layout) a

The patterns of site design

[also-rr]

• Still done in HTML 3.2.
• Still done in HTML 3.2 but with tables for layout.
• Still done in HTML 3.2 but with tables for layout... and heavy on that new fangled BLINK tag.
• Done completely in Flash.
• Done mostly right, but with all the actual information in Flash.
• Incorporating a browser check that sends !ie to a holding page.
• Navigation missing.
• Navigation broken.
• Navigation an active X control.
• Split over 17 pages of two paragraphs (and nine ads) each.
• Correctly coded in XHTML+CSS with graceful fallback. (NB: Never seen in the wild.)

Re:

[JAS0NH0NG]

You have a lot of good points and anti-points (ie things to avoid) with respect to practical implementation of web sites. However, I think it doesn't quite capture the essence of user interface design patterns. What you have is more of guidelines, which are useful, but don't provide actual examples of what to do.

Another way patterns differ from guidelines (and something the GoF missed) is that they should be hierarchical. Take a look at Christopher Alexander's original book on design patterns, and you'll se

Re:

[Marxist Hacker 42]

You missed (and this is somewhere below HTML 3.2) Done entirely in huge, uncompressed Bitmaps that take forever to load even at broadband speeds.

Re:

[MP3Chuck]

Web 0.1 [worsethanfailure.com], perhaps? ;)

Re:

[Marxist Hacker 42]

Pretty close. This advice actually came from a ZNet article circa 1995- back when incorrectly compressed pictures and improperly coded img tags could cause a page to be rendered so slowly that nobody actually ever got to the content- the modem would drop carrier first.

Re:

[bigdavesmith]

All this brings up a good point, and one I'm currently having to address. How do you tell someone who is not a web designer (small business owners, from my experience) that their website is bad, or has problems, when the web is such a collection of bad examples? 'But Everybody Else is Doing It!'

I'm a student doing some web work for my university. Nothing major.
Anyway, my boss (who is an awesome guy, but not a web designer), the person who threw the site together originally, used Dreamweaver, and for

Re: The Design of Sites

[stevey]

It is hear I realize the true value of the book: there are no 'right' answers in design, only guidelines:

Interesting sounding book, I might take a look.

But for future reference "here" not "hear".

Sounds like PimpMyWebsite

[HOTTILA.COM]

A touch of pink might be ok :)

Design of Sites Website

[mh1997]

How come when I go to http://www.designofsites.com/index.htm [designofsites.com], the book shown is the first edition, yet the link at the bottom of the review is for the second edition?

The book looks very good, and I will purchase it today, but you'd think that the author's website would have been updated, you know, to make the design of the site....

Re:

[gsmalleus]

You didn't see the link to the book on Amazon [amazon.com] that was included with the summary?

I picked..

[Nazlfrag]

Extremely Valuable Highly Professional Big Company Sites, I'm bound to get rich!

So, they wrote a book about how many templates are there in Dreamweaver.. what the hell does that have to do with programming, GoF or design patterns?

Ajax Design Patterns by Michael Mahemoff

[at_$tephen]

I think Mahemoff does an excellent job on "Ajax Design Patterns". He is clearly well schooled in the traditional design patterns of Gamma et al and does an excellent job using a similar spirit vis a vis Ajax. He covers an impressive number of sites, many of whom I would never have heard about if it were not for his diligent research. He has a catalog of the specific patterns he covers such as Ajax App, Ajax Stub, Browser-Side Cache, and Data Grid. However, the actual book is organized in five main areas beg