Wiki Problems
- 4 minutes read - 669 wordsI really like the idea of having a wiki website. It’s great to be able to share documents really easily, be able to edit stuff without logging in, track changes you’ve made, and so on.
I have also tried quite a few wiki setups, including MediaWiki(mostly at a job a while back and a spectacular success), MoinMoin, and PmWiki. However, each of them fell flat in a certain annoying way.
Mediawiki is very close to perfect. It a good(or at least, familar) interface for viewing and editing, and an amazing history to go along with it. Plugins are easy enough to deal with, and while I don’t like PHP coding all that much, it certainly is where it’s at with respect to ease of deployment. However, while the trust assumptions make sense for the encyclopedia-type data they are running, it makes little-to-no sense for how personal and research/course related materials should work.
MoinMoin and I also had a great start. The python was somehow more painful to deploy, but probably this can be attributed to my own inadequacies and laziness to thoroughly read the instructions. In my defense, my goal of any computer interaction has changed from ‘Play with fun toys’ to ‘Get real work done’, lately. Setup pains might be a O(1) dose of painfulness, and there’s a lot to like here. MoinMoin’s access control lists are perfectly executed, in my opinion. Some big issues remain though: Inconsistency with forward versions of the software(ie, everything I learned to get productive on an early version is junk for the latest and greatest), inability to edit sections of text(Mediawiki has this nailed), and, surprisingly, spam has been a huge issue on my personal site.
PmWiki was introduced to me by my dear friend Sharvil. It comes pretty close. The plugin structure here feels even easier, and it’s an absolute cinch to install. I got math markup working very easily, and it seems pretty nice. The PmWiki philosophy is very similar to the latest Apple ad campaign, except their mantra would be: ‘Yep, there’s a plugin for that.’ This is all fine and good, except that it means that some things(users) are essentially an afterthought, and this complicates administration for the poor saps that have to use it. One exchange on their wiki suggested putting admin-vs-anonymous logic in the theme, which severely damaged the amount of trust I’d be willing to put in them.
I haven’t addressed some other things yet. Notably, I’d love:
- a git repo to get out-of-browser(either TextMate or Vim), offline editing
- the ability to edit sections without editing other parts(this was a giant boon when working on the course report/group project in Brazil, and I’d hate to imagine life without it.)
- really easy thumbnail uploads, or a way to pull pictures from google images/flickr
- access control lists and users as a design attribute, and not an afterthought
- Math-mode with $ f(t) = t^2$
- printable mode that makes math look really good, or PDF export
- ReCaptcha support. Ideally support a user-configurable number of edits for a ReCaptcha to be valid for.
- RSS feeds with a changelog(MoinMoin does this very wrong)
Some more thoughts: I like how ReStructured Text looks in text and HTML-rendered formats, but I’m not slick with Python. Perhaps now is the time to get that way? But if MoinMoin is a pain to install due to Python layout, I suppose I couldn’t do much better.
I suppose this is a long enough rant on the current state of Wikis. I have this strong urge to start coding this up and see how well I could do, but the reality is that Wiki software is very hard to do correctly. I haven’t even addressed in any of this how database-driven to make this type of setup, because I’m not sure what the right mix is. So I’m trying hard to resist this urge. There’s always something more pressing to work on than a Wiki framework that nobody but you is going to view, edit, or extend.