Wiki Blog

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.

Tip5: Go to the source. Put some content exclusively on the wiki so people get used to it as the source of information.

July 7th, 2010

Your way to make the wiki be the true source of content is to make it indispensable.

Part of the cunning plan

We've written about this before. In most business situations, there is a lot of collective knowledge that cannot be remembered by most people. So all these typical topics are good candidates to be put in the wiki. We give a list of possible 'unique reference opportunities' below:

Reference information on people

• Your team members are the first candidates to be put in the wiki. I have used every occasion I got to create personal pages for each team member. I provide some basic information about name, location and so on. Then send the person the link to his page with a request to complete it.
• Basic lists like contact lists containing phone numbers, msn and skype id, email links, home phone numbers and so on are a pretty easy target. If you see it is used by many people, put a link to it on the home page.
• Great content like the team's barbecue pictures, or references to news articles or other publications seem like bringing little value to the wiki, but it surely attracts many visitors. If you are not using an easy to use way (read 'drag&drop') to insert pictures in pages like WordonWiki offers, you may find yourself doing quite some editing. As a tip, don't drop all links in the page, but make sure the pictures are visible when opening the page. To get people in the habit of editing pages, insert some funny captions along with each picture and invite others to do the same for the other pictures.

Reference information on the work/project

The names of the people from the customer site are often very interesting to be put in a dedicated wiki page. Don't be afraid to also add a line of explanation what each name really means. Indicate their role in the customer organization and explain for what they are supposed to be contacted or not.

Any reference or url to the selection of company processes or methodology elements that are applicable to the team can be referenced in a separate page. Don't hesitate to add explanatory text of how the team should judge the application of these standards. You can explain why some guidelines are absolutely essential and how some others are only of secondary importance. Your team will appreciate you put how and what to apply in writing. As a word of caution: beware of regulations that can exist in your company or industry.

Major milestones, important deliveries, budget or timing constraints should be explained in clear and simple terms. Don't use overly formal language. Rather write things down as you would explain it in a team meeting.

Dedicated topic pages

Each team and project will find itself from time to time facing a big challenge. Some nasty bug that is bothering them, some crash exercise to remedy a crash situation, some change project or alike. These topics often merit a set of dedicated pages. Something like a wiki in the wiki. You will find these pages get consulted and updated a lot during the crash exercise and are much less visited later. However that is not a problem. You will thank the effort you have put in as a team the day a similar problem reappears. You can quickly tap in to the knowledge that you built up six months before.

Don't bury pages to deep

One experience we would like to share is to take care not to bury pages to deep in the hierarchy. Although today's search algorithms should help you find back quickly the information, this only helps if you know there is some content that you can search for. If you are just browsing page content, make them rather rich in terms of number of links to other pages. It helps to limit as much as possible the depth of the navigation tree (Maybe max 4 or 5 levels deep in a wiki of a few hundreds of pages). One way we have used successfully is to have the links to all the dedicated topic pages directly accessible from the home page. Instead of creating an link to an index page, put all the dedicated topics one after the other on the home page. Even if you got 10 or 15 of those, it will only take 2 or 3 lines and people are immediately confronted with new links that are added.

What the experts say on wysiwyg editors in Wikis

June 18th, 2010

The great site wikipatterns has a full page dedicated to the benefits, problems and tips for a wysiwyg editor. We feel this page is written more for makers of wiki software than for the people wanting to introduce a wiki in their organization. Yet there is some interesting stuff in there we can pick up.

Wysiwyg Benefits

The site lists following benefits:

• Avoids users having to learn the details of the wiki markup before they can contribute. For many users, particularly non-technical users, the learning required can be a significant barrier to participation.
  
  We couldn't agree more. A wiki's success is directly proportional to its content. With all the focus on usability, the obscure textile or crappy wysiwyg editors seem counter intuitive to everything we learn from the Don't make me think mantra.
  
  
• Better media integration. When users can see the page as they edit, they are often more inclined to include images and other media to assist in communication.
  
  Again we are in full agreement. However, we still need to come across the wiki that let's you do this as easy as Microsoft Word.
   
  
• Allows users to achieve better results faster. Users will be more likely to create pages that visually appealing if they can see the page as they edit it. While this may not add to the content, it can encourage users and give them more confidence with using the wiki.
  
  No comment.

