The Perfect Wiki

A wiki is a great place to store braindumps, thoughts and ideas, and lots of personal scatterism. What’s so great about wikis is that they’re flexible, you don’t have a predefined sitemap, you don’t have to restrict yourself to a certain organization, your creativity just flows…

I’ve been researching wikis for the last couple of days, I needed a wiki for Codeflakes, tried almost every wiki I could get my hands on, Kwiki, Meatball, MoinMoin, ZWiki, MediaWiki, PmWiki, Twiki, and a dozen of WakkaWiki forks. The problem is that I like a feature of each, but none of them has it all.

So here’s a list of features I think that the perfect wiki should have:


What I mean by flexibility is that the wiki should have the ability to use custom templates, and make that easy for designers. It doesn’t have to fix “edit this page” on top or bottom, let me decide, it shouldn’t have fixed pages like search, comments, etc. I should be able to design the wiki’s layout and overall sitemap the way I want.

Localization is sometimes critical, the perfect wiki should be able to deal with several languages, separate versions of the same site, page translations, and that also includes the administration interface and all internal words and sentences.

Ease of use

The whole point of using a wiki is to encourage collaboration, don’t make it difficult for users to fix minor typos or add some content to the site, don’t let the user take difficult decisions like “This is a minor edit” unless they want to, or even better, let the wiki decide, have some bayesian or AI code to determine what’s a minor and what’s a major edit.

No server round trips to the server to edit a page unless it’s absolutely necessary, let the editing occur on the same page that the editor is viewing, some JavaScript code will work, you can even have RPC calls (via XmlHttpRequest or similar) so the page doesn’t refresh when editing or saving.

A wiki shouldn’t clutter the interface with tons of irrelevant links, make them appear as needed, don’t confuse me when I’m reading a page, especially when I’m a first timer, I don’t want to see words like edit, discuss, comment, history and the rest unless I know what a wiki is. Yes, a lot of people already know what a wiki is, but think of the poor newcomer who’s confused by “edit this page”, he’ll think why the heck should he edit this page?! Be gentle, the user is more important the software.

Absolutely no hidden actions! It’s a stupid idea to make double-clicking a page comes up with a huge text box with some content. I, and probably a lot of other people too, have this nasty habit of double-clicking words to highlight them, this helps me focus on what I’m reading, it can also help me copy a single word, a date or a location. When I double-click a word in a page I expect it to be highlighted, just that double-clicked word, don’t change the behavior I’m used to, you’re not making it any easier for me.


A page’s history should be easy to read, I don’t want to see +++, ---, >> signs all over, just get to the point, tell me that Joe added this certain sentence to Jane’s page, I don’t want to “parse” the history, it’s the wiki’s job to do that. However, I wouldn’t mind the option to get the same history in GNU diff’s format, it might be useful somewhere else.

Faceted Categorization

Facets are the new folders. The perfect wiki should use faceted categorization by default, some pages don’t fit in a single place, and it’s easier to find certain information if I have several paths to it. For instance, a page about “The Godfather” movie can have at least two paths to it, say Films > Genres > Drama > The Godfather, and Films >Oscar Winners > 1972 > The Godfather. Think Gmail labels, WinFS or Spotlight, make it easier for me to search and browse the wiki.


The perfect wiki’s output should be valid XHTML. One of the many reasons for that is because I can process XHTML through an XSL processor and generate all kinds of other document, SXW, PDF, SWF, HTML Transitional, plain text files, just about anything. It even makes it easier for the perfect wiki to have these alternative views built-in and generated upon request. Oh, and it’s always a good thing to make W3C’s validator happy.

Have a clean and clear structure for the output, sometimes a designer doesn’t want to mess with tons of template files, sometimes a designer just feels lazy, make it easy to change the layout and design using CSS.

Separate backend

The perfect wiki should have a separate layer to support multiple backends, it should be able to use just about anything to store it’s data, ranging from plain text files, to RDBMS, to SCMs. I’d like to be able to choose where my data is stored, some people like CVS, others like Subversion, maybe Oracle, PostgreSQL or SQlite, just give me choice and I’ll know what to do.

