The Pattern Language Network

Taming web2.0 in Higher Education

Thinking about structures

Posted by Janet Finlay on July 30, 2008

A sub-group of the Planet team had a profitable time this morning meeting with Jill Jameson our very encouraging critical friend and discussing the progress, successes and challenges faced by the project. After Jill left to see ARGOSI, John, Isobel and I mused about some of those challenges and how we might address them. One that we need to finalise quickly is how we can best structure individual patterns to make them most accessible both to those involved in creating patterns through our workshops, and those who will hopefully come along later and want to make use of them in guiding their teaching practice choices. Planet wiki currently uses a form inherited from the Learning Patterns project which includes the pattern name, aim, context, solution, related patterns, examples (case studies/scenarios), note, links and references and legal rights. However we have had some debate as to whether this captures all that we need and whether the sections are clear enough.

In 2004 I was involved in organising a workshop at the CHI conference where this issue was the primary focus. One of the outputs of that workshop was PLML – a pattern language markup language – complete with DTD, specifying the elements that might be included in a pattern. The basic pattern element looks like this (full details and spec are available from the link above):

<!ELEMENT pattern (name?, alias*, illustration?, problem?, context?, forces?, solution?, synopsis?, diagram?, evidence?, confidence?, literature?, implementation?, related-patterns?, pattern-link*, management?)>

It is interesting to compare this to our structure, noting that only the unique identifier is essential in PLML. We have a name – though it could be more obvious on the pattern page itself. Our “problem” is called “aim” (I think I prefer problem – suggests the problem solution pairing that we are looking for). We have context, solution, evidence (our examples – though we could also have a rationale element), literature (our notes), and related patterns. Our legal element might be part of the management section – which could also include version and authorship information which is effectively managed by the wiki itself. So what is left? Looking at the elements that we don’t have, three stand out as being particularly useful: illustration, diagram and confidence.

It has been said that a pattern is not a pattern if it cannot be drawn. That may be an exaggeration but the concept of illustration of patterns is one which is critical I think to their accessibility. It really is a case of a picture being worth a thousand words. In the case of learning patterns the illustration might be a photograph or an artefact or a diagram or even a video – but there should be some visual way of representing the essence of the pattern that lets others have that “a-ha” moment. Perhaps here we need to talk to John Sandars and the Reflect 2 team about their activities..? Not sure if we need both illustration and diagram (they do serve different purposes so maybe we do) but certainly illustration.

The other area is confidence. At the moment our patterns are categorised by their level of development – seed, alpha, beta. But this is slightly different from the idea of confidence – it would be possible to have a well developed pattern in which you had limited confidence, perhaps because there was not much substantiated evidence to support it. Confidence is how sure we are that this really is a pattern. Alexander used a star system which was elegant and informative – you can see at a glance which patterns are the strongest in his language.

So from this I propose that we consider some adaptations to our current form:

  • Change “aim” to “problem”
  • Add “illustration”
  • Add “confidence”
  • Make “examples” a subsection of “evidence” and add another subsection “rationale”
  • Make the name clearer and maybe allow aliases.

Thoughts anyone?


