I took us quite time to arrive at this map. We tried various techniques and approaches. First, we tried to draw a graph of the links between the patterns. That proved to be too thick in some points (highly connected patterns), too thin in others, and not very informative in general.

Then, we tried a table-top concept mapping at a workshop, where we asked participants to draw out key concepts and map them on the table using post-its and coloured thread. This was a good exercise for participants, helping them establish a common language and identify the contingencies of the domain. However, it didn’t give us anything we could work with as an organising structure.

In the end, we went back to the fundemental question: if having a map is the solution – what is the problem (and the context)? We realised that in the context of our group the primary value of the map, or any organising structure would be to provide a means of navigating the language. To that effect, it has to be simple and informative. Too much information would be just as bad as too little. Think about the London tube map (thanks Jim, for the example). Beck’s genius was in understanding that the design of the map should be functional rather than structural. In other words, scale or any geographical refernce was irrelevant. The map should show you in the simplest and clearest manner how to get from station A to station B (and what fare you need to pay). This resonated quite well with what I remember Helen Sharp pointed out at October meeting. She refered to the papers from the pedagogical patterns project. Most of them start with an easy to grasp table that organises the patterns below into clear categories.

Nevertheless, once we had darted the patterns over the table, the gaps were apparent. Which, as Janet always reminds us, is the second important function of an organising framework.

Conclusions?

An organising structure is not an Aristotelian hierarchy. It is functional, not structural. Or rather, structural to the extent is serves its function. Organise as a verb, not organisation as a noun.

We should expect many mappings of the same space, each internally coherent but each partially covering the space and overlapping with others.

Maps may take any arbitrary shape – spiders, tables, trees, graphs, etc. The mapping tool should afford this. Personally, I recommend creating maps in SVG using inkscape. Unfortunatly, some primitive browsers don’t support embedded SVG, but I trust our users to have enough sense to use decent software (and in any case, we can export images for the poor).

Thanks to the good work of Ajdin, we now have an HTML API that serves Patterns and Cases in XML, PLML, RSS or CSV. I’ve also added a generic API, which allows you to browse all object in the system in XML/HTML.

The intention here is to allow other design pattern / learning design repositories to interface with our system programmaticaly with as little effort as possible. Other systems could list our objects, include them in searches, support easy linking, or offer an alternative interface (read only, for now).

But there’s also a caveat: we’re still in the experimental / conceptual phase. These APIs work, but they are also subject to change. We give no guarentees of backward compatibility. So if you use them, make sure you wrap them with an abstraction layer on your end.

Our cases have a “group / workshop” attribute. This is because we collect them from various communities, and the participants in these communities want to quickly find their peer’s contributions. We didn’t have a similar attribute for patterns, thinking that the whole point of patterns is to promote generality and knowledge transfer. Now, that is still true, yet on the other hand we can see several distinguishable (if not distinct) languages emerging. Patterns for e-Assessment are a cluster apart from HCI patterns etc. After all, this is the pattern language network.
So, should we add a “language” attribute to patterns? Should it be single or multiple choice?

On Thursday we had the 2nd practical inquiry day of the formative e-assessment group. The focus of this day was collecting case stories and identifying seed patterns (aka proto-patterns).
To get people in the right mood, we started with the Eureka! game, which we first tried in Singapore. You have to try it – it’s such great fun, and brings out the hidden truths about learning.
It’s also a great release exercise before diving into case study writing. After playing this, people loose all inhibitions, and the stories just pour out.

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.

When we engage with practitioners, the first thing we ask them is for a case study. That seems to be an overloaded, somewhat obscure creature. We think we know exactly what it means, or at least what we’re looking for, but it turns out that the term is so widely used in so many ways, that it can go any odd way. Often people bring their personal statement of beliefs and achievements. In other cases, they will give a marketing presentation of their project or institution. All we really want is a good story. Believe me – that’s pretty close to the best place to start a discussion, which is what Planet is all about…

We developed the S.T.A.R.R template, which we provided as a powerpoint template and as an online form. That helped, but usually only after some verbal introduction. So here’s that introduction as a (hopefully) free-standing, self-explanatory slide deck:

Please let us know how to improve it..

(And if you’re struggling with the more technical issues, there’s the help page. )

I met Ademar Aguiar at EuroPLoP last week (note to self: need to report on the conference, it was a great event). Ademar is a long-standing member of the pattern community and something of a WikiGuru, he’s one of the organizers of WikiSym, but I’m digressing.

Ademar and his students are working on PatternSeer.org, which is a web2.0-esk clearing house for all things pattern. PatternSeer allows you to submit design patterns and pattern related papers, rate them, discuss them and share them. Needless to say, it allows you to search across sites.

This covers just about everything that the Planet platformdoesn’t do. We provide a structured participatory methodology for developing patterns and pattern languages, and the authoring tools to support that. We’re strong on the editing and storage, but pathetic on the social aspects and cross-site search.

We’re having our own “summer of code”. Planet is offering one or two intern opportnities for students of computer science or related fields.

Interns will contribute to the exploration of novel forms of knowledge representation, organisation and visualision in this domain. A solid knowledge of a high level programming language (e.g. Java) is essencial, as is a creative approach to web development.
Please note that this is not a paid position.