Tip4: Wikipedia does not make a wiki.
June 27th, 2010
Don’t mistake your wiki for Wikipedia. Yours doesn’t have to be anonymous and open to the public.
It never stops to amaze me how wikipedia has become the synonym of 'the wiki'. Do a search on twitter for wiki. Almost half of the people are simply assuming that wikipedia is 'the wiki'. Although technically speaking wikipedia is a wiki, the business context is slightly different. There the term 'the wiki' should at least get most people understand that you actually mean the team's of company's wiki and not the world's most wonderful illustration of its collective knowledge. As a side note, a anecdotal illustration of why wikipedia is different, is the fact their best times (financially speaking) is when they are down. Probably this is not something you can say of most of your systems and applications. This is because wikipedia's 'site is down' page has an appeal to send them some money.
There is more than one wiki software
Mediawiki is the software used to power wikipedia. Although it is one of the very robust and obviously very scalable wikis out there, spend some time to see if it would fit in your organization. One key factor you will hear us mentioning over and over again is the WYSIWYG capability, or rather the lack of it. To get a good comparison on the features that interest you, go to wikimatrix.
Try to imitate wikipedia, but not too much
Wikipedia's best lesson is that great content will attract many visitors. Another powerful lesson is that many people just want to put in the effort to share content and to help people out. They clearly are motivated by other factors than money or paychecks. Make sure to award an interesting wiki contribution with the appropriate appreciation. That alone will motivate the author and others to continue adding value to it.
Think twice about what you open to who
Wikipedia is all about sharing as much as possible to everyone. Don't simply apply this to your wiki. There are things that are better kept inside your company or even your team. The same is true for write access. You need at least the basic identification of who can update what parts of the wiki. When someone tells you to imitate the wikipedia's processes as closely as possible "because that's how it should be", run away.
WordonWiki's privilege structure in its current settings is rather simplistic: it divides users up into people having no access, those that have read access, those with write access and admins. Future versions will elaborate on this to make priviledge settings page or folder dependent. This is quite high on our backlog list as it is asked by many people.
Even wikipedia has a strong editorial staff and process in place. Many of the pages are true battlegrounds for people coming from different opinions, religions and beliefs. Yet, almost all of the controversial pages, have truly great content and represent a balanced view about the topic.
To conclude...
Wikipedia is the best and worst example for your in-house wiki:
The best because
- Great content is provided because generally people want to share.
- Its software scales to be one of the most visited sites in the world.
- Its brand name is so strong that it has become the synonym of 'the wiki'.
The worst because
- The whole world is your team. You'll be lucky if you will have a core team of 3 regular contributors.
- Wikipedia is kept up to date up to the minute. Events just happened are available almost instantly, much faster than newspapers or even radio/TV. In your team, you will need to relentlessly ask the team: 'has the wiki been updated yet?'.
- Wikipedia's underlying software is not really supporting easy and fast data entry. Although most of your users will never have attempted to update a wikipedia article, if they have come across other mediawiki implementations, the arcane interface may frighten them. Luckily, more modern tools exist that make WYSIWYG possible.
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.
Tip3: Populate it and they’ll come.
June 1st, 2010
Put content on the wiki; direct people to it using email.
This tip seems a bit counter-intuitive. I mean, that sentence originates from the "Build it and they will come", which has become somewhat of a sarcastic statement. And that also the way the authors meant it. You need great content, that's for sure, but you need to open people's eye to where that content is.
Email is your friend
We've said on many occasions that whatever get's emailed to more than one person, is a candidate to be put in the wiki. So why use mail as your friend? The big difference of course between mail and wiki pages is the push and the pull mechanism. An email is really pushed in the person's inbox whereas the wiki page needs to be navigated to. Because people like short and clear emails, concentrate the gist of what you want the recipient to do with it (understand, take action, remember,..) in the email body, but the background is pointed to by an wiki url.
Topics you can offload from an email to your wiki are: attachments, process descriptions, specifications, and so on. Things you would need to remember or that you want the team to remember.
Your cunning plan
You could of course make the wiki so content rich and so well structured that people can simply not ignore it. Once all the collective team knowledge is in a wiki and that wiki is well structured and easy search-able, you will find that no decision can be taken without consulting some of its pages. The cunning plan is to make the wiki the sole place where up to date information can be found. Archive folders that contain useless and outdated stuff, publish updates of once used files and network locations on wiki pages only. Soon you will see no one can ignore the wiki.
The baseball field in the picture above comes from "Field of Dreams", a 1989 American drama sports film. In this film, Ray Kinsella (Kevin Costner) is a novice farmer who lives in rural Iowa with his wife, Annie (Amy Madigan), and their young daughter Karin (Gaby Hoffmann). While walking through his cornfield, Ray hears a voice whisper, "If you build it, he will come" (often misquoted as "If you build it, they will come"), and sees a vision of a baseball field.