Validity, Resonance and Aggregation

I’ve been chatting with Christian Kohls of Knowledge Media Research Center about pattern languages, workshops, community engagement, and the big picture. The discussion brought up some issues which where floating around EuroPLoP, and resonated with recent discussions on the Liberating Voices mailing list (pss – the book is out).

I see three major challenges pattern language communities to address:

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

In the Learning Patterns project, we noted:

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?

Who would have thought?

.. that the dog food principle has a doi number.

Singapore: what our users want

Just finished a great workshop in Singapore. We had the great opportunity to work with teachers, curriculum designers and software developers from Singapore’s future schools programme.

We heard about a lot of daring experiments, and even more daring plans to use participatory technologies (Web2.0, MUVEs and games) in education.

Apart from the 8 case studies and 6 patterns, the workshop generated some excellent questions.

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?

Read, read, read. And go to conferneces:

• Wikipedia is obviously the first place to go.
• Our bibliography page.
• Google scholar.
• The Learning Patterns project has some pointers to start with.
• Hillside organize pattern workshops around the world – highly recommended!
• And of course, follow our groups and workshops.

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.

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?

Sharing practice – a shared problem.

End of the first day of the JISC Innovation Forum and the issue of sharing practice has cropped up several times already. How do we move from having swathes of useful information hidden away at best in reports and project websites and at worst in the heads of experts to making it available to practitioners in a form and at a time that it will be useful to them? This is exactly the problem we are exploring in Planet so I was pleased to see that it is recognised as a significant issue well beyond the scope of the current project. Tomorrow Jim and I will be presenting the project in the Market Place (9-10am for those who are in Keele) – hopefully the start of a dialogue on how we can extend its reach and use the process to support the wider JISC community.

Planet makes stuff together

I had the rather rare but very welcome opportunity of acting as non-participant observer in yesterday’s “Making Stuff Together” Planet workshop at LKL. As we had started the day with a Planet project meeting we had a full complement of “staff” for the workshop so some of us stepped back to operate recording equipment and observe proceedings.

The theme for the day was “Making stuff together”, the aim to consider submitted case studies of teaching and learning in collaborative environments and tease out the elements that were successful in order to seed patterns. We had representatives from a couple of other Emerge projects on the day (APSTAIRS and MOOSE) as well as colleagues from elsewhere. It was a mixed group – some with particular interest in patterns and pattern capture, some with little knowledge of patterns but an interest in making things in MUVEs, others with interests in creative online collaboration tools. The potential for not finding commonality seemed high!

However we should not have worried. From the explanation of the first case study (of using Flashmeeting to support collaborative design activity) the group were engaged and animated, picking up connections relating to collaboration across a range of applications from World of Warcraft to Google! By lunchtime we had half a dozen potential “seed patterns” which were then taken up enthusiastically by the group in the afternoon and developed further. There is still work to do on these but the outputs of these labours can be found on the Planet wiki pattern page and feedback and comments are welcome from all (check the Created on 7th July ones – though comments are welcome on them all!).

As an observer it was also very interesting to see how the process worked and I can see some potential patterns emerging here as well. Group formation was certainly an issue both here and in our online workshop at the June Emerge event. Facilitation needs to carefully balance team and participant engagement and it is important to establish common ground in advance. Interestingly all of these were also highlighted in the discussions of making stuff together suggesting much similarity whether we are dealing with Second Life, face to face workshops, Elluminate or Google Docs. It is the human activity of collaboration which is critical, not the technology.

Thanks to all the participants for a really stimulating day – and to Yishay, Steve and Jim for facilitating it. Our next workshop is scheduled for July 21st in Leeds and is focused on one of our user groups, the multi-institutional CETL on Active Learning in Computing. We will be looking at experiences in assessment, project work, learning spaces and Web 2.0. Although primarily for this user group, other participants are welcome. Full details will be posted here as soon as possible but in the meantime if you are interested in coming along just let me know – j.finlay@leedsmet.ac.uk

Guest post: Justin Smith on “Collaborative Thinking for a Pattern-Based Knowledge System”

Justin runs a blog called Designing a Sustainable World. He’s also involved in the Liberating Voices! project, which has been a great inspiration for me. Over the last few weeks, we’ve come to realize that there’s a lot in common between what we’re planning for our system, and what he’s hoping to develop for his projects. I thought the best way to share our thoughts and broaden the circle of discussion is to invite him to do a guest post on our blog. So without further ado, I give you Justin Smith:

