The Pattern Language Network

Taming web2.0 in Higher Education

Posts Tagged ‘template’

the new pattern template is here!

Posted by yishaym on November 19, 2008

Over the last few weeks, we’ve been busy with workshops all over the place: CETL ALiC in leeds, formative e-Assessment in London, Teaching and Learning Computer Science in Edinbrugh. Of these, the first two were planned as a Workshop II in the frame of our methodology. The London one pretty much followed the plan, while in Leeds, as Janet reported, was more of a “I.IV”. Perhaps we were more aggressive in London.

In Edinburgh (Heriot-Watt, to be percise) on the other hand, we managed to discuss case stories and derive two patterns in a single day. It might be down to having a longer workshop, or to the fact that computer scientists are more comfortable with the whole design pattern concept.

These workshops were a good oportunity to evaluate and refine our pattern template. In light of Janet’s suggested format, as well as the discussions we had here on Validity, Resonance and Aggregation, we now have a new and improved pattern template:

  • Includes slots for icon, illustration and diagram.
  • Added a confidence value (0-3) dropdown.
  • Details (authors, dates, etc) hidden and shown on request.
  • Added a support section

The last bit is perhaps the most significant change. The support section aims to scaffold pattern authors through establishing scientific validity. It includes four elements:

  • Source – the case story from which this pattern originated.
  • Triangulation – additional supporting case stories (remember the rule of three)
  • Rationale – theoretical backing
  • Verification – solutions implemented using this pattern

This still doesn’t reflect the pattern scheme in full glory, but “you might find, you get what you need”.

Posted in patterns | Tagged: , , , , , | Leave a Comment »

Finalising a pattern structure

Posted by Janet Finlay on November 3, 2008

We have had many discussions about the structure we need for a pattern and the template on the wiki has been updated to reflect some of these. However I don’t think we have agreed a structure that we can work with from now on. My own view is that the current structure is incomplete and does not give enough support to people moving from protopatterns to patterns. It would also be useful to use a structure which is compatible with other collections to allow more seamless reuse of the patterns of others.

I proposed 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 believe our template should include the following elements (comments in parentheses):

  • Name (short, memorable but not so gimicky as to be meaningless to anyone outside the initial discussion)
  • Illustration (a picture showing an instantiation of the pattern in real life – so a photo, screenshot, video – rather than a diagrammatic representation)
  • Problem (the design challenge the pattern will address)
  • Context (described by PLML as “applicability” – what kind of situation does this pattern apply to?)
  • Solution (the instruction that resolves or addresses the challenge expressed in the problem)
  • Diagram (a schematic or diagramatic representation that captures the essence of what the pattern is about – could be a sketch or a more formal representation)
  • Evidence – to include 3 sections (either formally or indicated in the section “advice”):
  1. Examples (cases where this pattern is seen)
  2. Rationale (principles, evidence from literature etc to back up pattern
  3. Links and references (supporting the above)
  • Related patterns (patterns within the language – or another) that this one extends, is part of, contains, is the same as etc)
  • Confidence (how sure are we this is a pattern – may be related to the level of evidence, the rule of three etc. – suggest a three level “star” rating).
  • Author
  • Licensing (as now)

I think this is in keeping with our previous discussions but that of course is open to disagreement! Some of these may end up being collapsed into one field; others may be optional. However, given the difficulties users have had in knowing how to move from case to pattern, overspecifying the structure seems appropriate to begin with.

Our plan is to use this format for the ALiC workshop this week and work on scaffolding questions and activities to help our participants map their cases onto it. We’ll keep you posted.

Posted in patterns | Tagged: , , , | Leave a Comment »