* Name

* Primary example — a screenshot or photo which captures the pattern perfectly

* What — a soundbite description; if I can’t capture it in one or two sentences, is it a pattern worth putting into the book?

* Use When — the context of use

* Why — an explanation of the design principles underlying the pattern

* How — advice, suggestions, pitfalls, alternatives, and related patterns

* Examples — an assortment of diverse examples that illustrate the range of the pattern; critical for visual thinkers

This simplified structure went over better with the intended audience than the more Alexandrian structure I had used in a previous iteration. A very few people have asked for additional sections — “Related Patterns” being one — but the information’s already there anyway, usually under “How.”

And yet I don’t think your long list of section names is wrong. Why? Context of use, of course!

I wrote these patterns as a teaching tool and a brainstorming aid. They were not a collective, collaborative effort; they do not represent the history of a single organization’s design work. If they did, then I’d agree that sections such as Specifications, History, Code, and especially Usability Results would be very important indeed.

Still, a long document can be scary-looking. If you want your patterns to be read by as many people as possible, I think you shouldn’t overwhelm them with five pages’ worth of stuff. Put the sections most important for hurried readers up front; hide the rest behind another link or something. As described in the “Extras On Demand” pattern, of course.