Roadmap for future wikis

Yep, wikis are a total nightmare. I don't know why I went easy on them in my previous posts, as I wanted to share all the things they do poorly when I posted recaps. Might as well do it now.

Overall, people that have had their "light bulb" moment with a wiki love them and would love to see wiki functionality in other kinds of sites. The following suggestions are all geared towards making wikis more easily understood and used by most web authors and readers by reducing the wiki cruft and wiki geek features to act more like a typical website people are accustomed to reading and building.

My first problem was finding any package that could output good html. Only a handful (maybe 3-4) could pass the HTML validator for anything beyond HTML 4.01, but all but one still output terrible markup. They either use line breaks instead of paragraph elements, or they forget to use closing paragraphs. Some packages (it looks like MoinMoin is one of them) output html in CAPS so you'll never get xhtml out of them without doing modifications.

I don't know why this is so difficult for wiki package authors to get, but if you want to build a powerful package, have it output pages that look like this:

...
<h1>Page Title</h1>

<p>first bit of text.</p>

<p>next bit</p>
...

PHPwiki was the only package I found that could do this.

Navigation is always going to be difficult, as wikis are supposed to be flexible enough to grow in any direction. Consequently, this means you often see a link to absolutely everything on the main home page, which is an information nightmare. It'd be nice if you could flag a handful of pages as the major ones, and have navigation bars build up automatically (on my wiki I had to hard code them by hand). Of course before you can have a nice nav bar, you have to dump the ones that ship with wikis, which leads me to:

Wiki package authors need to get over their geeky features. Just because you can do backlink searches, subscribe to pages, and measure file differences on all the previous versions of a page doesn't mean you should display these things for all users. Look at this random page from a MoinMoin-powered wiki. How much actual content is there and how much is geek cruft that only a subset of users would care about or even know how to use? Give all but logged in users a minimum set of functionality that actually improves their experience, not hinders, and stuff the info in the footer, not the header of the site. I know wikis were designed by engineers, for other engineers, but the general public is beaking into the wiki world and not all of them know what CVS is.

As Barry found out, the template systems are fairly arcane, requiring you to modify html around programmic code (perl, php, python, etc, it's usually intermingled in the templates). Approach wiki templates like a powerful blogging system. Templates should be pure html, with calls to functions that include other bits of content and html. Make templates for all those other bits too, so that when you include [$navbar$], you can also modify the html within the navbar include. Also make the main CSS file a template that can be used to control the layout and design of the entire wiki. I know this might mean a wiki could have 20 different templates, but them's the brakes, and people would prefer the flexibility and control over their look and feel. Like blogging engines, most users would start with the main template, and only the industrious few would go into every template to make sure every last line of code was valid and correct.

Blogging tools have done templates this way since 1999, and so far I haven't seen a single wiki adopt this method, though I've only looked at 7 or 8 packages and I know there are dozens now. It's simply a matter of removing as much hard-coded HTML from within the wiki's codebase, and move it out to your template engine. You don't want people to get to the point of saying "boy I hate the way the calendar's HTML is coded by my wiki package and I can't modify any of it." Let page designers sculpt and mold any and all HTML output by your engine, because this is how organizations work. A group has a site, they might have an engineer coding it, and a page designer making it look nice, while others work on content and marketing. Wikis should allow this type of backend collaboration as well as the frontend.

They also need to provide a method for linking beyond CamelCase. Give me a shortcut to make a regular, single word into a new page. Perhaps I could write &&contact and have that become contact?, and build a new page that doesn't have to be called ContactThisSite in the URL and title in order to be easily added to the site.

I'm sure I'm missing a lot of things I found out while setting up my wiki, but this would be a good start to building the ultimate wiki package that users and designers would like.