So for the last year or so following the conclusion of a research project focused on a socio-technical pattern language (Liberating Voices!) I have been left thinking of ways in which patterns could be made more accessible to a broader audience. One of the many ideas that came to the fore of my attention was that pattern language users need more appropriate technical systems, specifically designed to support pattern development, and perhaps more importantly, pattern use for real-world problem solving. This perceived need was a central outcome of the research, and has prompted further investigation leading me into a PhD program where I could focus my attention specifically on addressing this issue.

About a year ago I had the honor of running into Yishay Mor (virtually) on a mailing list dedicated to pattern languages. Based off of our subsequent conversations it quickly became apparent that many of our ideas and interests were parallel, even though his work is centered on education, whereas mine is focused on natural resource management. Nevertheless, over the past several months we have continued to uncover increasing similarities in our ideas for promoting and developing pattern based systems.

Now, in the past few days an interesting conversation has developed. He and a group of colleagues have been actively mapping out the specs for creating just such a system, following their own research outcomes. Recognizing that we are essentially working on the same project we have begun to share some ideas. With that in mind I have put together a synthesis of some of these conversations.

In addition to the things that have already been defined as necessary components for the system, we have come up with some other things to consider.

1.) Patterns as Hubs, where case studies are linked as evidence for a particular pattern, as well as case studies linked to provide insight into how pattern users applied specific patterns and the outcomes associated with the work.

2.) Pattern Visualization (with several different approaches to include: mind-maps, concept maps and influence diagrams)

3.) Versioning to track the evolution of visualized pattern maps (addition to current versioning of text-based patterns)

4.) Ability to provide geographic boundaries to place based patterns (GIS/Google Maps?)

5.) Ranking of pattern relevance to specific forces/context to aide in pattern searching (similar to an Expert System)

6.) Parallel Development of Django/Google Appengine based version of the proposed system

7.) Interchangeable API between Appengine pattern system and Java based pattern system (enable easy communication between pattern systems built on different platforms)

By adding these pieces to the specs or at least in reiterating the importance of the pieces already described in the system, we can hopefully construct an application that can be usable across multiple domains. In this sense, by providing a range of capabilities this system could be just as useful for people working in the education field as for those working in natural resource management. Following an implementation of these components or at least some derivation of them, it will then be useful to see how such a system supports the work of educators and resource managers.

—
Justin G. Smith
Research Assistant,
Washington State University
Center for Teaching, Learning and Technology
http://www.ctlt.wsu.edu

Blog: http://heuristicthinking.blogspot.com/
Website: http://publicsphereproject.org

Thanks, Christian!

Christian Kohls from IMW/KMRC has contributed two brilliant sets to our slideshare group. Christian gives a good introduction to “what is a design pattern” and addresses deep issues of “where do patterns come from”. This looks like the beginning of wonderful conversation…

comic etude

watch this space

Twine is looking like the first real world web3.0 (aka semantic web, aka ggg) service. Twine introduces itself as –

a new service that helps you organize, share and discover information around your interests, with networks of like-minded people. You can use Twine individually, with friends, or with groups, teams and communities.

yawn. been there, done that. right? except that Twine is semantic. It –

… automatically organizes information, learns about interests and makes recommendations. The more you use Twine, the better it gets to know you and the more useful it becomes.

In Twine not all tags are equal. A book’s author’s name is not the same as the place he lives or the organization he’s affiliated with. And not all things are equal, a book is not a bookmark, is not a video about it. Twine distinguishes between things, and tries to display content appropriately to its type. It also tries, with some success, to guess types tags and categories. Really interesting stuff. And it’ll be even more interesting when they get it to work properly (they’re not that far).

Another intersting thing about it is that everything is a twine, which is a kind of stream of stuff, and you can tune to, create and interleave many twines. So there’s the stuff I share with my family, the stuff I share with my office friends, the stuff I share with my highschool mates. There are some overlaps and cross-connections and I can manage them all by routing items to twines and inviting people to listen to the relevant threads.

A fresh approach, but is it too complex? It looks like its been designed for networked minds. Those of us who have been to all the twitters and pownces and are ready to move on. How many are there? And will our normal friends be able to follow a single twine, ignoring the rest? Time will tell.

Planet, of course, is dog-food principle compliant and has its twine.

(first published on Yishay’s blog)