Planet 2-day meeting

My head is buzzing following our very productive two day meeting in London which finished yesterday. The first day was a meeting of the Planet team; on the second we were joined by distinguished guests with expertise in various areas of patterns and representations of practice. These included: Lorna Burns from Barnet College; Mark Childs from Coventry; Juliette Culver from the OU; Sally Fincher from University of Kent; Christian Kohls from the Knowledge Media Research Center in Tübingen, Germany; Diana Laurillard from London Knowledge Lab; Helen Sharp from the OU; and Niall Winters from London Knowledge Lab. Jill Jameson also joined us for the afternoon on the second day in her role as critical friend to the project. In between the two working days, the team and guests met for dinner at the wonderful Ottolenghi restaurant in Islington – well worth a visit! But back to the main business. 

Frankly it is difficult to know where to start. On day one we thrashed through some major issues to do with the process of eliciting patterns, the scaffolding we offer through our wiki, and the need for (and current lack of) an organising structure for the patterns that are emerging from our workshop activities. On the second day we had invited our guests to submit stories about their own successful teaching practice which we then used in the morning to give them a taste of our workshop approach to pattern elicitation. In the afternoon we invited them to feedback on this which led to a valuable discussion of the strengths and weaknesses in our approach and alternative approaches which really helped us to pin down the aspects we need to focus on in the remaining months of the project.

Each of these needs further consideration (and warrants its own blog post) but to summarize:

• We are proposing a three workshop model, with active facilitation from a pattern-knowledgeable moderator pre and post each activity. Much of this is in place but needs closer specification so that what is currently “craft” knowledge is made explicit, the activities required of participants are more clearly defined and the case and pattern structures currently on the Wiki reflect what we are seeking in these two forms.
• We need to agree what and how we are abstracting from case stories to make patterns: what are the salient questions to ask? And what order is it appropriate to ask them?
• We urgently need an organising structure to help us make sense of the patterns that are already emerging, to identify gaps where new patterns are needed, and to scaffold the use of patterns in practice. We have some candidates and we need to start working with them: how do our existing patterns map onto these? where are the gaps? what sense do they make to users? The latter is key: whatever structure we choose must reflect the way teaching practitioners work and think about their practice or the patterns will not be used.
• We currently have upwards of a dozen user groups, with whom we are working and talking. All are at different stages in the process, but it is important that one or two at least complete and evaluate the whole three workshop cycle. CETL ALiC and the e-formative assessment groups are furthest along this path so we need to make sure their forthcoming workshops reflect the process as it is developing.

There is much more to say and other team members will give their own reflections on the event. But for me this has been a significant activity and one which has really enabled us to examine what we are doing. There is a lot still to do but we are definitely making progress! The challenge now is to keep focused on these critical elements of work.

Pattern Formats and Structures

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.

Thinking about structures

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?

Workshops?

In the Learning Patterns project, we drove the pattern language development by a series of workshops. As we discussed at the kickoff, it would seem valuable to replicate, refine and elaborate that strategy.

Part of the workshop methodology itself has been captured by a pattern, and there’s a set of videos demonstrating the process. There’s also a paper on the way. The workshop descriptions and calls can be used as a starting point for our own proposals. There’s a few conferences coming up which could offer good venues:

ALT-C 2008: Rethinking the digital divide
9-11 September 2008, Leeds, UK
deadline, 29 February 2008
http://www.alt.ac.uk/altc2008/

The Shock of the Old 7: Web 2.0 and the Connected Future
Said Business School, University of Oxford, 3rd April 2008
http://www.oucs.ox.ac.uk/ltg/events/shock2008/

EuroPLoP 2008: 13th European Conference on Pattern Languages of Programs
July 9-13, 2008
Irsee Monastery, Bavaria, Germany
http://www.hillside.net/europlop/

ICALT 2008: The 8th IEEE International Conference on Advanced Learning Technologies
Santander, Cantabria, Spain
July 1st- July 5th, 2008
http://www.ask4research.info/icalt/2008/
deadline: January 29th, 2008

Tools for Participation: Collaboration, Deliberation, and Decision Support
University of California, Berkeley
June 26 – 29, 2008
http://www.publicsphereproject.org/events/diac08/

project administration documents

I’m a bit baffled about this one, and I suspect others are facing similar problems. In fact, apart from this being a concrete problem we’re confronting, there may be a pattern in here.

We need to agree on a set of document which define the administrative structure of the project. These include statatory documents, such as the consortium agreement, project plan, workpackage details, roadmap, etc. These may be frozen at some point. Other documents will evelove continously over the project life time.

There’s two related issues that I want to consider:

• Which form / format should these documents use?
• How do we manage them.

So far we’ve been using word documents, stored on the google group file area. I see several potential difficulties with this mechanism:

1. It doesn’t scale as a file manager. there’s no support for folders, or any other scheme for managing large number of files.
2. It doesn’t support collaborative editing, commenting and versioning. Let’s say I want to suggest an ammendment to the plan. how do we facilitate this?
3. Some forms of administrative knowledge ae better represented as mindmaps, gantt charts, spreadsheets, etc. How do we choose formats?

There are several alternatives we can consider, but none seem ideal.

Option 1: version control

We have a subversion repository on the google code site. We can host all documens there.

Pros:

• consistent. one place for all outputs.
• easy to browse.
• supports versioning (obviously).
• extreme transparency.

Cons:

• everyone needs to master subversion (not too hard to do).
• extreme transparency.

Option 2: wiki

Pros:

• easy to use.
• supports versioning.
• managed transparency.

Cons:

• easy to mess up.
• limited editing capacity.
• potential problem with exporting to deliverable format (depends on particular clone).

Option 3: google docs

Pros:

• easy to use.
• supports versioning.
• managed transparency.
• familliar format.

Cons:

• limited editing capacity.

Option 4: document management system

Pros:

• does all we want.

Cons:

• costs money.
• requires maintanence.