Would you need a wiki maintainer?

February 28th, 2011

According to the wonderful http://www.wikipatterns.com site, a maintainer is a person assigned or self-assigned to a page, space or section of a wiki who accountably takes responsibility for the quality of some of the content. The role may include that of a:

  • secretary, collecting information from comments and meetings into the wiki
  • refactorer, collapsing redundancy and inserting organization into a wiki
  • solicitor, encouraging input from community members
  • architect, categorizing pages, creating 'project' and 'overview' pages, assigning meanings to labels

While everyone will agree that this is indeed a vary valid wiki pattern, to actually get it off the ground may be an whole different matter. Let's focus on what we saw typically happen in organizations.

Wikis should be self-maintained

For some reason people seem to think that any sort of wiki organization is a bad thing. Maybe it is the myriad of open source solutions that exist for wikis, may be it is their inherently open editing nature, maybe it is just a sign of the times, but every time we try to get someone in the organization responsible for setting up and maintaining a subsection of the wiki, we get a big oh-oh. Like, how can you seriously consider organizing something as beautiful and organic as a wiki? The answer is simple.

Acknowledge wiki (sub) section ownership

Assigning a responsible owner for a section or a subsection of your wiki will help you move things forward. There are just some things that need to get done and you cannot rely at all times that 'someone will fix it'. The bad news is everyone will think everyone else will fix it. We've often advocated to use the wiki for meeting preparation, agenda setup and meeting minutes review and approval.

In our previous blog post on "50 tips to get your wiki up and running" we have shown following tip:

Create reasons to visit your wiki: Add all meeting agendas + minutes + actions on the wiki (this introduces edit cycles)

The bad news is that these things don't come naturally. Even worse, when you leave things to organize themselves, you can be pretty sure all hell will break loose in no time. A simple set of rules for our meetings example:

  • All team meetings are in the wiki.
  • The wiki organizer makes sure that the minutes are available max 24 hours after the meeting.

These can make sure things move forward.

Other examples of wiki pages that merit a responsible:

  • Contact list.
  • Requirements and specifications.
  • Customer info.
  • Knowledge base.
  • Course schedules...
  • ...

In fact most of the 'structured' wiki page content can be attributed a responsible.

How to multiply your knowledge base input by a factor EIGHT

January 7th, 2011

Recently a really exciting answer was posted by Robert Cummings on the mediawiki message board. 

We quote his reply here:

I have to disagree with you given my experience. In one government department where MediaWiki was installed we saw the active user base spike from about 1000 users to about 8000 users within a month of having enabled FCKeditor. FCKeditor definitely has it's warts, but it very closely matches the experience non-technical people have gotten used to while using Word or WordPerfect. Leveraging skills people already have cuts down on training costs and allows them to be productive almost immediately.

Music in our ears. Beautiful, lovely music.

What more proof do we need? This is something we always advocated, the very reason this site, this product, this company is built. When we lower the threshold for creating and editing knowledge bases, more information will be shared faster and better. More knowledge will be available. More people will want to contribute.

Time to end the nerds tyranny

The IT people have always claimed that anybody can learn the simple html syntax. Intelligent people will not be bothered by this small threshold. Moreover, content is more important than appearance. Of course the opposite is true. People are used to MSWord and that is what they would like to use for their work. Please post comments to share your view.

List of wysiwygs

December 1st, 2010

As we specialize in Wysiwyg wiki editing, I sometimes get questions on which wysiwyg editors exist for web editing. I always point people to a great article on smashing magazine.

The article is quite dated but it gives a very accurate overview. I really enjoy reading the comments from time to time. Smashing magazine kept the commenting section open, so recently people still commented on the article. It's so great that the exact same emotions as for WordonWiki are displayed:

  • Geez, this is like reading about the good old days of Assembler&using superZap to modify S/360 registers & memory directly.
  • I love how the comments always fill up with “WYSIWYG is not real coding” arguments in seconds.
  • And what’s wrong with Web 1.0 anyway?
  • People, people, don’t you understand that the future has arrived?
  • anyways real men use vi and nothing else
  • Tons of arrogance and snobbery—boobs all. Wouldn’t hire any of them to update my calendar, let alone design a Website.

