The Pattern Language Network

Taming web2.0 in Higher Education

Posts Tagged ‘wiki’

The Story of the Planet Platform

Posted by yishaym on March 31, 2009

True to the dogfood principle, we now have a case study on the development of the Planet platform. An amazing tale on international mystery and intrigue. Well, maybe not – but if you’re working in a UK HE institure and thinking of launching an ambitious web2.0 project, you might find our experience informative.

Or, if you have been involved in a similar project, we would be curious to know: does this resonate with your experiece?

Its all there (in brief): the original plan, what went smoothly, what went wrong, and where we are at the end of the day. Enjoy!


Posted in about us, announcements, case studies, code, notes from the field, reporting | Tagged: , , , , , , , , , , , , | Leave a Comment »

The Planet Video

Posted by Janet Finlay on February 25, 2009

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!

Vodpod videos no longer available.

more about "The Planet Video", posted with vodpod

Posted in about us, project, reporting | Tagged: , , , , , , , , | Leave a Comment »

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

Posted by yishaym on April 21, 2008

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


Posted in code, musings, related projects | Tagged: , , , , , , , , | 1 Comment »

server pains

Posted by yishaym on February 29, 2008

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.

Posted in case studies, tools | Tagged: , , , , | Leave a Comment »

Something happening on the Wiki

Posted by yishaym on January 28, 2008

The PLaNet system will be based on an open source Java wiki. We’re not sure yet which (we have three candidates). It would make sense to use the system to conduct its own development discussion – identify requierments, agree on specifications, etc. Of course, there’s a chicken & egg issue here.

So to kick-start the discussion, we’ll use the googlecode wiki. That should see us through to the first prototype, and then we’ll migrate.

There are several pages there, in a very raw state, waiting for your comments. Unfortunatly, googlecode does not support page change notifications (yes, that is a requirement for our system). So if you leave a comment or edit a page, please send an email to the mailing list (or leave a comment here, saying that you’ve left a comment there).

Right now, three pages are waiting for your insights:

    WikiHome: General introduction to the code site.
    EnvironmentSpec: Overview of our deployment and development environment.
    MethodologySpec: Overview of our methodolgies for developing the language, the tools to support it, and the instruments to evaluate both.

Posted in code | Tagged: , , , , , | Leave a Comment »

project administration documents

Posted by yishaym on January 18, 2008

I’m a bit baffled about this one, and I suspect others are facing similar problems. In fact, apart from this being a concrete problem we’re confronting, there may be a pattern in here.

We need to agree on a set of document which define the administrative structure of the project. These include statatory documents, such as the consortium agreement, project plan, workpackage details, roadmap, etc. These may be frozen at some point. Other documents will evelove continously over the project life time.

There’s two related issues that I want to consider:

  • Which form / format should these documents use?
  • How do we manage them.

So far we’ve been using word documents, stored on the google group file area. I see several potential difficulties with this mechanism:

  1. It doesn’t scale as a file manager. there’s no support for folders, or any other scheme for managing large number of files.
  2. It doesn’t support collaborative editing, commenting and versioning. Let’s say I want to suggest an ammendment to the plan. how do we facilitate this?
  3. Some forms of administrative knowledge ae better represented as mindmaps, gantt charts, spreadsheets, etc. How do we choose formats?

There are several alternatives we can consider, but none seem ideal.

Option 1: version control

We have a subversion repository on the google code site. We can host all documens there.


  • consistent. one place for all outputs.
  • easy to browse.
  • supports versioning (obviously).
  • extreme transparency.


  • everyone needs to master subversion (not too hard to do).
  • extreme transparency.

Option 2: wiki


  • easy to use.
  • supports versioning.
  • managed transparency.


  • easy to mess up.
  • limited editing capacity.
  • potential problem with exporting to deliverable format (depends on particular clone).

Option 3: google docs


  • easy to use.
  • supports versioning.
  • managed transparency.
  • familliar format.


  • limited editing capacity.

Option 4: document management system


  • does all we want.


  • costs money.
  • requires maintanence.

Posted in action items, internal collaboration | Tagged: , , , , | Leave a Comment »