Pattern Formats and Structures

I want to try to summarise some of the discussion that we have had about pattern formats and structures, so that we can make the necessary decisions to take us forward.

1. There is agreement that “Illustration” should be added as a standard field and that we should encourage use of visual representations, such as diagrams, more generally.
2. There seems to be a consensus that “Aim” should be changed to “Problem”. Because of some restrictive connotations of using this term which have been mentioned, we should provide supporting text and examples to indicate that this is meant in the sense of what issue the pattern resolves.
3. The question of the confidence rating for patterns has been raised. The view that this should reflect the level of confidence in the pattern as a pattern, and not just its level of development, seems to be generally agreed. Some further discussion is required to determine how this could be reflected in the form of usable guidelines.
4. There has been discussion about a range of detailed additional information in different categories which relate to the main parts of the pattern (Problem, Solution, Context), or to the pattern as a whole. Suggestions include subsections for rationale and evidence. The experience of the formats used by other pattern repositories will be useful to us, to help decide on a compromise between the requirements of precision and standardisation to aid pattern interchange, and flexibility and simplicity for users of the pattern network. A draft structure is available on the Planet Wiki, and can be the basis of further discussion. My general preference is for fairly broad categories, with a number of more detailed optional subcategories prompted by a set of guidelines and suggested questions, with examples to indicate how these can be applied.
5. How we deal with the formative stages of a pattern has been discussed. This is a pressing issue as it affects how people use the Planet platform, and any changes agreed need to be implemented soon as it would be difficult to change things retrospectively. There appears to be a consensus that the seed/proto patterns are not patterns, and thus must be distinguished from patterns – even ones categorised as having a low level of confidence attached to them – in some way. How this is then reflected in the pattern and platform structure still needs to be resolved. These are some of my thoughts on this. I will use the word “proto-pattern” for convenience, but what term we actually use needs to be agreed on.

The processes associated with creating a pattern, as against refining and seeking to increase the level of confidence in it, are obviously linked. However, especially when considering the initial stages of pattern creation, there are also significant differences. A simple way of looking at this question is to consider the components that make up a pattern, which we are currently discussing with regard to specifying the pattern format. In defining the problem, we need to understand what the forces are that need to be resolved. The solution both needs sufficient evidence from actual cases (a minimum of 3 according to the rule of thumb we have agreed on), as well as an understanding of what other patterns would be needed to provide a complete solution. The context specifies the conditions under which the pattern applies, but also connects it to other patterns at its own and higher levels. Therefore, even before we can even consider something to be a pattern, we have to look for other relevant cases and practice, look at the practice and theory of associated problem areas, and relate the prospective pattern to a wider conceptual framework. The questions raised and activities required at this stage thus will centre on resolving these issues. Of course these processes are also relevant when we reach the pattern stage, but while the processes associated with a pattern are primarily focused on its use to solve a particular problem, for a proto-pattern it is primarily focused on the formulation and development of the pattern and pattern language.

The distinction between proto-patterns and patterns should not be seen as a formal or linguistic one. Rather it reflects their different roles. Indeed, for a considerable part of the period of development of a proto-pattern, it may be uncertain whether it will progress to pattern status or not. It is potentially confusing to people using the Planet site, who may expect more from what are labelled as patterns, unless this distinction is made clear. At the same time, having a means of representing and developing even very rudimentary proto-pattern ideas is vital. Clarifying how we do this will be particularly important at the current juncture, where we are beginning to discuss with others how we interface with systems that may be the source of such ideas.

How would this affect our current framework? Obviously we should have some guidelines that explain the distinctions, but reflecting this in our systems and pattern formats requires careful thought. In practice, although we need to draw the distinction between proto-patterns and patterns, we also want to create a smooth transition between the two. If feasible, I would prefer a common format, with an interface that was effectively context sensitive, and presented different options and questions depending on the proto-pattern/pattern status indication. As an example, for a particular part of a proto-pattern, questions may prompt the user to look for examples where a proposed solution does not apply, to help establish the boundaries of context for the pattern. In the case of the pattern itself, this part would state what these boundaries were, and indicate relevant related patterns. There would need to be a process, perhaps using a simple checklist, that facilitated the transition from proto-pattern to pattern. Underlying this would be the simple criterion for deciding whether something should be given pattern status – namely: “Can it be used as a pattern?” Opinions on this issue would be particularly valuable, as we need to move to a decision very soon.

yongfook made me friendfeed

Here’s what I learnt from this presentation:

• Blogs are not what they used to be (ok, I knew that, but he has nice graphs).
• Lifestreams are the new blogs (ok, I knew that too, but he has some nice links and examples).
• When you post on slideshare, have a good joke on slide 1.

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?

PatternSeer and the Planet platform: this looks like the beginning of a wonderful friendship

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 platform doesn’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.

This has mashup written all over it. We need a pattern language interchange API, which would allow PatternSeer to crawl the Planet platform and the the Planet platform to piggy-back on PatternSeer for search and social features. And here’s the first shot at a project spec.

Scoping a vision for formative e-assessment

The centre for Work-Based Learning for Education Professionals, at the Institute of Education,  has been commissioned by JISC to conduct a study on Formative e-Assessment process modelling.  This study, based on a combination of desk-based research, case study building based on empirical data gathered from practice, will survey existing literature as well as sample practice in the field to identify effective models of formative e-assessment and the software tools to support them.

Formative e-assessment is understood as the use of ICT to support the iterative process of gathering and analysing information about student learning by teachers as well as learners and of evaluating it in relation to prior achievement and attainment of intended, as well as unintended learning outcomes.

The outcomes of the survey will combine theoretical and pragmatic resources, in the form of a literature review, case studies, and semi-formal models of tools and processes, to serve as requirements for software development.

The formative e-assessment project team has chosen the Planet platform and methodology as a central part in its framework. The team will use a a group space on the Planet platform to collaboratively author the literature review, and then use the tool provided to record their case studies and patterns, building on Planet’s methodology of Pattern elicitation workshops.

Internships with the Planet project

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.

For further details, contact: Yishay Mor.

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

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)

server pains

This is probably a situation many projects are familiar with. Any advice is most welcome.

As mentioned earlier, we need to develop and host a web-based system for collaborative authoring of pattern languages. We decided to start from a modular wiki server and enhance it as needed. Following the discussion on the development wiki, we identified XWiki as a suitable platform.

The next step should be easy: download and install a copy of XWiki, and play around with it. But actually, it looks like if we can get past this part, the rest would be a walk in the park.

The problem is, that like most academic groups we’re faced with three options:

1. Institutional web services, which use a very specific setup, and do not have the capacity to support our unique requirements.
2. A dedicated server at our disposal, but self-supported  (actually, this option makes us luckier than most).
3. External hosting with a commercial provider.

Unless your institute is very adventurous, option (1) doesn’t cut the mustard. It is built to provide department with centrally managed static pages.

Option (2) would normally be OK for me, but for most people its too much of a hassle, or simply outside of their comfort zone. Unfortunately, for various boring technical reasons, in this case it hasn’t worked that well for me. I’ve been struggling with my server for a few good days, and still can’t get her to yield.

Option (3) is usually not too bad, except that it raises a question of sustainability: if we pay per month, how do we keep the site running after the budget is gone?  However, in this case there’s a more urgent issue: most hosting providers do not like to provide Java for some reason. Either they politely send you home just for asking, or they quote you at 5-10 times the usual price.