Some thoughts about organising frameworks

I’ve been reading Jim’s paper, and Yishay and John’s recent experiences with organisational frameworks for the patterns.I think we have to remember that there is a problem that mapping to an organisational framework is intended to solve. The problem is: how does a practitioner who is new to the system find the patterns that will be useful to them? Ease of locating relevant patterns should, in my view, be the criterion by which we judge any organising framework. True to the Planet, participatory methodology, we have been getting users collaboratively to develop the framework, but the users we have been working with have been essentially the pattern contributors. In doing this, we mustn’t loose sight of the intended end users who come to the system cold and need to locate relevant patterns.

I’ve been trying to view recent Planet experience with this view in mind. In some ways I think it reduces the complexity of the problems significantly – but inevitably increases it in others. So, first the reductions in complexity:

• Concern with mapping tools and process is irrelevant unless the nature of the tool used for mapping affects the usability of the resultant framework for end users
• We can collapse the time dimension. Jim outlines a “decision cycle” which I think, might more properly be called a “development and use cycle”. The point being, that whenever a practitioner has to make a decision, they are effectively in “planning and design” mode. Jim’s scenario of use illustrates this: as the teacher implements activities that generate more information about the students, reviews the design and is faced with deciding what to do next, what has changed is the contextual information available to the teacher, not the fact that they are now consulting the patterns in order to design the next bit of the module. Ie. the use of patterns is for designing – it might be for designing activities, or designing feedback, or for designing evaluation, but the point of use is in the design stage. Collapsing the time dimension enables us to avoid a major issue – that the planning and design process is both iterative and parallel, and thus the time dimension is not a simply connected linear one.
• As John’s group recognised, decisions may be individual, institutional or discipline-wide. In very crude terms there is probably a 1:1 mapping between these levels and time. Institutional or discipline decisions (and hence consultation of the patterns) have to be done a long way in advance of implementation. Individual decisions (and consultation of patterns), can be done closer to implementation (but not too close because by then it is too late). If we accept such a 1:1 mapping, it enables us, once again, to ignore the time dimension by collapsing it into the level description.

So, where does this leave us? Imagine a teacher with a problem consulting the patterns to try to find a solution. I think they will want to locate themselves within the organisational framework through the parameters of their problem – eg. “large class with very varied abilities”, ie. they will be locating the patterns through descriptors of their context. It seems as though both the eFormative assessment workshop, and one of the CETL ALiC groups started to develop frameworks that were based on simple context descriptions.

Some suggestions for where we could go (if we had time):

• Try to establish what the key dimensions of context are. As well as collaborating with users, places to look for evidence would be the forces descriptions in our patterns, the fields used by the pedagogic planner and Mod4L projects, the taxonomies of learning activities developed by the DialogPlus project and by Helen Beetham.
• Develop the pattern tagging system to request tags for the key dimensions, enabling contextual search and retrieval of patterns
• Map the patterns (our collection and others) against the dimensions for a gap analysis.

Talking about gaps raises a further question that we haven’t addressed so far:

• Do the gaps matter? A pattern has an impact if it points to something the designer would not otherwise have thought of. If the gaps arise because they represent such common practice that no-one has thought it worth articulating, then they may not matter (although we would want to be assured that the practice was so common that even novices were aware of it). If, on the other hand, they are gaps because they are crucial parts of practice but rare among our contributors, then filling the gaps would have considerable impact. If high impact gaps have arisen because of the affordances of our methodology, then we might want to reconsider the methodology in the long term.

Mapping the Planet Patterns – and a Pedagogical Framework for Learning

The Planet project has collected and is developing a number of patterns related to using Web 2.0 techniques for learning. How can these be connected to each other to form a language, and incorporated into a wider pedagogic framework that can be easily used by learning practitioners? These questions are looked at in a document available at:

http://patternlanguagenetwork.myxwiki.org/xwiki/bin/download/Outcomes/Internal_Reports/PatternFramework.pdf

 

The document looks at the principles of connecting patterns together into a language, and maps the patterns collected by the project, including patterns that came out of the very successful recent workshop on Digital Identity. It then suggests a general pedagogical model and framework that can include the Planet patterns, and uses a simple example scenario to demonstrate how this could be used in a practical situation to help design a unit of learning.

 

Although diagrams and maps can help in understanding pattern structures and pedagogical frameworks, it is only if these are part of an online dynamic interactive system that they can provide an easily usable practical tool. The document considers what a system like this would look like, and concludes with a discussion on how such a system could interface with other learning tools and systems, which the project has begun to investigate.

Good advice from Balbir Barn

In November Harvey Mellar I had a long chat with Balbir Barn. Balbir has done a lot of work with JISC on process modelling, and is well versed in the design patterns paradigm.

The first thing Balbir noted was that we should be clear about the nature of our patterns: these are pedagogical patterns, and are quite different from what he expected as a software developer. This gave rise to an interesting observation. “Our” patterns are the same creatures as Alexander’s or the gang of four’s. They all –

describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use this solution a million times over, without ever doing it the same way twice (Alexander et al, 1977, p.x)

