Archive for August, 2008

One of the nice things that happened at the Singapore workshop was the introduction game we played.

Every one of us has these Eureka! moments; personal experiences were we learned something in a way that was etched into our memory. Positive, formative events of learning, the kind we wish to engender in the environments and activities we design.

To get people in the right mindset for the workshop we asked everyone to draw (scribble, sketch) one such moment. We distributed paper and markers, and instructed participants to tell the story of their Eureka! moment in images. They could use words as part of the drawing – in speech bubbles etc. – but not as a way of telling the story.

People stood up, showing their drawing, and we used that as a started for a discussion on design principles. We then hung the pictures on the walls, and handed out post-its for people to “tag” them with comments.

In fact, it was such a nice game, we thought maybe you’d want to play it too:

Validity

What’s the scientific process of showing that a pattern does what it claims? Is it science, or is it art? What kind of evidence does a pattern need? How can we get the scientific community to accept patterns as a valid tool of knowledge production?

Even looking at Christopher Alexander’s patterns, the question arises. Alexander has a “confidence” measure, but what is it based on?

Resonance

Paradoxically, often as more expert knowledge is embedded in a pattern language it becomes less accessible to novices. The Learning Patterns project has tried to address this issue by a small set of Trails which accompany our pattern language.

But perhaps the problem goes deeper. Again and again, at every workshop we run, we see how hard it is for people to “get into the pattern groove”. Primarily, patterns are about abstraction without loosing context – and I think that is precisely what most people find hard. No wonder patterns have caught on so well in software engineering communities. After all, abstraction in context is what software engineers are trained to do.

So how do we break out of the cosy cult of patternisers, and make the knowledge we accumulated accessible to the wider public?

Aggregation

Once there was one pattern language for architecture (Alexander’s). Then there was one for software (GoF). Now there’s hundreds. Spread all over the place. Patterns are supposed to capture the essence of a recuring problem and its tried and tested method of solution. But they are supposed to capture it ONCE. In a way that can be referenced, linked, composed into larger structures or decomposed into sub-elements. What we’re seeing now is a fragmentation which defies the core purpose of the project.

How do we avoid reinventing wheels? How do we make sure that we build on each others’ work as much as possible, and aggregate design knowledge systematically?

Fitting patterns into teachers’ practice

The workshop gave me a lot of ideas, and I can see the value of the pattern approach, but tomorrow I’m going back to my school – how can I use this approach there? How do I integrate it into the existing practices of the school team?

A very good question. Obviously, not limited to design patterns – you could ask the same about any innovative paradigm. But that would be someone else’s problem. In our case, we believe that the knowledge we generate in and between our workshops can help teachers, educational designers and software developers in their daily challenges. Yet if one or two teachers from a school attend a workshop, how will they introduce what they learned into their work environment? They had a pretty hard time taking it all in themselves, now they have to convince their colleagues that the effort of learning a new way of thinking and working will pay off.

The simple answer is that patterns are supposed to help practitioners solve design problems. In order to make effective use of them, teachers need to identify the challenges they need to address and phrase them as design problems, then search for the patterns which can be used in solving these problems.

I can see three scenarios for doing this:

Cross-school / cross-discipline pattern community: build on the links that where forged at the workshop, and use the on-line tools, to support continued discussions of the case studies, design patterns and scenarios which emerged from the workshop. The big idea is to create a circle of expertise which overlaps and connects the innate circles of practice. The members of this circle will bring in problems from their daily experience, and take back solutions derived from others’ experience, encapsulated in patterns.

School-based mini-workshops: Hold pattern workshops in schools, engaging the local work teams. This could be framed as a study group on learning design, meeting for a couple of hours every week. The big idea is to empower teachers as learning designers, by giving them a language and a space for design-level discussion of their daily needs. By using the on-line system, such groups could also benefit from feedback from peer groups and the project team.

Scenario based “media production teams”:Media production team was one of the most powerful patterns that emerged from the workshop (nb: it is still very much a work in progress). The core idea is that students learn by arranging themselves as a team producing some form of digital media – a game, a movie, a collaborative essay. Following the dog food principle, we should apply the same pattern to practitioners’ professional development. Arrange teams of teachers, curriculum designers and software developers, and let them develop eductational media in a new form. The process should use the framework of cases, patterns and scenarios, but should also result in artefacts which can be used in class. Each team would define a concrete learning scenario, compare it to existing case studies, identify relevant design patterns, and experiment with a solution. The big idea is to drive practitioners’ learning, and design-level discussions, by addressing a real problem. As several participants noted, pain is a strong learning motivator.

Finding the patterns I need