And my favorite...

  • This thread is dripping with arrogance from cowardly designers hiding behind their IPs, and it’s pathetic. Grow up. If I needed a web designer and he/she had the same attitude that I’ve seen here, I sure as heck wouldn’t hire that person.

So what if documents actually were better than wikis?

November 24th, 2010

That should stir up some controversy. But that was exactly what we thought when we read the blog post of Alexander Brütt about Wiki vs. Documents. In this blog, the author makes his point about what are exactly the advantages of documents. Let's examine some of Alexander's points:

  • Documents can be send
    Valid point of course. Except from mailing somebody a link to the url (a good habit we have been promoting all along) there is no real way to send somebody a copy of a page. You could of course make a pdf-print and send the resulting pdf. But I agree that is somewhat of a hassle. That at least gives us an idea for a new feature on our wordonwiki product backlog.
  • Documents can be read offline
    Again a valid point, but in this day and age of ubiquitous internet, ipads and smart phones, that becomes less of a problem. What can you do if you are offline anyway. There have been some ideas floating in the office to keep a cached set of documents on a client. That would limit download time when the copy on your local machine is the same as the one you are downloading. We could image some offline mode switch to at least view those cached pages.
  • Documents are a standardized storage medium.
    Strange point. If you would call .doc and .docx standards, there are Microsoft specific to make sure. Who would care about this anyhow. 'Send me the doc' in today's business environment most likely means 'Send me the Word file'.
  • The editor for documents named Word 2010 is the best document editor on this planet
    Oh my God, music in my ears. Yes that is exactly what we have been trying to tell the world. Kudos for Alexander to make this point to beautifully. Kudos to ourselves to make this an advantage of the WordonWiki product :-)
  • Documents can switch their file format as desired. A wiki cannot really do that.
    Yes, true... But why would I want to change the wiki format.

Our view is best summarized by following equation:

the document == the page == its history == its url

In a wiki, the document is synonym for the page. The wiki page has everything contained in it: its history (complete with revert possibilities) and its unique location indicated by the url. The document has all these things separated out. The historical versions of the document are other documents and once you 'send it' it is no longer unique.

Please add comments if you have thoughts about this comparison between documents and pages.

Microsoft addin to save media wiki pages

November 18th, 2010

On this link, you can find a Microsoft addin for Word. It allows you to create page content and then save it using the 'save as' dialog in Mediawiki format.

Nice idea, and somewhat motivating that big all mighty Microsoft sees this as a valuable addition to their product.

How does it work?

  • Step 1:download and install the MSI package
  • Step 2:open MSWord and create some document content. You can use lists, tables and some limited formatting options.
  • Step 3:use the save-as menu option, select 'Other formats' and then select Media wiki.
Save as dialog box with Mediawiki

All very neat and handy, but...

  • You can only use this to create new pages, no way to use it to do page edits. (the mediawiki file is saved as a text file)
  • No fancy stuff like images and graphs can be included. The Mediawiki addin generates [[imagename]] tags for this.
  • Last but not least, it does not work on somewhat more complex documents. I had repeated error messages like the one below until I created and saved a relatively 'simple' file.
MS Word error message on Mediawiki

Best lame excuse of the day not to use the wiki

November 16th, 2010

A developer in the project team where I do consulting had been struggling with some new code. The code was perfect, but the problem was a lack of documentation. Nobody knew how to configure the thing. So precious hours were lost just before the scrum demo later that day.

One would hope the developer's reaction would be to document the found settings in the wiki or installation manual so that the same hours would not be lost again. Instead this guy wrote an email detailing every frustrated step he had to take and mailed it to the support email box of the company.

The developer knew the support email box was automatically converted in todo-items for the system administrator. The system administrator was the most likely person next in line to run into the problem.

When asked about the justification of these bizarre actions, the developer responded: "Well, I keep this email in my sent items folder so the system administrator cannot say I never told him...."

Tip10: Beware the derailers.

October 6th, 2010

