Not presenting at Etech: Wiki Anarchy in the United Nations

Not presenting at Etech: Wiki Anarchy in the United Nations

Around the time proposals for this year’s Etech were due, I had just wrapped up the WaterWiki project at the UNDP, and I put together a quick submission. WaterWiki was a very very satisfying project, and it looks like the concept will soon start replicating through the UN. The etech proposal has been under consideration until just last week, when I got the word it wasn’t in. Ah well. There are some good, still relevant ideas in the original proposal, and the follow up response to the selection committee’s feedback, so here I share.

Original Proposal

The talk covers the first experience with Wiki technology in the UNDP (United Nations Development Programme).

The UNDP is an inter-governmental, not-for-profit organization. It’s highly decentralized, working on the basis of a global network of Country Offices, backstopped by regional service centers and one headquarters (in New York). There are untold amounts of knowledge and experience from project development, implementation, evaluations, etc., most of it stored in places difficult to access geographically and temporally – human brains. As common elsewhere, formalized knowledge management – a declared and explicit goal for the organization over the past couple of years – has not lived up to its potential in freeing individuals within the organization to either contribute to repositories of knowledge, not to access their colleagues worldwide and contribute through informal means.

An anarchic approach might be the answer, yet it needs to be properly designed. Wiki, despite its evident simplicity to geeks, is not a technology (and concept) that’s easy to grasp for laypersons. And in reality, the problem of introducing the benefits of Wiki into an organization is cultural. Practitioners suffer from technology and change fatique, and are already overburdened with procedures and substantive work. We learned many lessons in designing the cultural virus that is WaterWiki, like..

  • Start small and have a champion
  • Wiki text sucks
  • Structure and familiarity is essential for initial momentum
  • templates and adequate simplification of script, Maps, pretty pictures, and nice formatting make it all less scary
  • Grow nice carrots (ie make their job easier), cause the stick
    doesn’t work

Wiki turns information architecture into an anarchic activity.

Putting this tool into the hands of experts is the next challenge for technologists.

Follow Up

Two facets of WaterWiki stand out when thinking about usability and
attention in Wikis: Structure and Visualization.

Wkis are by nature amorphous, unstructured, open, adaptable. That’s
their greatest innovation. But as you say, it requires very active
manual gardening to focus a group of contributors, and often no one
takes that role. Simply getting started from the blank slate of a new
wiki is a challenge for any community.

Wikipedia has been such a success partially because an encyclopedia is
so unstructured, traditionally only an alphabetic list of mostly
standalone articles. It’s a model easily translated into a Wiki, and
provided a lot of initial inertia for Wikipedia.

At the other end of the software spectrum, large knowledge management
solutions attempt to beauracratically embody community processes, and
can end up expensive, barren places.

I think there is a middle ground.

In WaterWiki, we installed & implemented several MediaWiki hacks and
extensions to introduce just enough structure. New wiki pages are
selected from a group of user editable/creatable templates, each
defining a category. They consist of several sections, with pre-chosen
section headings. These pages can be rendered & styled in a variety of
ways. The fundamental unit in the wiki moves from a page to a section,
which are reusable throughout the wiki. For example, each country page
has a News section, which are all gathered into a single page, and RSS
feed.

We don’t have it entirely right, but I think WaterWiki is moving in the right direction. In a sense, it is an attempt to empower wiki users, to take on Information Architecture and even application building. There are many interesting takes on structured wikis — JotSpot, Twiki, WikiData, but still I find them complex and difficult. A strong current in the history of software has been self-obsolence by programmers — how can domain experts build software for themselves without worrying about all the innards and pecularities of computer. Higher level languages, spreadsheets, HyperCard, cgi scriping, Ning .. always balancing the trade off of abstraction and customizability.

Within the MediaWiki development community there are several sketches
and some small projects to introduce structure. But it does touch on
the 800 pound gorilla role of Wikipedia. It’s wide exposure provides
great conceptual leverage when discussing wikis in non-geeky forums.
MediaWiki has an active developer community and is definitely a proven
platform (even if the code would ‘go well with meatballs’). However,
the idea of what a wiki can be is becoming frozen, and idiosyncratic to the Wikipedia experience (does every wiki need ‘Talk’ page and edit
buttons for math formulas?)

WYSIWYG is not a silver bullet for that greatest offense, wikitext. We
really don’t want wikis to start looking like Word documents. Small use of WYSIWYG, along with more use of familiar feeling HTML forms build on simple structures, will make the wiki editing experience less
absolutely terrifying for the novice.

Data Visualization is the other major theme, particularly when thinking about attention. With a few exceptions like weighted lists,
visualization has been tremendously underutilized for comprehension in
every day use; its mostly the result of one time or occassional heavy
analysis. IBMs ‘history flow’ visualization of Wikipedia was
fascinating, but only a single study and possibly too complex for quick comprehension.

Spatial Visualization has become a phenomenon because its so
accessible. Maps are very familiar forms, and the required analysis can be straightforward (this is located here, happened here). The power of spatial visualization has motivated my work from World as a Blog, to worldKit, to OpenStreetmap.

In WaterWiki, the front page features an interactive map of the region. Each country contains mouseover content, from the news sections. These countries are assigned geographic polygons in the wiki, and a GeoRSS feed is produced for display in the map. This simple map has made the wiki much more inviting to new users.

There are many active projects combining wiki like factors in map
building, all with different takes, from Placeopedia to Wikiteer to
OpenStreetMap (which takes it to a whole new level).

Dynamic network visualization could by useful in some wiki situations.
I’m actually not aware of any network visualization applied to wikis,
perhaps due to the conception that they are always quite amorphous. I’m curious to try this out on WaterWiki; its structure could lead to a comprehensible, usable visual site map.

Yes, recently modified lists and alerts are crude tools for Attention.
Perhaps before visualization can be fully engaged, much more thought is needed in the analysis of Wiki activity. Determine the scope of the
change (small edit or major modification), how the change fits in the
history of the article (repeated reversion indicates conflict), who is
making the change (a long standing contributor, or newbie), how long
the edit took, the frequency of edits.There can be more focus paid to
individuals behavior on the wiki, to tailor attention to wiki activity.

On OpenStreetMap, we have just started looking at this issue. A small
step from the Recent Changes list to visualization was introduced last
week, by plotting the locations of edits on a dynamic, updating map —
http://brainoff.com/osm/change/.

Comments
Comments