Case Story: Developing the Planet Platform

Summary
Group / workshop	Planet team	Status	seed
Project details...	The Pattern Language Network (Planet) project is/was a collaboration between Leeds Metropolitan University, Coventry University, Glasgow Caledonian University, Kings College London and London Knowledge Lab. It is/was funded by JISC under the Users and Innovation Programme. For more information see http://patternlanguagenetwork.org

Situation

What was the setting in which this case study occurred?

The JISC Users & Innovation funded Planet project needed a platform to support its activities. The project was a consortium of 5 UK universities, and engaged a user group of over 100 workshop participants from the UK, Europe and Singapore.
The project has a public-facing site based on a wordpress blog, as well as a community-facing presence on the Emerge site. The project's main mode of operation was a continuous engagement with groups of practitioners through a series of collaborative reflection workshops. The purpose of the platform discussed here was to support this process, and provide various project administration facilities.

Task

What was the problem to be solved, or the intended effect?

The London Knowledge Lab (LKL) was assigned the role of developing and hosting a web-based system for collaborative authoring of case studies, design patterns, scenarios and domain maps. The project plan called for a system which would support basic functionalities from day 1, and would evolve in tandem with Planet's methodology. To achieve this, we defined a phased approach whereby:

1. LKL would deploy an initial release of the Planet Platform based an adaptation of the Learning Patterns project platform to meet immediate requirements collected from Planet team members.
2. Planet team members would seed this system with content, and present it to core user group for feedback.
3. LKL would iteratively enhancement and extend the Planet system based on user feedback, allowing others to engage in an open source process.
4. Coventry would investigate innovative techniques that improve the system’s usability (e.g. visualisation) through student development project work.
5. LKL and Coventry would document the system for users and future developers

The core functionality of the system was to support:

• Index pages of case studies, patterns, scenarios and domain maps
• Template-based on-line editors for case studies, patterns, scenarios and domain maps
• Discussion mechanism for case studies, patterns, scenarios and domain maps

The system was required to support the following data formats for interoperability:

Name of standard or specification	Version	Notes
PLML	2.0	Pattern Language Markup Language
XML 1.1 , XSLT 1.0, CSS 2.1	Various	Document/web standards
REST	n/a	Web services
W3C WAI WCAG	2.0	Accessibility
PDF	n/a	Documentation

Actions

What was done to fulfil the task?

Methodology

The Planet software development methodology was based on the User and Innovation Development Model. This involves an iterative process with three stages:

1. user requirements capture and participatory design of ideas
2. implementation of tools
3. testing, deployment and evaluation of tools in context

The Planet platform was designed to support the project's overall methodology for engaging groups of practitioners in a collaborative endeavour of developing a pattern language. This methodology originated in the Learning Pattern project and hence it was decided to take the software system developed by that project as a starting point.

The overall Planet project methodology covers three related domains of activity:

1. The manner by which the pattern language is developed and used.
2. The manner by which the software system to support (1) is developed.
3. The manner by which (1) and (2) are evaluated.

All three are open, collaborative, distributed, participatory, user-centred, iterative and integrated.

• Open: All aspects of the project work are transparent and subject to public scrutiny. We welcome others to benefit not just from the fruit of our work, but also from observing how these came to be. The only exceptions to this principle are where there may be legal limitations, or a compromise of privacy.
• Collaborative: All aspects of the project assume a joint effort of all members. While is is natural for members to focus their effort in their domain of expertise, the design of tools and procedures must assume that more than one, and potentially all, would contribute to any goal.
• Distributed: Contributors are spread across several physical locations.
• Participatory: Users have the opportunity to contribute as partners.
• User-centred: The needs of users, as defined by them, are the driving force behind all choices.
• Iterative: The project progresses by numerous tight cycles of specification, design, development, deployment and evaluation.
• Integrated: All aspects of the project are interlinked.

Combining the project's starting point and the interleaved overall methodology defined the parameters for adapting the User and Innovation Development Model.

Implementation

