The Pattern Language Network

Taming web2.0 in Higher Education

Pattern Formats and Structures

Posted by jhensman on September 23, 2008

I want to try to summarise some of the discussion that we have had about pattern formats and structures, so that we can make the necessary decisions to take us forward.

  1. There is agreement that “Illustration” should be added as a standard field and that we should encourage use of visual representations, such as diagrams, more generally.
  2. There seems to be a consensus that “Aim” should be changed to “Problem”. Because of some restrictive connotations of using this term which have been mentioned, we should provide supporting text and examples to indicate that this is meant in the sense of what issue the pattern resolves.
  3. The question of the confidence rating for patterns has been raised. The view that this should reflect the level of confidence in the pattern as a pattern, and not just its level of development, seems to be generally agreed. Some further discussion is required to determine how this could be reflected in the form of usable guidelines.
  4. There has been discussion about a range of detailed additional information in different categories which relate to the main parts of the pattern (Problem, Solution, Context), or to the pattern as a whole. Suggestions include subsections for rationale and evidence. The experience of the formats used by other pattern repositories will be useful to us, to help decide on a compromise between the requirements of precision and standardisation to aid pattern interchange, and flexibility and simplicity for users of the pattern network. A draft structure is available on the Planet Wiki, and can be the basis of further discussion. My general preference is for fairly broad categories, with a number of more detailed optional subcategories prompted by a set of guidelines and suggested questions, with examples to indicate how these can be applied.
  5. How we deal with the formative stages of a pattern has been discussed. This is a pressing issue as it affects how people use the Planet platform, and any changes agreed need to be implemented soon as it would be difficult to change things retrospectively. There appears to be a consensus that the seed/proto patterns are not patterns, and thus must be distinguished from patterns – even ones categorised as having a low level of confidence attached to them – in some way. How this is then reflected in the pattern and platform structure still needs to be resolved. These are some of my thoughts on this. I will use the word “proto-pattern” for convenience, but what term we actually use needs to be agreed on.

The processes associated with creating a pattern, as against refining and seeking to increase the level of confidence in it, are obviously linked. However, especially when considering the initial stages of pattern creation, there are also significant differences. A simple way of looking at this question is to consider the components that make up a pattern, which we are currently discussing with regard to specifying the pattern format. In defining the problem, we need to understand what the forces are that need to be resolved. The solution both needs sufficient evidence from actual cases (a minimum of 3 according to the rule of thumb we have agreed on), as well as an understanding of what other patterns would be needed to provide a complete solution. The context specifies the conditions under which the pattern applies, but also connects it to other patterns at its own and higher levels. Therefore, even before we can even consider something to be a pattern, we have to look for other relevant cases and practice, look at the practice and theory of associated problem areas, and relate the prospective pattern to a wider conceptual framework. The questions raised and activities required at this stage thus will centre on resolving these issues. Of course these processes are also relevant when we reach the pattern stage, but while the processes associated with a pattern are primarily focused on its use to solve a particular problem, for a proto-pattern it is primarily focused on the formulation and development of the pattern and pattern language.

The distinction between proto-patterns and patterns should not be seen as a formal or linguistic one. Rather it reflects their different roles. Indeed, for a considerable part of the period of development of a proto-pattern, it may be uncertain whether it will progress to pattern status or not. It is potentially confusing to people using the Planet site, who may expect more from what are labelled as patterns, unless this distinction is made clear. At the same time, having a means of representing and developing even very rudimentary proto-pattern ideas is vital. Clarifying how we do this will be particularly important at the current juncture, where we are beginning to discuss with others how we interface with systems that may be the source of such ideas.

How would this affect our current framework? Obviously we should have some guidelines that explain the distinctions, but reflecting this in our systems and pattern formats requires careful thought. In practice, although we need to draw the distinction between proto-patterns and patterns, we also want to create a smooth transition between the two. If feasible, I would prefer a common format, with an interface that was effectively context sensitive, and presented different options and questions depending on the proto-pattern/pattern status indication. As an example, for a particular part of a proto-pattern, questions may prompt the user to look for examples where a proposed solution does not apply, to help establish the boundaries of context for the pattern. In the case of the pattern itself, this part would state what these boundaries were, and indicate relevant related patterns. There would need to be a process, perhaps using a simple checklist, that facilitated the transition from proto-pattern to pattern. Underlying this would be the simple criterion for deciding whether something should be given pattern status – namely: “Can it be used as a pattern?” Opinions on this issue would be particularly valuable, as we need to move to a decision very soon.


3 Responses to “Pattern Formats and Structures”

  1. yishaym said

    Thanks for the summary, Jim. Some of these ideas are already embodied in the pattern scheme we’ve started working on. Comments on that are very welcome.

    Other issues should be elucidated when we get down to writing up our methodology. I think it’s time to start working on that.

  2. Janet Finlay said

    I think it can be simpler than this. What we have at present are clearly protopatterns. If we are considering altering and expanding the form for full patterns (to be more akin to PLML) then we could introduce this as a second stage, leaving the current form as the protopattern form. What we then need is scaffolding for people to move from one stage to the next. I am working on that at the moment – we have a follow on workshop with the ALiC user group in the planning stage (will post details shortly) and this will focus on moving from our initial protopatterns to full patterns. Will this be the first time we have run a follow on workshop with the same users?

  3. […] some changes some time ago based on the PLML pattern elements – the resulting discussion was then summarised by Jim. I’d like to take that further now and propose an actual specification for the structure. I […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: