WaterWiki Toolkit: Technical

From WaterWiki.net

Jump to: navigation, search
edit  ·  Toolkit WaterWiki 2.0 - The project
WaterWiki in UN-Water Context | Technical development issues | Managing WaterWiki 2.0 | WaterWiki - Wanted Content
WaterWiki-presentation Nairobi web4dev-conf Nov07 (Web4Dev Nairobi 2007 | Web2forDevConference findings) | The Contribution of a Wiki to the Development of a Community of Practice: A Case Study - Anna Maron Aug07 (Findings from study on WaterWiki by Anna)
Further resources: Knowledge Management Toolkit
WaterWiki 1.0 (Careful: Archived, non-updated version)
WaterWiki 1.0 Toolkit (FAQ | KM | Substantive | Technical | Process Step-by-Step) | "Outstanding Dev Issues" on WaterWiki 1.0 | Draft concept for the way ahead | New architecture (draft) for WaterWiki

Contents

Where the Technical Part of the Process Started

Within the over-all pilot cycle shown in the "Process Step by Step", where did the identification of technical expertise being needed come in and how was it secured?

After the initial phase of "knowledge gathering", there was a need to share the results. It was decided that a Wiki would be a useful format -- the knowledge gathering process could continue beyond the pilot. And a Wiki could support broader goals beyond the intention of the original pilot.

The IT staff at UNDP ECIS did not have the time capacity to support this project, so outside technical expertise was needed. Anna and I had been privately discussing the pilot, and I was interested in its challenges and goals. Fortunately, I was available, and was brought on board.

Step by Step Overview of the Technical Back-End Support

For each main phase of start-up, structure, test-use, revision, confirmation and consolidation, what were the MAIN steps you took to inform the decisions that were taken in relation to the pilot project?

The first step was to identify a Wiki software package to use. There are many, with differing features and requirements. The quality of the code differs widely.

At the same time, we had to discuss what technical resources were available from IT .. in terms of scripting languages, web server access, databases.

MediaWiki was not the first choice, but limitations imposed by the IT resources made it so. The first choice required Perl, but only PHP is installed and supported here. In retrospect, I am glad that we had to go with MediaWiki. As the code behind Wikipedia, it has a high profile, is installed widely and has a huge user base, and it is insured to have an active developer community going forward. It is definitely stable. It has a large number of features. On the downside, there are many features idiosyncratic to Wikipedia. And the code organization feels similar to a Wiki ;).

Once the decision to go with MediaWiki was made, access to the web server and mysql was arranged with IT. The software was installed and minor customizations made within a day. Research began into the code itself, and resources in the development community.

We decided to focus on one country during the development process. The structure of pages, technical requirements, problems with MediaWiki were revealed, and solutions were deployed. Feedback on features, deployment, etc was immediate by Instant Messaging.

For detailed information on the technical modifications, look through Technical Details

For example, the templating system went through a couple stages of development. These templates are styled and enable structured data creation. I installed a MediaWiki "Hack" that prompted users to select a template when creating a new page. These templates required HTML tables. We tried to highlight the sections that were editable, but it still came off quite intimidating. This was identified as the biggest usage problem for the site. After some thinking, I devised a method of formatting and structuring the text using only the familiar Sections wiki text. This required deep modification of the code, but the result was a vast improvement in usability.

Experience Base and Technical Capacity Requirements

What main experience do you have that prepared you for the provision of technical support on this pilot? What transferable experiences would be comparable?

Over 10 years working experience with programming, developing, and using web technologies. Also have a focus in web mapping.

What capacity level and specific skills are required for replicating the project?

This project involved more than simply installing software; new requirements quickly emerged and morphed, and much customization to the codebase was necessary.

You should be comfortable developing with web scripting languages (php or perl), apache and mysql dbs (your basic LAMP platform), and able to quickly get familiar and involved with a new codebase and development community (here MediaWiki).

Embrace Open Source -- the budget will thank you.

The mapping portion of the site required knowledge of web mapping data sources and software. Here we used worldKit

For Wikis, it's very important to understand the technology from a user perspective. What may seem obvious to a techie, is not to an expert on Water Governance. Wiki technology still has many rough edges, and requires some care before introduction to a wider non-techie audience. It is very important to receive user feedback, and act on it.

