Last week, I went to a workshop run by the PLANET project about pedagogical patterns. In case you haven't come across it before, the term 'pattern' is a semi-technical one with origins in architecture. Very roughly a pattern consists of a problem and a solution at an appropriate level of abstraction. The idea is particularly popular in software engineering which is how I first came across them. I don't know how widely known the concept is elsewhere. The Hillside Patterns Library is a good general site about patterns. You can see the patterns compiled so far by the PLANET project and also the work of the separate pedagogical patterns project.
With my mathematical leanings, I go a bit gooey at the idea of systematising all that stuff that's known about education that's out there. I think there are still some question marks however. Ultimately with this type of thing we are trying to help people teach and hence help students learn. For me there are two big challenges. How do you go about doing this systemisation and how do you decide what to include? And then, what do you do with all these patterns when you've got them? Indeed are they are useful form in which to systematise things?
As a researcher, evidence and abstraction are both important. However these aren't necessarily so crucial for your average teacher or lecturer. As a teacher have to make decisions about how you are going to teach and there's a fair chance that there isn't going to be much evidence available as to the exact best way to do that. You're happy to base your decisions on your own experiments or those of people you talk to. If something evidently helps your students you learn, you probably don't care too much whether there's research-standard evidence for its effectiveness.
Abstraction on the other hand has two problems.
First most folk just aren't all that good at it (however odd this feels to those of who revel in it). There's some interesting work by the EPCoS project that indicates that lecturers actually need examples that are context-transparent rather than context-independent. They used a format that I rather like called a bundle instead of a pattern.
Secondly abstracted ideas can get dry and dull very quickly. I mentioned at the workshop that I've got a book on my shelf about user interface design patterns that despite being an obviously excellent and comprehensive book, I never touch despite designing interfaces on perhaps a weekly basis. The patterns that I do use are ones I've not learned about from a patterns catalogue.
Of course this doesn't mean that trying to build up pattern libraries is a useless activity. Some people might find reading an atlas dull and it might not tell you everything you want to know about geography but it doesn't mean that atlases useless to geographers.
Another good analogy was the classification of groups. Groups are mathematical objects related to symmetry and mathematicians have put a great deal of work into trying to classify all the groups that can possible exist. They've classified all the building blocks for groups that aren't infinite. In fact there's an impressively big book called The Atlas of Finite Groups.
Now you wouldn't even start to think to introduce somebody to group theory by giving them The Atlas (as it's known). It's research-level stuff and it's important that it exists, but you'd probably do several undergraduate level courses on group theory before even being told about it. Likewise, I think the peril with patterns is that you give people to a catalogue of patterns and expect them to use it, whereas you actually need to introduce them to the ideas in a completely different way.
But I think that problem can be surmounted. More fundamental I think is the issue of how you compile patterns as you hit the usual problem of 'quality standards'. You can abandon quality standards as we have with the Cloudworks project (in the same way that the web abandoned quality standards) and then rely on clever ways of filtering. Or you dedicate effort to quality assurance, which is less sustainable and means you will miss out on lots of useful things for practice for which there is no evidence of effectiveness, or that somebody just can't be bothered to write up to the required standard. Now the latter option is still achievable and useful, but it's going to just one part of helping the folk at the chalkface rather than an entire solution.
One thing that I heard about at the workshop from Helen Sharp did really spark my interest was hearing about patterns libraries that are very much owned by the communities that own them. I haven't yet gone away and found out the details, but it sounds like a more sustainable model in the end than holding workshops with the potential users of the patterns. It's cutting out the middle-man I guess, but I suspect that like building any community requires skill to do well.