9 Responses to “Thinking about structures”

  1. yishaym said

    Several good points here.

    Pattern structure
    The current form definitely calls for debate. Some elements are derived from an intersection between PLML and the Learning Patterns project (aka LP) template. Nota bene, LP used a Soft Scaffolding template, while ours is slightly more rigid – primarily to allow PLML export.
    I also prefer problem to aim, maybe because I come from a CS culture, where a problem is something fun to do. But I noticed that for many people a problem is a threat, something to avoid. I noticed that in the British social-science vernacular we talk of issues, never problems. I think that’s why we went with aim.
    I think there’s three types of “organs” in the above structure:

    Meta-data, such as author, URI, creation and last edit dates
    Summary info, such as name, aliases, tagline, confidence
    Body, which consists of the problem-context-solution triad, and the support (evidence / examples etc.)

    At EuroPLoP I also came to acknowledge the importance of enumerating the forces as part of problem description.

    In any case, I think this discussion should be of interest to a wider audience, and indeed must involve partners from outside of the project team. I’ve opened a page on the
    Pattern Language Exchange workspace.

    Diagrams / illustrations
    In notes on the synthesis of form, Alexander talks of diagrams. He later claimed that they are synonymous with patterns. If you ask any architecture what they find appealing about the Timeless Way of Building, they will point at the visuals. The lack of visual / graphical modalities in our patterns is something we must address. We have two proposed projects on this theme, and will start working on them soon. In the meanwhile, note that the pattern editor makes it very easy to embed graphics. So just get creative! here are some examples.

  2. […] Comments yishaym on Thinking about structuresRob Knapp on Contact usJane Chandler on […]

  3. […] Thinking about structures […]

  4. Jim Hensman said

    Some comments on Pattern Structures and Categories

    “Aim” or “Problem”: I would prefer problem as the main heading as well. It highlights the fact that a pattern resolves certain forces, and as Janet points out, pairs problems and solutions. However, relating to Yishay’s comments is the fact that often a problem is interpreted in a rather restricted sense, and may not easily associate in people’s minds with the experience from particular learning case studies. Perhaps we should have the heading “Problem”, and then the blurb underneath saying something like: “What is the aim of the pattern, what issue does it seek to resolve?”

    Illustrations and diagrams: I think visual representations of any kind are very important for patterns, and we should try to incorporate these as far as possible. The illustration is meant to provide a visual representation of an archetypal example of the pattern. This is obviously easier in the case of an architectural pattern, or one used in web interface design, for example, although Yishay gives a good example with regard to the use of gestures in a learning context. For learning patterns, what would really be effective would be a video sequence or at least a set of photographs linked to the particular scenario. If you look at the illustrations Alexander uses in a pattern language, although these are in black and white and of relatively poor a quality, many of these immediately invoke the experience that Alexander is trying to convey. We need to think creatively how to do this for learning patterns. Diagrams I think have a more functional use, particularly in helping to explain the solution, but again I think should be used where possible.

    Confidence: Perhaps we are trying to fulfil too many requirements with this categorisation. I would agree with Janet, that this should primarily be an indication of the level of confidence that this is really a pattern – for instance, if it has been confirmed by a considerable range of examples. Alexander in fact had a very stringent requirement relating to this – the pattern had to be “common to all possible ways of solving the stated problem.” This leads on to something which we started discussing but never really resolved, about the status of “seed” patterns. Let’s remember, that our rule of three is suppose to apply before something is even considered a pattern. It perhaps may be considered too late to try to represent the “proto” patterns in a different way. However, we need to provide some guidelines that indicate their status, and perhaps there needs to be some process before a pattern is upgraded from seed status to alpha. This is not just to maintain the quality of the patterns, but also conversely because we do want to encourage observations and good ideas which come from experience to be contributed. But I do think we need to make clear, that these are not patterns at this stage.

    The “Licensing” category: I am not keen on this as part of every pattern. I think this may deter people, especially those using the system for the first time. I appreciate that we do need something, but could we not have something that people have to agree to before they get authorisation to add content, for instance?

    General points: One of the problems with what we are trying to do in representing patterns, is that particularly at a developmental stage, we are trying to fulfil several different requirements. The needs of those contributing and developing patterns, for instance, are not the same as for somebody who wants to use them. The wide variety of different patterns categories used in different pattern language examples is probably an indication that it is impossible to have just a single suitable representation. The PADI example, which John refers to, is a very interesting case of adapting the pattern format to tailor it to a very specific requirement. Perhaps, as I have mentioned previously, the optimum would be to have an underlying representation, but different views which are adapted to the type of user and use. Given these limitations, what I do think stands out as being missing in our representation, is what often forms the largest part of Alexander’s patterns, which he categorised as the “body of the problem.” This is the general discussion about the pattern, which could include theoretical issues, detailed analysis of the forces involved, examples and counter-examples etc., in essence the general justification for it to be a pattern. I don’t have a view as to whether “Evidence” and “Rationale” together are the best terms for this, but perhaps if we had some categories like these, with maybe a short blurb and examples to indicate how it could be used, it could fulfil this general function. For instance, in the case of a seed pattern, if we aren’t going for a separate representation, these categories could perhaps be used to indicate what added information and case studies are being sought. Overall, I suppose we have to seek the best compromise between being as comprehensive as possible from a formal patterns viewpoint, while being as accessible and user friendly as well.

  5. yishaym said

    Reflecting on this discussion, and drawing in some of the comments in the fascinating exchange on validity, I’ve drafted a scheme for pattern structure. Its still very skeletal, but you should be able to understand it. Looking forward to your comments.

  6. yishaym said

    Jim: licensing is not a technicality. It is the foundation of sharability. I think we need to put it upfront, and make sure the UI is streamlined.

  7. isobelf said

    On illustrations, we already have two good examples of photos as illustrations, which I find instantly compelling. I’m not sure that video, because it takes longer to watch and hence to process mentally, fulfills the same purpose. As Jim suggests for diagrams, perhaps video is part of the solution.

    In any event, I agree with Janet, that it would be helpful to add “illustration” to our structure, to highlight the crucial need for them.

  8. yishaym said

    thanks Isobel. I’ve posted an issue on the tracker for that. I think I’ll promote it, given there seems to be a consensus on the importance of this feature.

  9. […] proposed some changes some time ago based on the PLML pattern elements – the resulting discussion was then summarised by […]

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: