Archive for the ‘patterns’ Category

There are a couple of things that make patterns distinct from other forms of design guidance. One is that they are routed in practice – they are not simply “good ideas” or theories (not that there is anything wrong with those) but they are drawn from real examples of things that have worked to solve problems in specific contexts. Another is that they cannot just be based on a single example – a pattern can only really be called a pattern if it can be demonstrated to have worked in at least three distinct cases. We call this the rule of three. We recently reviewed all the “patterns” that have arisen from our workshops and most fall into the “candidate pattern” category – we think they might be patterns, we have one – occasionally two examples of the pattern – but we don’t yet have sufficient evidence to be confident that this really is a pattern.

So we are looking for evidence in the stories of successful practice that we all have as educators. Our Elluminate story telling session on Tuesday with the EXTEND project brought up several examples which – at least on the surface – seem to be evidence of one or other of our candidate patterns. We plan to hold more open story telling sessions over the next couple of weeks. Prior to that we will be publishing summaries of our existing candidate patterns so that people can easily review them and let us know if they have had any experiences relevant to any of them.

Pattern elicitation is an ongoing community process – and we expect the Planet patterns to be evolving and developing long after the of the project through other initiatives that are already in progress. But we’d like to make the most of the wealth of experience in Emerge to gather evidence! Watch this space.

I had a meeting with Tony Linde (U&I Semantic Web) and Vania Dimitrova / Lydia Lau (AWESOME project – Leeds Uni) today where Tony looked at how the semantic web might be applied to JISC projects. With regard to Planet Tony suggested that there were opportunities to apply semantic Web approaches, particularly when we seek to make use of patterns in our pattern store and represent them to users who seek solutions /make decisions about various aspects of designing and delivering learning experiences. I think we should follow this up at the face to face meeting on Dec 15th.

One other outcome of this meeting relates to the AWESOME project and the fact that they have collected together a series of examples from both staff and students of things that worked across the various phases of writing a dissertation. Thisseems to present an opportunity to capture both a collection of case studies and abstract potential patterns for use within Planet. I suggest that we agree a way forward with AWESOME on how to achieve this.

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.

This pattern is far from complete. The discussions around it are still hot, and you’re welcome to pitch in. But even in its current form, it is worth a read. This pattern uses a clever grading scheme to promote students to make a serious effort to get the answer right, and then make good use of the feedback they receive.

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”):

Examples (cases where this pattern is seen)

Rationale (principles, evidence from literature etc to back up pattern

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.

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.

Last week Jim, Steve and myself were invited to a Cloudfest with the Cloudworks team. A lot of interesting stuff came up (see George’s post). Among them, the question of sharing design objects (patterns, resources, etc.) across sites and the visual aspects of design objects. This resonated well with some the conversations we’ve been having here, as well as with recent discussions on hillside’s pattern languages mailing list.

We’ve been talking about the structure of a design pattern. The jury is still out on the definitive form, but we all agree that having visual elements is integral to a design pattern. So now our template includes slots for icon”, “illustration” and “diagram”. The icon appears in indices, the illustration appears at the top – as part of the motivation or inspiration for the pattern, and the diagram elaborates the solution. All three are optional, of course.

The issue of sharing information across sites is subject to a hot debate. When I record a pattern in our system, how do users of other repositories find it? In the case of Cloudworks, the idea is to broker design knowledge between communities – how do you populate the system? Part of the answer is in agreeing on a wire protocol and data format, and keeping them simple. The pattern eXchange section has a first draft of a semantic scheme which could be the basis for such a duo. Another part is indexing the aggregators (repositories, search engines, brokers) out there.

What else is new on the platform?

Well, the pattern and case study templates are slowly getting out of their teething phase. Email notifications are active (albeit clumsy). So, good progress – but if you’re looking for a programming project, we always have something interesting to offer.