What type of technical support and what technical support resources are required for creating a Wiki?

We needed access to a server with the LAMP stack.

Lessons Learned From the Water Wiki Pilot

What are some other crucial factors for realizing a project like this?

Support and interest within the organization. A champion for the concept and technology. Because even though much of the project seems technical, the real challenge is cultural. Wikis (and other technologies like Weblogs) are a subversion of traditional hierarchal structures and working practices.

The goal of a Wiki needs to be very focused. Working directly with the needs of the Water Governance sub practice, and priming the Wiki with the results of the initial information gathering phase, was crucial to making the Wiki truly useful. It is not enough to install a Wiki and invite a large organization to start using it.

How much time is required?

This project required two months working time.

How is that time divided up in terms of programming, training, etc.? (Link this if possible directly to a job description, or terms of reference, or task assignment, for both the lead intern, the KM function (Anna) and the technical support / programming intern (Mikel). Anyone considering replication would have to consider two interns as a team, probably, so might as well include in the Toolkit the ToRs or job descriptions ...

Long term technical support of the wiki is crucial. Initial set up can be done quickly, as here, as a full time focus. But technical requirements and support will continue to trickle in as the Wiki is used. This will require intermittent attention over a period of 3-6 months, perhaps more.

Recommendations for Those Considering Use of a Wiki

What could have made the process work smoother?

The WaterWiki modifications to MediaWiki represent a significant step in adapting Wiki technology to working practices in the UNDP. If this software is sufficiently packaged, or merged with the main code of MediaWiki, future deployments will be much easier.

The other biggest improvement that could be made to the Wiki is WYSIWYG (What you see is what you get) editing. Wiki text can be intimidating at first.

What advice do you have for the technical support colleagues who may end up on similar pilots, tasked to do the same thing you did on this one

Pay close attention to the needs of users. Wiki has some rough, geeky edges, and they need special attention and adaptation to user needs. So, in a sense, you must be dedicated to not just fulfilling your technical obligations, but to the overall goals of the project and the good it will do for the UNDP.

Communities of Practice Making the Most of Technology for Purposes of Knowledge Management

Based on your technical expertise, and the summer's orientation to knowledge management as a priority along with substantive areas, do you think that the approach of using wikis is the way for the organization to go? If yes, why, again from a technical point of view? What else do you suggest the agency consider as part of consolidating KM and using the best of what technology can offer to support that process?

Absolutely. The UNDP has a variety of technical tools already at its disposable -- email, intranets, databases. All of these have a place, but are misapplied to the essential problem -- how does a group of geographically, and even temporally, seperated people work together?. How do you collaborate with a colleague half way around the world as easily as someone in the next office? How do you access the informal knowledge of someone who left the UNDP three years ago? That is the problem Wiki solves.

Highly structured systems, "knowledge databases", put up high barriers to use, and are inflexible to the emerging needs of its users. You can't plan for every usage scenario, and contributors are discouraged by over formalized online environments. Intranets suffer from centralized control.

Much informal discussion happens over email. However, the discussion is transitory. It may be archived, but accessing that knowledge requires wading through a lot of discussion.

A common usage pattern I've witnessed, is a group working on a common document by emailing around a Word attachment. This results in confusion over which version of the document is most current, and tracking changes becomes a mess. This is what Wikis excel at.


Wikis fits the niche between intranets and email. They are open, free form, but with our improvements, also support some structure. They empower users of websites into contributors. At a higher level, Wikis make decisions about information architecture tractable for non-programmers.


Besides Wikis, my biggest suggestion for improving KM is Weblogs and Syndication. Weblogging is a different mode of communication, similarly embracing open publishing, but with a more personal, progressional focus. Introducing Weblogs in a similar pilot would be very valuable.

Key Implications of Pilot Experience for Other Technical Support People

What is it important for other technical support people to know about your experience with this pilot, and the implications for their experience, if they are asked to take on a similar job? Any advice?

Again, to really make this kind of project work, you need to get the religion. Drink the Wiki kool aid. Really believe that the right software can make an organization work more efficiently, and ultimately help people and improve the world.

Contact

Mikel Maron (mikel_maron at yahoo.com) Weblog

1527 Rating: 2.2/5 (37 votes cast)