It’s apparently time for everyone to think about wikis.
I was inspired by Matt Haughey’s “CSS wiki zen garden” to try setting up a wiki for one of my sites. I had no idea how difficult and confusing this would be.
I entered this mission with clearly-defined goals:
- I wanted a site where my readers could easily create and update pages. Sounds like a wiki!
- The software needed to be (really) easy for a Unix doofus like me to install. UseModWiki took me about 15 minutes to install and configure, but it was downhill from there.
- The site’s design needed to be consistent with the rest of my site. that means I need to use CSS and to include a navigation bar. Navigation turns out to be a special challenge.
- I didn’t care whether the software was based on Perl, PHP, or Python, since I don’t understand any of those languages well enough to modify the software. But that also means the package can’t require me to modify its code to get something done.
- The pages need to based on templates that can be modified by someone who knows HTML and CSS.
- It would be cool if the software supported search, an index page, and RSS.
- I’m not sure if I should care whether the software stores pages in MySQL, a built-in database, or a big pile of text files in a directory. But, as far as I can tell, there is no way to move pages from one wiki package to another. I suppose the markup is so simple that one can manually move wikis with even hundreds of pages.
Like most simple plans, mine ran into some harsh reality.
I’m not sure anyone knows how many wiki programs there are and I haven’t been able to find a comprehensive list. Wikis manifest some of the worst aspects of open source software. Everyone has their own package because everyone thinks they can do it better, their preferred language is superior, or that they should be in charge. And because wikis are so simple, it appears that anybody can write a wiki package.
Wiki authors should talk to Ben and Mena Trott about how to create templates. The wiki templates I have seen are programs that contain HTML markup, and not HTML pages that call program macros.
Because wikis date back to the earliest days of the Web and because they are based on a doctrine of extreme simplicity, and probably because there are so damn many of them, they have largely ignored everything we’ve learned about building Web sites in the last near-decade. Their accomodation of CSS is weak. They typically don’t support tables, even for tabular data. Their notion of content management is all over the map. And they don’t support any navigation other than inline or generic navigation links [Home, Edit, Recent Changes].
Try finding information about wikis using Google. One problem is that, unlike weblogs or web sites, most wikis have the word “wiki” in their name, so it’s difficult to separe pages about wikis from the wikis themselves. It’s like searching Google for “home page”.
Navigation is at the heart of my problem . Unfortunately, most information about wikis is stored on wikis, and most of it consists of links to the same pages, most of which are waiting for wiki users to update them with useful information in lieu of placeholders. Even when I can find a site with useful information, like Choosing A Wiki, once I begin following links, I soon become lost in a way that I don’t on most modern Web sites. . Even the vaunted Wikipedia is a hopeless maze of twisty passages.
Can anybody point me to enough information to find a wiki package that meets my modest criteria?
15 thoughts on “Building a wiki: a maze of twisty little passages, all alike”
Yes, while the defult installation has an assy brown color is outstandingly simple to use, is free of clutter, supports rss, and has a specific file for css.
After unbundling it you do a quick “./install.sh” set a few permissions and you’re off to the races.
Whoops. You should be able to edit your own posts in MT.
The above should read:
Yes, while the defult installation has an assy brown color moinmoin is outstandingly simple to use, is free of clutter, supports rss, and has a specific file for css.
After unbundling it you do a quick “./install.sh” set a few permissions and you’re off to the races.
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….
I just started playing with Wikis, and when looking for a suitable implementation, I found going to the original Wiki the best solution: the WikiWikiWeb has the WikiEngines page, which lists dozens of different implementations.
I chose PmWiki, since it has a very simple install, produces valid, albeit outdated HTML, has revisions and several kinds of access control.
That page underlines my problem. There are indeed dozens of wiki projects listed, with no information about them other than the language they were written in.
Apparently the only way to find out which projects meet my criteria is to install each until I find one that works. Since none are likely to be a perfect fit, I’d have to install and test them all.
Tom Coates has a great article on “(Weblogs and) The Mass Amateurisation of (Nearly) Everything…”. Tom makes some good observations
The wiki engines page is a comprehensive listing of all the wikis. Since it’s a wiki if you felt that you needed more information about a particular wiki you should have added your question to the page.
More usefully you could have identified a wiki which came close to meeting your requirements and emailed a feature request to the author(s). Everyone has different features they’re interested in and it’s very easy to say yes and end up with a monster like Twiki which supports every feature you want but will take weeks to get running. The essence of the wiki idea is simplicity. If you add too much complexity you might as well be using Lotus Notes.
I don’t see a way to get a list of wikis that meet my criteria, particularly templates. I’m not even sure where to post the question. That wiki list doesn’t look right. If you can point me to right place I’d appreciate it.
It seems like the only way to do this is to create a new page called HelpBarryParrFindAWiki pointed off that list, which seems wrong.
More usefully you could have identified a wiki which came close to meeting your requirements
How? That’s my problem.
Regarding Notes, heh. See Notes on Notes for my opinion of that particular piece of…software.
The only things I require that I can’t find together is easy-to-modify HTML templates that support CSS and inclusion (via server-side includes or macros), and easy installation. Both are very wiki IMHO. Lots of extra points for a broad user community.
General: Scientology bites the dust | Trackballs, a fun game | Scarey Identity Theft | SkyOS GUI contest over in a day Web: Three bugs until Mozilla Firebird 0.7 | CSS Zen Garden to continue using Creative Commons licence |…
I suspect the reason most people don’t support valid html in their wiki engines is because it’s very difficult. I wrote my own wiki engine and the syntax for lists was the hardest part precisely because I wanted to generate valid html that used CSS. The best approach involves writing a full-blown parser rather than just using regular expressions. Most people use regular expressions because it’s much easier to get something working.
Very Quick Wiki by Gareth Cronin seems to fit your requirements very well. It does searching, RSS, and being based on a proper parser it generates decent html. The only downside is that, like my own KwikWiki it’s written in Java which may make it hard to deploy on a hosted site.
Your article has inspired me and the next release of KwikWiki will include a variety of stylesheets to show people that they don’t have to stick with the defaults.
And I also added your question about templates to the bottom of http://c2.com/cgi/wiki?RunningYourOwnWikiFaq so that in future there will be a central place for people who are interested in the same issues.
Yes, I’m sure I’m a bit late now but I’m intrigued by your attitude Brian.
It sounds like you want a site similar to http://freshmeat.net/ but for wikis or something.
Sure if you start at the WikiEngines page above you have to do a little research – you have to actually click on some links in order to find feature sets for each bit of software but why are you expecting this to be spoonfed to you?
Would you expect that if you google for blog you’ll come up with the perfect blogging software package without actually having to do any work yourself?
I think wikis are incredibly cool, and potentially paradigm-shifting, but until they’re easier to shop for, they’re going to be a marginal technology.
There are maybe half-a-dozen popular weblog packages. There are twenty times that number of wiki packages. And the information about how they work cannot be found in public source. Take the example of templates. I still haven’t found a wiki with templates that a nonprogrammer can modify and which support real control of the page’s appearance. The only way to find out how they do it is to download and install the package. I don’t have the time or patience for that.
If I could narrow it down to half-a-dozen likely wiki packages, I’d try the all out and report the results on MediaSavvy.
(Lately, I’ve been using PHP, so I’m willing to limit my search to PHP-based wikis. Any suggestions?)
There’s absolutely too many wiki engines. But, then again, there’s too many of lots of things.
Here’s half-a-dozen or so PHP-based wiki packages that you can try out and discuss:
I’m pretty sure you’ll want PmWiki. It installs very quickly, is highly configurable, has great template support (well, OK, kinda great), has a lot of documentation, and generates clean XHTML with CSS styling.
Oh, just to be clear: I think most of those packages are overkill for your needs. But they’re the most prominent PHP-based wiki tools, so if you’re going to do a shootout, they’re the ones to shoot. At. Or something.