The development of the software platform was driven by the pattern identification process and informed by the Kaleidoscope project. The interdependence of the platform and the pattern identification was reflected in the internal data structures used to store information provided by users. A set of functional, interface and design specifications (http://patternlanguagenetwork.myxwiki.org/xwiki/bin/view/Specs/ ) was created and used to guide the software development process. Building the software followed a highly agile approach and again reflected the iterative process of build, test, evaluate (through the user group workshops) and modify. Issues identified by the user groups were reviewed and used to enhance the platform. From the beginning the software platform was used to support the submission of case studies and also to capture emerging patterns. Pioneers using this approach did experience some difficulty both in using the platform and also in providing case studies of an appropriate level of granularity; some case studies were focused on problems associated with a whole project whereas more helpful case studies identified problems of much smaller granularity e.g. intra group communications. The provision of more detailed instructions on using the platform improved problems identified with using the platform. These instructions were provided as a series of slidesets on slideshare.net

The Learning Patterns code was built on top of the Alpha Complex CMS developed by the Kaleidoscope network of excellence. At the time of Planet's inception, this CMS was planned to be released as an open source product with continued support. However, soon after the project's initiation it emerged that neither the release date of the Alpha Complex CMS nor its support plan where reliable. This was identified as a major risk, and the implementation plan was reassessed in order to mitigate it. It was decided to evaluate alternative platforms. Eventually XWiki was identified as a suitable candidate for the following reasons:

• XWiki is an open-source highly-configurable wiki platform, written in Java.
• It is backed by a commercial body (XWiki.com) as well as a vibrant user and developer community.
• It supports many of the features we needed out of the box, or through minimal scripting.

Shift away from the original plan of using the Learning Patterns codebase also highlighted the volatility of academic hosting. Academic institutions tend to be somewhat slow to adapt to changes in technological requirements. It was assessed that approving the installation of an XWiki server and exposing it through the firewall might pose a risk in terms of on-time delivery of the required functionality. In order to pre-empt this risk, we chose to host the project platform during its development on the free MYXwiki server farm.

Using the MYXwiki environment released us from institutional constraints and system maintenance, but it did raise issues of stability and control, as discussed below. A laptop was used for local test & development, enabling us to respond to issues as they emerged even during on-site workshops.

In order to support an streamlined, effective and quality controlled development process, a project development space was set up on google code. This space provides issue tracking, version control, release management and a development wiki. We opted not to use the wiki function, but rather host the system specifications on the system itself. Version control and release management were less of an issue during development: the code we developed was versioned on the system itself, and since we did not entertain external installations, a periodic local backup was satisfactory. As we moved towards the end of the project, and in view of sustainability of the outcomes, we contacted XWiki.com for stable hosting, and deposited a version of the code along with an installable product on google code.

By far, the most useful facility on google code was the issue tracker. This was used to manage and coordinate all coding practice. It afforded an efficient, effective and transparent development process. For the convenience of non-technical users, the issue tracker was embedded in a local page on the system.

Complex requirements and enhancements where discussed with the project team at face-to-face and online meetings, as well as via the team mailing list.

Based on the initial requirements, as well as the needs as they emerged from the user workshops, we developed content areas for Cases, Design Patterns and Scenarios Domain Maps and Trails, which played a significant role in the Learning Patterns methodology, did not resonant with the Planet workshop approach, and where therefore left underdeveloped (although basic functionality exists).

In the course of the project we recognised the need to provide thematic groups with a workspace of their own, and thus a Groups section was created. The actual group space functionality was provided using the base XWiki features.

As the project progressed and content accumulated, several features where identified as high-priority requirements. It was decided to allocate targeted effort to supporting these. Most notably, these included the API, the tagging mechanism and Candidate / Pattern differentiation, described in the Outputs section below.

Results

What happened? Was is a success? What contributed to the outcomes?

Outputs

The actual deliverables from the project include:

1. A collaborative software platform for capturing and storing case studies, patterns and scenarios in various levels of refinement
2. A software application program interface (API) for the patterns stored within the software platform
3. Entry into the JISC Innovation base for the Planet project identifying the types of services needed to support patterns

Collaborative Authoring System

The Planet system supports the creation and collaborative editing of three content types: Case Studies, Design Patterns and Scenarios. Each one of these has a dedicated space in the system, where all items of this type are displayed in a searchable and sortable index. The index page is also the entry point for creating new items. Upon creation authors are presented with a form-based editor, which scaffolds them through the editing process. The can save and return to this editor as many times as needed. The owner of an item can also specify additional contributors who will be granted editorial rights. Other users can comment on the item but not edit it.
The form of the different types was refined through the iterative participatory process. The Case type is intended for contributors to describe the details of a problem they personally encountered and resolved. The Case template offers a simple structure which guides authors but leave ample room for a personal narrative. The template prompts authors to specify the situation in which the case is embedded, the task or problem to be solved, the actions taken, their results and finally any reflections.
Patterns abstract the salient features of context and problem across cases, and the common core of a possible solution. The template is much more detailed, prompting authors to specify the context, problem and solution along with supporting evidence and related patterns. Special attention has been devoted to the visual aspects of pattern: the pattern template has fields for icon, illustration, diagram and a text editor for a defining a sequence diagram.
Scenarios are similar to cases, except that they describe problems which need to be solved and prompt authors to explore which patterns could be applied in their resolution.
The tutorials on slideshare provided user with vital assistance in using the system. More immediate help was provided in the form of tooltips.
Tagging is enabled for cases, patterns and scenarios. Authenticated users can apply tags to any item in these classes, and can then search, filter or navigate using these tags.
As the project methodology matured we noticed that proto-patterns are typically recorded in the course of workshop discussion, case analysis or development of other patterns. These proto-patterns need to go through a lengthily editorial process in order to qualify as valid design patterns. To reflect this life-cycle, it was decided to initially mark contributions as "pattern candidates" and define a process for promoting candidates to "pattern" status. This procedure would be supported by system functionality.

API

The Planet platform offers two APIs for accessing Cases, Patterns, and Scenarios. These APIs were inspired by the discussions with the pattern exchange forum, a group of developers of various pattern tools and repositories across Europe. The initial implementation is being tested by LDSE and CloudWorks, among others. Both APIs are based on REST model with only GET method enabled at this stage. In effect this means that client applications can read the content in our system, but cannot edit, delete or add new items. A generic API allows programmatic navigation through the class and object structure. Clients can retrieve the list of classes (datatypes), the structure of each class, and then list objects from any class or ask for specific fields of specific objects. A simple API allows clients to retrieve Cases or Patterns, specifying search criteria and output format. Output formats include PLML, XML, RSS and CSV.

Code and executable release

All code developed by the project is available for browsing or sub-version access under an open source licence from: http://code.google.com/p/patternlanguagenetwork/source/checkout The installable package is available for download from: http://code.google.com/p/patternlanguagenetwork/downloads/list This package is an XAR file which can be imported directly into any XWiki installation. XWiki can be downloaded from: http://www.xwiki.org/xwiki/bin/view/Main/Download Note that the installable package includes all the source files as well.

Obstacles and their resolution

Hosting

The LKL had commited to hosting the Planet platform, and indeed had put forward the necessary hardware. However, a combination of circumstantial and institutional constraints led to a situation where it was impossible to expose the service to the web within a reasonable time frame. A quick investigation confirmed that this is a prevalent condition in UK academia, and most innovative projects choose to resolve it by renting external server space. The technical specification for our system would have implied that external hosting would be very expensive: most low-cost providers do not support Java and other application services. The project team approached the XWiki team and was granted free hosting on the MyXWiki server farm. This solution was obviously cost and resource effective: not only was hosting free, but it also released the Planet team from server maintenance tasks. However, it came at a price of reduced control and reliability. While the service was generally robust, it came with no guarantees, and occasionally the server would be down at the least convenient moment. Platform software upgrades were performed per XWiki's testing schedule, and on some occasions caused unexpected incompatibilities and feature degradations. Limited access rights on the MyXWiki server meant that some required Planet features were hard or impossible to implement. The free service contract came with no support obligation. XWiki staff and community were very helpful, but acted out of good will and within the limits imposed by their commercial commitments.
During the active life of the project, the advantages of having a low-cost, powerful and flexible platform outweighed the price of working "in the wild". As the project draws to a close, we need to stabilise the system and ensure that it will remain stable without our constant monitoring. To that end, we have agreed on a paid hosting and support plan with XWiki.com, the commercial company which backs xwiki.org.

Resourcing

As the Planet project unfolded, we identified a strong need in the wider community, and where invited to conduct more and more workshops, engaging with a growing circle of practitioners. This demand from the community called for reallocation of resources, as the workshop process is highly labour-intensive. Some of these resources where funded by auxiliary sources, but inevitably some degree of internal adjustment was needed. We contracted developers for short-period engagements and shifted some development work between partners. We continuously reassessed priorities and focused on the critical features highlighted by actual user needs, even when those deviated from the original specifications. The project adopted a user-centred, agile development strategy, which was much more reactive and responsive to user needs but abandoned the rigorous structure of formal specifications. Any follow-up project would need to set aside a planning period for updating specifications and insuring cross-cutting application coherence.
The software developed in tandem with the Planet methodology and was subject to its needs. This induced a sequentiality in feature specification and implementation: the project methodology was based on a three-workshop model, with one or two months gap between workshops. This meant that the features required by the last workshop were only tested close to the project end, and any adjustments to the methodology called for functionality refinements which are beyond the scope of the project.

Lessons Learned

What did you learn from the experience?

The development strategy chosen by the project appeared bumpy at times, but seemed to have paid off in terms of supporting a vibrant professional activity engaged in an intensive process of collaborative reflection. Nevertheless, the state of the software - as well as the technology is such that they do not yet afford independent, "off the shelf" engagement of groups and individuals. The main reason for this was that the project team remained commited to conducting workshops and dissemination events to the very last days of the project, constantly tweaking the methodology and the technology. The team in determined to complete the packaging and documentation of both the methodology and the tools over the next few months.
The growing acknowledgement of the viability and effectiveness of the Planet methodology, along with the supporting technology, strongly suggest a need for follow-up funding to develop both further. We are actively perusing UK and EU opportunities.
IT departments in Academic institutions see their first priority in supporting informational and learning support systems, and are ill-equiped for responding to the needs of experimental web2.0 projects. This leads to reliance on external hosting services, a practice fraught with inefficiencies. We identify a need for a centralised research and development resource farm, which would supply projects with development process tools (source control, document management, release management, etc.) along with high-specification application hosting.

Licensing

This work is licenced under a Creative Commons Licence.