calling all wiki design gnomes

16 Feb 2011 - 2:02pm
3 years ago
8 replies
1151 reads
Diana Wynne
2008

Hi all,

I'm cleaning up a 5-year-old wiki for a client and have been running into the usual tensions between imposing order (through better design and IA) and maintainability.

It's an internal resource for an IT group, and has been a very successful repository for specs, meeting notes, and requirements docs, despite how primitive the MediaWiki platform is. 

Has anyone worked on a project like this recently? I've done similar work on intranets and internal apps for corporate clients, but this is significantly more collaborative and non-hierarchical. 

The design and content activities themselves are clear. Happily there's a lot of low-hanging fruit, and my charter is broad.

But given that they have a wiki they actually use, I'm not sure how ambitious to be, since I won't be there to maintain it.

Thoughts and ideas welcome, here or off list.

Thanks!

Diana

diana at chestnutdrive dot com

Comments

16 Feb 2011 - 10:50pm
Davin Granroth
2009

Hi Diana, we're actually in the early phases of working out an organization scheme for our product dev team's internal wiki too. This wiki has been growing wild for about 3 years, and it is a tangled mess. When people go to add an article, usually they simply can't figure out where in the wiki it should go. Clearly this is a bad sign.

The question of maintenance is also very much in our minds, so I can share at least a few thoughts.

Wiki Gnome: we won't consider the project successful unless we have someone who has taken the role of wiki gnome. Unless there is someone who actually cares to continue tending the content, transplanting misplaced articles to appropriate places, etc., then our efforts will be wasted within perhaps half a year.

Clear separation of content categories: Given a list of main categories, we pick up various articles that exist in the wiki now or topics that we hear should exist, and toss them at the categories to see where they land. We want to see categories that people don't have to think too hard about where these various articles should go. Until we get those categories worked out pretty well in that way, we know we'll have a long-term maintenance problem. Also, in this process we end up dialoging rationale to define each category. Some of these definitions may end up on the main page for each category, so as to embed those concepts that differentiate categories into the wiki itself. Though, hopefully, the category labels will capture these ideas.

It looks like we'll have a "knowledgbase" category: We found a lot of articles in the wiki now that could be lumped into the grouping of knowledge articles. The topics themselves vary pretty widely, so this is going to be a broad category. But by having this knowledgebase category, we end up protecting the clarity of other categories, such as projects, products, methodology and procedures, team resources, and business rules.

Some more defined page templates: In general, the wiki pages will be generically structured. However, there may be some types of wiki pages for which we'll want more structure. For instance, any wiki page that describes a product may require references to business rulesets that apply to that product, locations of bug tracking for the project, and a product vision that can help guide future release planning for upcoming features for the product. Creating templates for some specific types of repeated content can actually help maintenance work be more reliable in the long run.

We haven't finished working out the questions yet, and we also haven't looked much deeper to sub-level categories. Though too much definition on sub-level categories risks overcomplicating what is really a collaborative space. Hopefully over time we'll be able to adapt the organization within categories as needed (again, wiki gnome is important). Perhaps this at least will spur some thoughts for you.

Best wishes.

-drg

16 Feb 2011 - 11:41pm
Diana Wynne
2008

Davin, great stuff and very relevant.

I hadn't really considered the issue of tags versus hierarchical categories until now. One of the challenges with a wiki is that aside from namespaces, pages don't really live anywhere.

In this case, I'm the wiki gnome, a bit of a challenge as a consultant thousands of miles from headquarters. I'll probably do the first pass at categorizing the thousands of pages of content, possibly in a dev environment. No one uses categories at all today, nor are there any well-structured index pages.

We've been discussing setting policies for archiving (possibly moving all pages unedited for 2+ years to a different namespace, or appending ARCH<year> to their names) and looking for tools typically found in a CMS that would notify content authors prior to archiving to review/update content. While it seems a little scary to rename and move pages wholesale, redirects ensure the links would still work, and they'd still appear in search results. We'll see what flies.

I have been itemizing major content types, with similar thoughts about using templates both for appearance and as scaffolding. Meeting notes should look/feel different from a project microsite or a feature spec. We're also collecting examples to showcase. The best designed Mediawiki site I've found so far is Familysearch.org, a Mormon geneaology wiki.

It does seem like wiki docs have a known lifecycle (single author->intensive editing and collaboration->lots of readers, only a few changes->obsolescence) that should be acknowledged in the design planning.

Thanks much for the conversation.

And as I said to my client today, congratulations on getting this far. From what I've seen, most wikis don't ever make it to the next generation, where there's a wealth of (unorganized, hard to discover) content and active users. 

17 Feb 2011 - 2:47am
Frank Ralf
2010

Hi Diana,

We've been using MediaWiki for our intranet for just a year now but as the content is growing, structure and usability is becoming more important. Here are my 2 cents:

  • I would highly recommend using the DPL extension which really is the Swiss Army Knive for MediaWiki.
  • For an even more structured approach you should consider using Semantic MediaWiki 
  • The Create Article extension helps creating articles in a userfriendly way with a pre-defined structure.
  • And new versions of MediaWiki come with jQuery support which will make for a lot of possible usability improvements.

hth

Frank

 

 

 

17 Feb 2011 - 11:32am
Diana Wynne
2008

Thanks Frank,

I will definitely check those out. We were looking at CKeditor yesterday, a WYSIWYG editor with support for tables, spellchecking, etc.

JQuery would solve a lot of things. I've been debating how much we need to roll our own solutions.

Diana 

18 Feb 2011 - 10:18am
Frank Ralf
2010

You should keep in mind that WYSIWYG editors sometimes break wiki text, e.g. transcluded templates, one of the most powerful features of MediaWiki.

Frank

 

17 Feb 2011 - 11:38am
Diana Wynne
2008

BTW has anyone used an extension to add ranking to wiki pages?

I'd like users to be able to mark pages as recommended, not recommended, and out of date. And then show popular popular back to users, and flag not recommended and out of date for content owners. 

18 Feb 2011 - 10:30am
Frank Ralf
2010

Hi Diana,

you might have a look at the following extensions (which I haven't tested myself, though):

  • http://www.mediawiki.org/wiki/Extension:FlaggedRevs
  • http://www.mediawiki.org/wiki/Extension:AjaxRatingScript

Frank

 

18 Feb 2011 - 11:12am
Diana Wynne
2008

Thanks Frank. I'll report back.

Syndicate content Get the feed