We have produced a short video which provides an overview of the project and our methodology. Many thanks to the EXTEND project for their assistance in developing this and to Jakki Sheridan-Ross for her production. Enjoy!

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.

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.

Our project has adopted a broad range of web-based collaboration and communication tools. First and foremost, because we believe in the value of these tools to support our work. As a bonus, using the tools we’re researching to support our research provides us with a perfect case study: us.

Almost two months into the project, its good to stop and assess where we are and where we’re going.

At the launch meeting, we identified having a project website as a high priority. During a coffee break, Steven bought the domain, I registered a wordpress blog, and within minutes we were rolling. A couple of iterations, and a few minor misunderstanding later (e.g. the difference between a wordpress profile and a profile on the people page) and we were ready to launch the site. We decided to keep the blog as the front page for the project, as it gives our users and friends a good focal point.

The site has a simple and intuitive structure. Apart from the front page, it includes the following sections:

About: a brief description of the project.

People: list of team members, each with a picture, a short bio, and link to personal site (if available).

Resources: links to our main tools, with descriptions, and to some related projects.

The sidebars provide quick access to most of the tools listed below. This way, the site is a showcase and a group workspace at one, making all our products immediately available to the community – as well as the process by which they are derived.

We agreed to use mailing lists and shared documents as our primary channels of internal communication and coordination. Using google groups, we set up three lists:

general interest: low-volume, announcement only, for anyone who wants to keep a tab on the project.

members: invitation only, any member can post. this is the main communication channel for team members. Any issue which requires coordination among partners will be discussed here. Even when an issue only involves a sub-set of the team, the list is CC:ed for archival and to keep everyone informed of all aspects of the project.

One of the issues that came up was sharing documents: plans, reports, meeting minutes, etc. At first, we tried circulating them by email. This is problematic in terms of managing documents, versions, etc. Next, we tried sharing the document as files or pages on the mailing list web-space. This too proved inadequate, as the filing and editing facilities were limited. Eventually we decided to use google docs. Any document that needed collaborative editing, commenting or archiving was created there and shared with all team members. We are considering having an index of key documents as a page on the members list web-space.

We decided to use google calendar to share dates and events. This should include deadlines for conference and journal submissions, meetings, milestones, etc. So far, only one event has been listed (project meeting, Monday, 14 April).

The main goal of our project is to develop a pattern language for using web2.0 technologies in higher education. Inter alia, we will need to develop a structured set of web-based tools for collaborative authoring of pattern languages. This effort is also marked for an open, collaborative process. To support this, we’ve registered a project on google code. Google provides free code development services for open source projects, including code version control, issue tracking and release management. So far, no code published yet.

As a first step towards developing our platform, we need to collaboratively develop a set of specification documents. We opted to use a wiki for that purpose. As a prototype, we’re using the wiki provided by google code. This doesn’t seem to provide the functionality we need, such as email notification, WYSWYG editing, hierarchical editing, etc. Once we set up our own system, we’ll use it instead.

We’ve set up a group space on the Emerge site. However, given our other tools – its function is mainly as a signpost directing interested visitors to our site. This situation does highlight the tension between a centralized hub, like Emerge, and specific project / team / individual sites.

We’ve presented the project in a few occasions, and produced slidesets for them. In order to share these, we’ve created a group space on SlideShare. Apart from the option of viewing, downloading and commenting on the slides, SlideShare allows us to easily embed them in blog posts.

We have started experimenting with google apps. This should give us project email addresses, a more convenient shared document space, and a few other services. However, the setup offered by the standard edition doesn’t yet give us answers to any clear and immediate needs. For the time being, we’re putting this on the back burner.

bibsonomy is nice because it supports sharing of both web bookmarks and academic references. del.icio.us, on the other hand, has a much wider user base (including in our team). Instead of choosing between them, we use both – with the same tag for marking the project (patternlanguagenetwork). RSS makes it all so easy…