The difference is that Alexander’s environment is the physical space around us, software developers’ environment is the internal workings and interfaces of the systems they build, and our environment is participatory, web-supported learning spaces. Hence the problems we solve are different, and consequently the patterns we identify. Yet they are strongly connected: pedagogical patterns provide invaluable capsules of knowledge for software developers, in that they highlight rich and crisply defined functional requirements. If I tell a software designer that, for a particular learning activity, I need to provide a narrative space with paper2.0 and video clips as objects to talk with, I’ve told her nothing about how to build the software (and indeed, its not my business to do that) but I gave her a pretty good idea of what I want it to do. Bottom line:

Pedagogical patterns serve as rich functional requirements for system design, and lead to a better choice of interface and software design patterns.

Next, we discussed what Balbir called the “meta-level description” of the patterns. This resonated strongly with the insights of Sally Fincher, Helen Sharp and other guests at our October meeting. Such a meta-model needs to provide two facilities:

• Semantic mapping / definition of the key concepts we use.
• Mapping of links and relationships between patterns, and between patterns and concepts.

For example, if we have patterns that refer to grading issued of skill-oriented learning in large classes of blended learning, then all these should be nodes in the map: “grading”, “skills”, “large class”, blended learning”. If the roles in such a context are learner, tutor, course leader, learning technologist, then these too should be defined and linked.

A meta-model / map does not need to take any specific form, but it should allow a representation of nodes of knowledge / concepts and links between them. This could be captured by a concept map, topic map, knowledge map, UML diagram, etc. Mind maps are problematic because they impose a strict hierarchy.

Mapping could be top-own or bottom-up. Working top-down would appear to be a more theoretically solid approach. However, it has two serious shortcomings:

• The sparseness of our content might result in a coverage of the map that is too thin to be meaningful.
• There may be many alternative and equally valid meta-models for describing the same domain. A top-down process will have a hard time differentiating them. A bottom-up process has one advantage – it is guaranteed to cover some significant concerns of some portion of the practitioner community.

To a large extent, this matches the approach we took at the learning patterns project, (see: Winters and Mor, 2008). There, we boot-strapped the pattern language by developing several typologies – structured glossaries of key concepts. These were continuously refined as we developed our cases and patterns. The patterns themselves were arranged in a tree-structure by their function and level of abstraction. Bottom line –

Provide two meta-level descriptions of the language: a semantic glossary of the lexicon and a functional map of the patterns IN THE LANGUAGE

Turning to the structure of the individual pattern, Balbir suggested that we encourege authors to clearly specify role and relationships in the solution descriptions. This should be a soft scaffolding, just like the recomendation to describe the problem as a tension between forces. It is likely to be a useful form for describing the solution, but we should not impose it.

Finally, we discussed the diagrams, or visual models to include in the patterns themselves. We all agreed that this was a fundamental element, yet at the same time we need to take care to avoid over-engineering. The diagrams need to provide enough freedom for the designer to apply her judgement and adapt the pattern to her specific context and specifications. In the case of the formative e-assessment group, Balbir recomended the use of sequence diagrams as a standard.

These recomendations where implemented in the next two workshops, but that’s for another post.

pattern browsers that make you go ahhh

I’ve recently come across these beautiful pattern browsers from Interface Design Team of the University of Applied Sciences Potsdam.

Of course, my immediate reaction was “I want one like this”. Its not surprising that an interface design / information visualisation group can come up with a better interface than our humble table. But there’s more to this than aesthetics. These browsers are functional. They are designed to help you find the pattern you need, when you need it. This makes me think about our quest for organising structures. Our primary criterion for choosing a structure should be functional. After all, isn’t that what pattern are all about? Providing a solution to a problem in context? This suggests that there isn’t a single-size map. Each domain of practice will have its set of contexts and problems, and the organisation of patterns for that domain should be driven by them.
Another question that emerges from these examples is: do we need fixed structures at all? Google made its fortune on the claim that where search is powerful enough, you don’t need structure. These patterns browsers allow you to search by specifying your needs. Although they don’t display any fixed structure, you can find the patterns that fits your problem in 3 clicks.

Planet 2-day meeting

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.

Organising structures

One of our aims in the Planet project is to explore possible organising structures for our learning patterns – the “language” bit of what we are talking about. This is probably the most elusive element of the pattern approach – there are many individual patterns and there are pattern collections, but genuine pattern languages are few and far between. Organising structures are not trivial!

So what are we looking for? We want a structure that captures the relationship between our patterns. It should allow us to find the pattern we need for a particular context but also the patterns that are nearby. It should help us to use the patterns to create new solutions. It should also illuminate the “gaps” where we might need a pattern but where we don’t yet have one. Indexes are not enough.

A starting point for consideration of an organising structure for teaching practice has come from discussions with Sally Fincher who is leading the Share project, with which Planet members are collaborating. This organising structure is based around decision points – when, where and at what level we make decisions about our teaching practice. Sally has produced the following initial suggestion for such an organising structure and given us permission to post it here as a starting point for further debate and discussion:

The promising thing for me about this structure is that it does potentially provide our three basic requirements. If we mapped patterns onto the structure you could immediately see the patterns that were relevant to your current decision point as well as those closely related. You could work through the decision process using the relevant patterns at any point. And it would be immediately obvious where patterns were missing.

Our next step is to try to populate and refine the structure using both our own seed patterns and the collections that are publicly available. Thanks to Sally Fincher for allowing us to explore her structure in this way.