Of the common editor problems that wikis may have, we have looked at the following ones in detail:

• Slow editors. A number of in-browser editors can feel sluggish to users. While this may seem like a small problem, it can become very frustrating for users over time.
  
  We can testify this ourselves. This frustration has grown so big we ended up building this product for it.
  
  
• Buggy or unintuitive editors. Many editors frustrate users over time because of bugs in the software or simply because they force the user to stop and think how to operate the editor instead of focusing on creating content.
  
  Indeed, try to create a list in a list, one numbered and one unnumbered. Try to indent/unindent. If your editor is still behaving, try to add newlines within a bullet point. If you are really adventurous, try to make one list level use numbers and others bullet. Beware, try this at your own risk!
  
  
• Inaccurate conversion between wiki markup and HTML. A number of wikis use a HTML editor but actually store the content as wiki markup. While it is straight-forward to convert wiki markup to HTML, it is very difficult to convert the HTML back to wiki markup. An alternative for private wikis is to use HTML as the storage format and this is supported by many wikis. Publicly editable wikis need to be cautious of security issues when allowing HTML content - it is possible to sanitize the HTML so it is safe, but most wikis pass the HTML through unfiltered.
  
  In the WordonWiki case, this problem is actually solved for us by the wonderful engineering teams at Microsoft. While their generated html leaves a lot to be desired for, converting from and back the page edit and the page view works wonderfully well. Tables, lists, footnotes, embedded excels, revision marks,.. there seems to be nothing these engineering teams do not handle.
  
  
• In a small number of cases, the user's focus may be drawn to the page layout and formatting instead of the content. If this happens, the simplest solution is often to disable advanced features of the editor to limit the options for authors and encourage them to focus on the content instead of the formatting.
  
  One strange piece of advice indeed: if it doesn't work or if it hurts, simply disable it. We understand of course why the author has listed this as the best pragmatic advice. To be honest, for some users also Microsoft Word could do with some 'functionality limiting mode'.
  
  
• Many wikis have sophisticated mechanisms for advanced content production (like page inclusions, page templates, plugins, ...). These are usually implemented through special syntax constructs which may not be available through the WYSIWYG editor, limiting the users to do trivial tasks
  
  In the case of WordonWiki, that simply does not apply. The 'special syntax constructs' are not there.

To conclude this article, we would like to reference an article on the 'Kick-ass curve' that is also referenced on the wikimatrix page (we have to give them credit for always including very helpful links). Make sure to go to view this 'Kick-ass curve'. A thing we as software makers need to keep in mind. 

Tip2: Throw out the rule book!

April 28th, 2010

Don’t start with a lot of structure and rules. Make a wiki available, then see how people use it, and grow accordingly. Follow the lead of the people using it – that’s at the heart of how social software works!

This tip goes to the heart of what the web2.0 movement is all about. Everybody is contributing. In this way, the result is better than what you would ever get when you tried to enforce it to your team or department.

It is not really the absence of rules that constitutes to the success of a wiki, but the freedom that people feel that they can take part in it when and how they want.

Why does 'absence' of too many rules gets teams on average to a better result? What motivates people to take the time to enter a new wiki page or to amend an existing one. In general because they feel that is something they ought to do.

Revisions, the feature you need but will rarely use

The single most important feature that explains why you don't need too many rules is the wiki's revisions system. Everything that was ever there, good or bad, is remembered. And is there for everyone to see. I have seen only on rare occasions that somebody had to revert to a previous version because somebody messed it up. People just need to understand that that feature is there. This understanding will keep them from spamming the wiki or getting engaged in some foolish escalating correction upon correction game.

The question of motivation comes back later, when we will try to understand what it is that makes people wanna come back to the wiki to make it better.

Page templates should help, not enforce

A word of caution about page templates. These templates are available when pages of a certain type are created. These should not be viewed as "fill in all the boxes on this form, or else it is invalid". Rather it should help new page authors structure the information on the page so that some kind of uniformity is reached. Rather use templates to assist on what kind of content is typically provided on a page of that nature.

I don't know where we are going, but we are getting there very fast

This is a slight exaggeration of course, but there is some truth in it. You may know where you start with a wiki, but you will need to have an open mind to see where people take the wiki. Don't try to limit the use of your wiki when it goes into a direction you did not anticipate. When the team decides that they need content on a topic, try to understand rather than to stop it.