Watch out for obstacles, like someone who takes content out of the wiki and emails it around, or someone who organizes others’ work a little too much. Help these people understand how to use the wiki more productively so they don’t inadvertently hinder its growth.

This is probably one of the more difficult tips to implement. You got everything going. Wiki pages are being created and new revisions are added. But then there is the helpful person that takes it a step too far. Who wants to make it to perfect. Who would put any thing in the wiki just because.

What do you don't want in there?

Content that should not go not go in a wiki:

  • Log files
  • Mails
  • Program code (other than code snippets that illustrate coding guidelines and alike)
  • Copies of websites
  • Database content
  • Users posting content they don't own (without revealing their sources)

Wiki patterns and antipatterns

The great site WikiPatterns lists a number of patterns and antipatterns that respectively helps and hinders getting the best results of your wiki. 

Wiki Noob Antipattern

Although some of the content and some of the roles are a bit far fetched (who ever came across a wiki noob ) there is some ground in most of the (anti)patterns the site lists. Roles described on WikiPatterns are often not really identifiable with one or more persons. In reality all of your users (even you, the wiki maintainer) will suffer from time to time to one of the lesser productive wiki behaviors. It is important to recognize such behavior and correct it.

The result

Like everything else in live, nothing comes easy. It is a matter of constant correction, review, cleanup,... You (or someone else in your team) will need to spend time every so often to correct mistakes, put the wiki on the agenda of team meetings and lead by example.

Tip9: Ask the Wiki.

September 4th, 2010

Prompt people to use the wiki. When someone asks about creating space for a project or revising a document, encourage them to use the wiki.

Relentlessly push the wiki usage

This is the bad news. It doesn’t really matter how well you prepare the wiki launch. You will need to (hopefully you will have some early adopters that will support you) push and push and push to get the wiki to its critical mass. Once everyone more or less accepts that the critical information is in the wiki, at least the more dedicated members of your team will have the good habit of keeping it up to date.

Not everyone will participate

It is always easier not to do what should be done. Many people do their job only for the pay check. They are not interested somebody would actually save time later if only they would update a wiki page from time to time.

Entropy always rises, unless you add energy

If you ever had a thermodynamics course, you may remember 'thermodynamics’ second law. This law states that in a closed system, entropy (which is a degree of chaos) always rises. Unless you add energy from an external source, systems migrate to a state of absolute and total chaos. This energy is what you should add. Each time the system tends to decay, you need to put in effort to put things back on the rails.

Entropy image, just for fun


There is a nice similarity to many business processes in general and wiki updates in particular. You will need to keep paying attention to the quality, completeness and usability of the wiki.

Can I have my own wiki?

A typical question if you are responsible for one or more wikis in your organization. In larger, more regulated industries I have seen many times that the default question to this question is NO. Or processes and procedures are so complex that people actually don’t bother asking the question.

Most of the time it is a good practice to let a motivated team have their own wiki. A minor requirement is that, when needed, content can be linked in between wikis.

If processes, licenses or any other reason prevents you from creating a separate wiki, it is perfectly normal to make a sort of navigation menu on the wiki’s main page. Each menu option then navigates to a sub-wiki where a team can regulate itself in terms of content and frequency of update. Enter the team’s name, the name or pictures of the team members on the navigation page. It will make clear that a subsection really is their private domain.

Tip8: Go back to the future.

August 27th, 2010

People will find new ways to do old things with the wiki. Embrace them and encourage additional operational improvement.

Simple example of not trying to over-manage it