I can see how pattern X is relevant to my problem when you point me to it, but how can I find the patterns I need when you’re not around?

This question bring us back to Janet’s comments on structures. It highlights the need for powerful search tools, which can leverage meta-data and semantic information. That is also one of the main challenges implied by the pattern aggregator project. It also relates to the issue of confidence that Janet notes: as a user, I want to know that the pattern I’m going to use addresses the problem I’m facing, but I also want to know it does it well.

All this is a nice way to say that this is a hard problem, and we don’t have any solution, yet. Or at least not an automated one. A satisfactory pattern search tool would require some serious AI, a nice PhD project..

What we can offer is Human Intelligence. Given a scenario, we – the planet community – can suggest relevant patterns. Of course, to facilitate this we need to improve the on-line discussion interface, but that’s a problem of a much lesser scale.

Sustaining a pattern community

We had a good conversations here, we learned a lot from each other. The pattern paradigm seemed conducive to this effect. But to reap the full benefits of this discussion, we need to sustain it over time – form a genuine, vibrant interdisciplinary community. How do we do that?

At the end of the day, that would be – to a large extent – up to you. We provide the tools, the group space, the mailing list, the support – but all that would amount to nothing without your participation. That requires will, commitment, and time. The first two can only come from you. The third also involves your employers. How do you convince them that this is a worthwhile investment? I’m open to suggestions.

Getting the right level of granularity

One of the issues I found most confusing about writing design patterns is identifying the right level of granularity – too specific patterns add very little to a case study, and have a limited scope of application. On the other hand, when patterns are too abstract they have a wide scope, but its not clear how to apply them to any specific case.

This is probably one of the hardest challenges any pattern writer faces. There are no rules, but there are many heuristics.

If your pattern is universal, i.e. “applies always” then it is clearly too general. In defining the context, you should be able to say where this pattern does not apply.

Most good patterns either provide a detailed “recipe” for implementation, or describe an ensemble of more detailed, specific patterns.

Try to phrase the problem description as a configuration of domain-specific forces.

Apply the rule of three: “A pattern can be called a pattern only if it has been applied to a real world solution at least three times.“

But most of all, its a matter of trial, error, shepherding and refinement. So the answer is: just write it, you’ll get it right latter.

Applying patterns

The patterns I saw look very convincing, but I still don’t know how to apply them to the problems I’m facing.

That’s what scenarios are for: you describe your problem, and then discuss it with others, compare it to case studies, and find the patterns that apply. Apart from that, the only way of doing it is just doing it. You have to try, stumble, try again. All this brings us back to the first issue – its hard to experiment with a new paradigm on your own, when your “day job” is so demanding. We need to think how to fit this in.

Learning the language of pattern languages

I feel a bit overwhelmed by the intensity of the day. I never heard about design patterns before, and I found myself speaking a new language before I could get a solid knowledge of it. How do I learn the language of design patterns and pattern languages?

if you participated in this workshop, please let me know of anything I missed. I’ve started working on a detailed case study about the workshop, and I’ve set a page for post-workshop reflections. Of course, you can leave a comment here or drop me an email.

EuroPLoP 2008 was probably the most fun I’ve ever had a conference. Imagine – strictly no powerpoint, no wireless, lots of games and an inexhaustible supply of beer. Ah, yes – EuroPLoP is the European member of the PLoPs family of conferences, which have been the primary meeting points of the design patterns community for nearly 20 years.

Funny thing, how social scientists will stand before a hall full of neatly packed passive listeners and preach about collaborative constructivist learning, while the computer scientists just do it. At EuroPLoP (and I imagine all other PLoPs) you don’t present a paper. You offer it to a workgroup, which will then discuss it seriously, in a supportive yet ruthlessly critical atmosphere, for an hour or so while you play “fly on the wall”. It’s an amazingly intensive learning experience, on both sides.

EuroPLoP 2008 also leaves ample space and time for the real work of conferencing, the stuff that can’t be captured in predefined structure, because it emerges out of the discussions at the time and place. There’s BOFs, focus groups, walks, swims, and well, yes – lots of beer.

Two of the discussions I was invloved in are starting to take on a life of their own, and both are strongly related to what we’re doing here at Planet.

The workgroup I attended was focused on Pedagogical Patterns. The discussions there were so lively, and the sense of common commitment so strong, that we felt we simply can’t let it end there. We’re thinking of various initiatives to take on together over the coming months. You can have a look at the groups space and mailing list.

Over BOFs and dinners some of us started discussing the various attempts to develop repositories, editors and other tools for creating, managing and sharing patterns. We all agreed on the need to coordinate efforts and work towards interoperability. This led to an ongoing discussion, which now also has its work space and mailing list.