Learning how to write patterns...a note on pattern form

Updated April 8 with corrected links.

I've received two requests for more info on writing patterns. (Like all online resources that I use for this project, I've tagged pattern articles and websites in my Furl and del.icio.us archives, respectively. If I've missed some good ones let me know!). These are some of the resources I am finding particularly useful as I learn about writing patterns.

Choosing a format. The concept of design patterns originated with architect Christopher Alexander and colleagues, in two books, A Pattern Language and The Timeless Way of Building. Every pattern I've seen derives its elements from his original pattern form, but adapt it to their domain. e.g. see E-LEN's e-learning design pattern and Pedagogical Pattern Project. The latter, used by Joseph Bergin and collegues is slightly a less demanding, more concise format, and comes with many examples. This is the format I've chosen to use, which Bergin et al describe as follows:

All patterns are written in the you-form, thus directly talking to you, the teacher. In addition to the pattern name, each pattern is divided into four sections. The sections are separated by ***. The first section sets the context. The second describes the forces and the key problem. The third section outlines the solution, the consequences, limitations and disadvantages. The fourth section complements the discussion of the solution, by providing further information and examples. The key problem and the solution are in bold font and represent the thumbnail of the pattern (also called the pattlet). The examples are in italic font. References to patterns inside this pattern language are in CAPITAL LETTERS, references to patterns published elsewhere are in normal font, but followed with the [pointer] to the reference section. In addition, each pattern is marked with one or two asterisks (*), as in Alexander’s patterns. They show how fundamental we believe the pattern is. Two asterisks denote patterns that state a true invariant. We believe that it is not possible to solve the stated problem properly, without referring to the solution that we have given. One asterisk means that we think that we are on the right track, but we believe it will be possible to improve the solution.

Step by step. It's a lot harder than it looks. Be prepared to ruminate. The E-LEN project offers a tutorial on making e-learning design patterns. It is really more of an analyis of a pattern example (Virtual Assitant), rather than a tutorial. For a more procedural approach, I relied on Richard Griffiths' and Lyn Pemberton's Don't Write Guidelines Write Patterns! because this whole pattern thing was beginning to strike me as too reductionist, and I was drawn to their advice to find patterns that 'feel good.' I am dropping in Gerard Meszaros' and Jim Doble's meta-collection, A Pattern Language for Pattern Writing as I discover specific situations where I need help. This is promising to be a very useful resource. These are Griffiths and Pemberton steps for pattern writing:

1. Identify the subject of the pattern.

For Alexander, within the domain of architecture, this involves finding places which ‘feel good’. For us, this could translate to finding examples of human-computer interaction that ‘work well’ for the users. The subjective experience of the users is crucial in identifying patterns that are, in Alexander’s phrase, ‘alive’, and make the user positively engaged with the system.

2. Identify the problem that this pattern resolves.

Patterns resolve conflicting forces, which may be technical, social or aesthetic. Their interaction, through either conflicting or supporting is the field of forces that the design solution must resolve.

3. Identify invariance.

Empirical examples of attempted design solutions to these fields of forces are then examined to identify features or properties of successful designs that are missing in unsuccessful ones; i.e. the invariant that a pattern must encapsulate. It is possible that an invariant will be identified, not from existing examples, but from abstract analysis.

Writing Tips. The skill to writing patterns, I think, is to shift between the parts and the whole with ease. For the specifics, I've found Ward Cunningham's Tips for Writing Pattern Language's. I think he is part of the Pedagogical Patterns Project. John Vlissides is definitely a programmer, but his Seven Habits of Successful Pattern Writers and Patterns: The Top Ten Misconceptions are valuable to all pattern writers. One problem I am having is coming up with too many patterns that are not really distinct from one other. This is when I hit on the idea of mapping it to Candy's model to keep the whole and the parts coherent. Here's Vlissides advice from Habit 4, Keeping patterns distinct and complementary:

...Therefore make sure your patterns are orthogonal and that they work synergistically. Continually ask yourself, "How is pattern X different from pattern Y?" If two patterns solve the same or similar problems, you can probably merge them. Don't worry if two patterns use similar class hierarchies. There are only so many ways to use the relatively few mechanisms inherent in object-oriented programming. Often the same arrangement of classes will yield substantially different object structures that address widely varying problems. Let the intents of the patterns be your guide to their differences and not the class structures that implement them.

posted by: Shanta at 11:15 | link | comments (2)
design, resources, lifelong, learning, patterns

Comments:

#1  10 April 2005 - 05:58

 

Dear Shanta
It was interesting to read a comment from you to my blog and then to follow you back here and see how people are working simultaneously alongside each other in completely different areas but using the same potential structure. You mention "furl" and so now this will trigger some further research for me.

jalar

#2  10 April 2005 - 10:09

 

Serendipity, jalar...my favourite word of the day. Without a doubt, Furl has proven to be the best organizing tool for online documents I've discovered on the net. For online websites, I use del.icio.us, which you may also want to check out.

Shanta

Comments: