I'm a sucker for a good set of patterns, so I read through the online version. Here's my thoughts, compiled on-the-fly during reading:

- One of the things that I really like about the GoF patterns is the "Consequences" sections. Each pattern has some implications, and the side-effects and potential downsides should be explored and covered.

- A little more in-depth analysis as to why some of these patterns might be needed would be handy. I've done a fair bit of web development, so I can see the uses for most of these right away, but that isn't really enough IMHO. It'd be great to see a more fleshed-out look at how some of the Problems might come about, and an examination of why the patterns are good solutions. For instance, why might a customer need human assistance in the Contact pattern? Is it possible that this need indicates a failure of the site to do something that the customer needs it to do?

- "Brain" seems like a misnomer for the pattern. Really what you've described is a site navigational hierarchy; possibly because of language differences, I really don't see a connection between that and "brain." I like the idea of a pattern called "Brain" though [wink] Actually, a lot of pattern names seem out of place to me, just slightly. Naming patterns isn't easy by any stretch; maybe collecting some suggestions for alternate names would be a good idea?

- The "Guardian" pattern seems (at first reading) to imply some kind of active thing that "detects" a lost user and helps them get back to where they need to go. In my mind, this is really little more than a static navigational element that should be present on every page and easily accessible. Maybe this is just my brain inventing implications that aren't intended in the pattern description, but the description itself leaves me confused as to what you're really meaning (although I suspect it's a static thing).

- "Map" seems to overlap "Brain" and "Guardian." Maybe the latter two should simply be rolled into "Map"? They're all essentially the same pattern: a clear and accessible navigational hierarchy.

- "Painter" and "Keyword" seem to be saying the same thing, really: choose words carefully, and speak a language that your users either already know or can learn quickly.

- "Reflection" is a bit too specific; the majority of web design doesn't deal with government agencies [wink]

- "Reformatter" is a great pattern, but the pattern description doesn't really give any clues as to how to implement it. I know how I'd do it, because I've done it before, but that's not useful to a newcomer to web development. A brief examination of how to deal with the implementation would be great; for instance, I'd suggest mentioning the use of stylesheets, an MVC-style architecture, and a generic formatter system that lets you reformat any page on the site.


Looks like a great start, but the tricky thing about patterns is that they're innately very complex to simplify and actually reduce to generalized patterns. A lot of yours seem like they could be combined and made more generic, as principles of design rather than specific individual tasks. At the moment the content reads more like a specification standard than an actual pattern set; the distinction is subtle but important.