Designing a Wiki, design considerations and feedba

Question

When designing a wiki application, what things should I take into consideration?

So far I have:

1. revisions
2. parsing some sort of markup text
3. keeping track of links in wikis, and pages that link to other pages.
4. related wikis i.e. wikis are related to others.

What else goes into building a Wiki?

Answer 1

I wouldn't start a new wiki engine with the same features that everybody has, there are so many of them out there.

I would only work on one that offers something different/unique, much more than a standard wiki.

Some ideas include (maybe some wikis already have this):

• The ability to have the wiki merged with a VCS, to discuss revisions/changes and be able to do code reviews (anything that gets committed automatically creates a page for the revision), having it linked to the committer and anybody in the discussion and sending them email alerts would be nice.
• An API for the wiki that allows 3rd party application to do mashup-style integration.
• wiki-style multimedia (Text, Images, Audio, and Video) that contains links to other media.
• multilingual side-by side editing and translation.
• a client-side editor/viewer (not web based) for faster response and real WYSIWYG editing.
• ...

Answer 2

Often overlooked:

• Good search
• Hierarchies. One of the things I miss most in Redmine's wiki.

If you find a good way to implement a wiki that is easy to reorganize, that would also be great (i.e. rename a page, or join two pages into one and don't break a zillion wiki links).

Answer 3

Every time I've tried to get non-developers to use a wiki, the difficulty of writing text has been the biggest barrier. A WYSIWYG editor along the lines of what StackOverflow has seems like a great idea to me. It still shows the markup in the box, so motivated users will eventually learn to use it (thus becoming more efficient), but it also shows a live preview, so that users get instant feedback as to whether their text looks correct.

Along these same lines, another annoyance is that every wiki seems to use slightly different markup. I guess each designer thinks they can do it better than the ones before. I would suggest using either MediaWiki's syntax, or something like MarkDown that's sort of standard, so that power users will have an easier time of things.

Finally, consider what about your wiki will set it apart from the many many many many other wikis already out there, and how your design will impact this.

Answer 4

User interface -- one of the most frustrating things for users is that they have to learn one user interface for MediaWiki, one for TikiWiki, and one for any of the other myriad of wiki's out there.

The most important part of wikis is not the technical feasibility -- it's getting users to contribute and edit in a convenient and effective way. You can have the most technically robust wiki in the world, but if it's not easy to use, it will be useless as the community tool that a wiki is supposed to be.

Either copy an existing and familiar wiki syntax (such as MediaWiki), or be prepared to invest heavily in creating a WYSIWYG editor.

Answer 5

Have a look at TiddlyWiki. I think it has the best combination of features I've seen in any wiki. (For "pages" below, read "items" since TiddlyWiki is a single-page wiki. But I think these features should apply to wikis with pages too):

• List of all "missing" pages (WikiWords with no page)
• List of orphaned pages (pages with no links to them)
• Most formatting is done by editing wiki pages
• You can't screw up formatting, because there's a default if you delete your custom formatting
• You can tag pages
• You can include a page in another page

And plenty more that I haven't mentioned. I think the formatting is possibly the best of many good features, because it's so easy to edit and so hard to screw up.

Answer 6

Make sure you perform input validation on all the edits people make to prevent XSS. Nothing would ruin a good wiki like people getting hacked.