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.

project communications platform: current state and future plans

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.

Calendar

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).

Code

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 del.icio.us

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…

Project Management Plan Update

The Planet project plan and the related JISC web page have been submitted to JISC as required. The plan was submitted in early February and the Web page about one week later. These were slightly later than anticipated however this did allow the development of an excellent evaluation plan by Isobel and Steve and this was incorporated into the overall project plan.

User engagement in pattern elicitation

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.

Planet @ LKL Knowledge Seminar, 30 Jan 2008

these are the slides I used at the talk I gave at the knowlege lab. I was hoping to have the video & audio tracks to attach, but there was a technical glitch, and I decided not to wait for the slight chance that something will be salvaged.

Overall, response was very good. I think that for the first time in my life I managed to come up with an explanation of “what is a pattern and what is a pattern language” that appealed to the uninitiated.

Quite a few people commented on the visual aspects of patterns and pattern languages, and saw a lot of value in expanding that theme.

I got a very important warning: avoid the content-neutral path. Learning is always a learning of something in some context. We should engage with users who are applying the technology to a clear need, rather then exploring it for its own sake.

Demand for patterns platform

I’ve just read the outcomes of Sheila MacNeil’s poll on “In the next year, where should JISC concentrate funding for learning, activities and resources?”. Top of the list was a user friendly tool for creating and sharing learning designs (63% of votes) – which suggests a lot of potential interest and user engagement for the patterns platform that the PLaNET project could tap into. Patterns are not necessarily the same as learning designs, but are closely related to them. See http://wiki.cetis.ac.uk/Educational_Content/polls for details of the poll.