The Pattern Language Network

Taming web2.0 in Higher Education

Archive for the ‘internal collaboration’ Category

tools we use to manage our work, develop shared plans and documents, etc.

Cloudworks, pattern aggregators, and some news from the Planet platform

Posted by yishaym on September 29, 2008

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.

Posted in case studies, code, internal collaboration, patterns, tools | Tagged: , , , , | Leave a Comment »

project communications platform: current state and future plans

Posted by yishaym on February 29, 2008

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.

Web site and blog

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.
  • Contact us: email addresses for managerial, administrative, and web issues.

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.

Shared documents and mailing lists (google groups)

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.
  • users: this will be used by the users participating in case studies.

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.

Developer wiki

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.

Emerge ELGG group

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.

SlideShare space

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.

google apps

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.

Shared references: bibsonomy and

bibsonomy is nice because it supports sharing of both web bookmarks and academic references., 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…

Posted in case studies, internal collaboration, reporting, tools | Leave a Comment »

User engagement in pattern elicitation

Posted by Janet Finlay on February 27, 2008

A critical part of the Planet project is user engagement – identifying and writing patterns must be a community activity for it to have relevance and application to that community. Patterns need to be drawn from that community’s practice and address the problems recognised as recurring regularly in that community. In the initial bid we identified Web 2.0 for learning as our core community and highlighted some Emerge and non-Emerge projects who had already agreed to work with us. Since then we have also had expressions of interest from the Second Life community so we may extend our interpretation of Web 2.0 to include virtual worlds!

Our user engagement will take the form of pattern elicitation workshops, both fact to face and online, and engagement through our Planet platform in developing, reviewing and revising the patterns. The exact schedule for workshops is still being finalised but we will be working with different user groups in phases, recognising that the new projects in particular will need time to establish practices and identify issues that they wish to share. So we will be starting with two established user groups outside of Emerge. CETL ALiC is a collaborative Centre of Excellence in Teaching and Learning focusing on Active Learning in Computing. The project is currently 3 years into a 5 year project so has identified a lot of good practice that it wants to disseminate to the rest of the HE community. Becoming a Webhead (BaW) is an annual six ­week induction programme that allows participants to join the “mother­community” Webheads in Action. Cristina Costa is our liaison with this community, to extract the good practice from their archives into patterns to be shared more widely.

Working with these two groups, using the process already devised through the Learning Patterns project, we will begin identifying patterns and refining our elicitation approach. Later, in May when our initial web platform will be released, we will be inviting other Emerge teams to work with us also.

Posted in internal collaboration, user group | 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 »