The ‘father’ of Pattern Languages is the architect Christopher Alexander. In the 1970’s he became concerned about the way in which the design process of living spaces had changed from one whereby those who live and use the buildings, streets, parks, etc. were primarily responsible for their design to one dominated by architects, town planners, and other professionals.

He developed the idea of a structured template where “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice.” (Alexander et al., 1977).

Combined together, individual patterns produce a Pattern Language. For Alexander, this approach was a way of capturing what it was that we used to do well in urban design (some time in the distant past) and at the same time empower those who live in the spaces to influence their development.

More recently, other professions, particularly developers and programmers have adopted a patterns approach – this is a good introduction from Alexander.

Taking this a little further, Richard Millwood, Ian Tindall and myself have attempted to develop a pattern language for Online Communities of Inquiry. It is our intention that the patterns should be readily understood by all who participate in the community of inquiry or support its development in some way – learners, teaching and support staff as well as invited guests to the community. We believe that full potential of pattern languages may be unrealised if there is a dislocation between different groups of users. They are designed to open up the debate between the different interested parties as to how tools and approaches could be further developed and improved.

This diagram shows our ‘high order’ Pattern Language and these are a couple of example patterns – ‘Nurture Online Community’ and a loweer level pattern of ‘Working Together’. Other patterns still to be constructed will include those for, retention, hotseats, asynchronous, conversations, learning sets. etc.

The trick is to find the right balance between too many patterns so that the language will be over-complicated, and too few patterns at an abstract level so that there is not sufficient detail for them to be implemented and understood.