If you trust the people in your team, (honnestly if you can't, change job or get another team) you need to just need to trigger the use of the wiki. That will soon lead to a new group dynamic that will use the wiki for inventive purposes. The office kitchen replenishment list was just one of the nicer examples I have seen. A list of famuous quotes by team members is another fine example. As a guidance to new users, the team had put 'Put quotes here too memorable to forget yet too embarrassing to put on twitter. The team's privacy prevents me from pasting some of the more crazy examples I found on there.

If it looks and smells like a wiki, probably it is a wiki

Pieces of information, that changes often that merit to be remembered can go in the wiki. More tradional teams, will need to 'express' their information in text, but WordonWiki helps you with tables, pictures and alike. As an admin or team responsible, you may feel awkward to 'admit' that kind of stuff in your serious, purpose built wiki. Relax, that is ok. Play with the structure to reserve those entries under a 'special team' heading. It is perfectly ok to assemble a link to all these pages on this kind of team link.

Some samples of what we've seen used successfully:

  • List of customer information for a support departement. The team used it to capture url's, special customer configurations and parameters. Every support team member used it to give remote support and to inform the team members about changes in the configuration.
  • Checklists of all sorts: installation checklist, packaging guidelines, new customer activation process. Putting this kind of information in a wiki (editable by all involved) makes sure that people will quickly add a clarification note or correct an inconsistency.
  • Special crash projects typically have a few dedicated pages. While it may seem an overkill when you are dealing with a crisis situation, you will thank the gods when the same crisis type occurs a few months later.
  • Conference and beamer reservation pages. Simple, straighforward and it works.
  • List of past system notices to inform users. Not only you can re-copy and paste from previous messages, you also get a nice log on when what event occured.
  • Sample code snippets with some explanation when to use them.
  • CV's of job applicants. Including the planning of who is seeing the candidate when. Also some preliminary feedback is noted by everyone.

I am sure some of you can add many more crazy, weird or funny examples. Comment on this post with your examples.

Tip7: Trust me. Don’t excessively manage it.

July 21st, 2010

A wiki doesn’t have complex approval mechanisms for a reason. Trust people to write quality content and they will.



A wiki is not a publishing engine

In a previous live, we have worked for some years in the publishing industry. That industry has its particular processes for content creation, indexing, storage, retrieval, review and finally publication build. Quite easy to understand when you know that the final product need to be pushed out to professional printers that, after some final processing, print it in high quantities. The professional publishing industry now publishes much of its content online. The result is that its cycle time can be drastically reduced. Yet most of the processes still apply.

Approaching a wiki with a publishing background is a definite no-no. The wiki built in mechanics concentrate on a superfast edit/publish cycle. One key feature in this is the knowledge that all changes are visible, all author actions are exposed and, if desired, all mistakes can easily be reversed. This is what is called a game changer. In other entries in this blog, we have made the case that the wiki contains many of the publishing functionality in one neat, easy to manage and understand package. Content creation, linking, indexing, versioning, review and publishing are not only all there, but they also are contained in one neat package.

So yes, the wiki content is also 'content', pushing the 'save' button can be considered as publishing and the more advanced wikis even add auto indexing, keyword management and some sort of 'table of content' creation. One big difference is that the wiki is a two way process. The reader can adapt, augment, correct, complete the content that is proposed.

So how to 'manage' a wiki?

Pushing content out there and get the wiki 'the' reference source is the task you want to accomplish. Put all of your organization's knowledge on a place where you know you can find it if nobody can be reached. So focus on getting the critical mass in there and get your team into the habit of updating and maintaining the wiki regularly.

But after some time, 6 to 12 months in most cases, you will see that the self organizing capabilities of a wiki may need some gentle push or discrete clean up and restructuring. We have called it 'Spring cleaning' before suggesting that its frequency will be rather low. Typical actions you may take are listed below:

  • Put the wiki cleaning and restructuring as a separate topic on the team quarterly meeting agenda.
  • Use new projects or special events as the reason to add new content to the wiki and archive old pages
  • Suggest searching wikis for specific problem situations that the team encounters. If your team finds it, see if it is still up to date. If not found, grab the opportunity to add a new wiki section.
  • Don't hesitate to archive complete subsections of the your wiki. Add a section called 'old' or 'obsolete version' and move stuff over there. It will not be lost and you have made room for new and fresh content.

Know it will never be perfect, never finished

This is probably more a problem for some people than for others. Some people take hours or days before they are happy with the result of their content creation. Just because everyone can see what they wrote, they get stuck in polishing and re-polishing the content. They much rather not publish anything. One trick that can help is to just open the relevant pages during some meeting or some face to face talk, and just start editing. Taking notes on the fly. After the meeting you forward url's to the pages to the relevant people asking them to complete it.