You can have a standard (XML-based?) format for wiki pages, and various plugins simply query the wiki’s API for information and store data wherever applicable.

Hooks and Plugins

The perfect wiki should have a clean and well-designed API, it shouldn’t be difficult to write plugins, all sorts of plugins, text-filtering, layout, special pages, alternative views, import/export plugins, backend storage, and basically everything the perfect wiki can do should be changeable via plugins. A plugin should know, at anytime, the current state of the wiki, which page is it viewing, who clicked it, who was the last person to edit it, date and time, current language, all information should be available. It won’t be a bad idea to have the same API exposed via XMLRPC or SOAP, some person with time on his hands might even code a wiki desktop client, who knows?!


Now that’s critical, the perfect wiki should be capable of being loud, it should be able to notify anyone anywhere of recent changes, recent members and all that kind of information, it should be able to send emails, generate RSS and Atom feeds, announce on IRC channels, budging me from time to time is ok too. Don’t be loud and annoying, but be able to be.


Assuming this perfect wiki is already using faceted categorization, it should be pretty straight-forward to generate a sitemap, not the regular tree-like sitemap, but a mind-mapping kind of navigation, where a single page can link and be linked to multiple pages. If you don’t know what I’m talking about try TikiWiki’s 3D browser, that’s almost what I have in mind, except that TikiWiki’s browser gets pretty cluttered with busy pages, and it uses Java; did Flash just die?!

ACL and Permissions

This should be obvious, the wiki’s administrator should be able to set permissions on each an every bit, including regular and special pages, administration pages and plugins. I think UNIX file permissions are one of the best models that suite wikis, each page will have only one owner and certain permissions for owner, group and then the rest. CoWiki does this, but the problem with CoWiki is that it’s written in PHP5, and not many hosting companies support PHP5 yet.

The wiki can have more permissions than just read-write-execute, it can add edit, view, protect, allow discussions, etc. And it should be easy to edit permission by just clicking a link, or edit multiple pages’ permissions at a single time, maybe like chmod -R.

Built for Communities

The perfect wiki should have building communities in mind, it should support discussions for every page, comments, footnotes, scribbles, related and similar pages. Certain discussions can spread over multiple pages, let’s say wiki users are discussing design patterns and how do they fit in the enterprise, this kind of discussion should be available on both DesignPatterns and EnterpriseDevelopment pages. It should make it easy to add references, ISBNs, links to external related articles, upload attachments, maybe even version them. It can take it to an extreme an integrate with some mailing lists software, like Mailman or Majordomo, archive their mboxes, and view the discussion as a part of certain pages, or a group of pages.

Well implemented

All the above features are absolutely useless unless they are well-implemented. That means it should be URL independent, I should be able to move the wiki’s directory to any place just as long as it’s viewable by the Web server, I should be able to place configuration files anywhere I like, and only point the implementation to a path, I might be lazy, but I only back up my /etc and /home, don’t make me look elsewhere.

Installation and configuration must be a breeze, it shouldn’t take me more than a couple of minutes to get the wiki up and running, filled with data, and actually works! I like fiddling around with software, at least I’ll get to know what’s it good for.

Open Source

This isn’t obligatory, but it fits the spirit of the wiki well. The perfect wiki should be open source, exposed to the public, editable, maintainable, and liked!! It should be good enough to develop a community around it, a community that can provide support, consultation, and best of all, customization of this perfect wiki for larger enterprises. Let the wiki be suitable for anyone and everyone.


This, by no means, was an extensive list of features I’d like to see. I only meant to highlight the lack of certain features on most wikis. So if you’re a guru, go ahead, maybe you could try creating once and for all… the perfect wiki.

One Response (Add Your Comment)

  1. Well-stated, Rami. Even if the platonic ideal never gets created in reality, its descriptive powers can be used to improve existing wiki projects.

Other Entries

Tweets from