Return to Wikiland

Years ago, I tried making a game design wiki. I discovered that collaborative sites don’t magically create communities, and didn’t maintain the site all by myself.

It had occurred to me that an internal wiki might be interesting at my employeer. Perhaps starting it in my own department and seeing if any other interest sprouted.

It came about that I heard of a plan to make daily archives of a planning spreadsheet to in order to maintain history. I immediately thought of the automatic versioning common to most wiki.

Things being a little slow with actual software, I went looking to see what kinds of wiki were available. Before long I found Wikimatrix, a site that allows comparisons of various wiki (and, of course, is wiki-ish itself.) I plugged my parameters into the wizard (which has been stripped down since then) – revision history and a WYSIWYG editor for the less technical office people, and then started looking over the results, and applying other filters, like a clean markup syntax.

Eventually, however I got sucked in by features. TWiki is one of the major wiki engines, deployed by several large corporations. Consequently it has plugins for most everything. The key idea it has is being a structured wiki. I’m always a sucker for a good idea. About the only other wiki that is reputed to support this is JotSpot, which is hosted only (definite ownership mentality at my company) and currently closed after it’s acquisition by Google.

The idea of a structured wiki is that topics have data attached, which can be classification, dates, people, and so on, allowing you to build up ad-hoc databases by searching and formatting the fields. Combined with templates, forms, and making URL parameters available via special tags, you can build up miniature web applications with relative ease. I’ve since made an installation on my home machine to try building up a curriculum database the martial arts school – editing separate curriculum sheets every time something changes always seems terribly inefficient.

There are downsides of course. For one, it’s written in Perl, with which it shares many traits. TWiki is feature rich of course, but also slow (a known problem, but one to which I can personally attest) and well known to be difficult to set up. The main things that has been saving me on the last point is TWiki itself – I’ve kept a wikipage log of the installation, to records problems and solutions. The template (‘skin’) system conflates look-and-feel with the ‘system’ content and maintenance pages, and is notoriously hard to modify. I’ve currently got a programming project going at home to analyze the 50 or so template files per skin and tell me what the heck is going on.

The other issue is syntax. Features like full text search with limited regular expressions are powerful to be sure, but the syntax is extremely verbose and nesting is abysmal. Quotation takes the form of things like $quot or $percnt, and an expression must be on a single line. Trying to do anything more than two levels deep quickly exceeds visual and mental capacity and becomes a nightmare to maintain. Now, you don’t need nested tags all the time to be certain, but I’ve needed them several times already, and I’m always thinking there should be a better way.

the planning application never got past prototype. I showed it to one of the program managers, but even I realized that a text based system wasn’t quite the right tool to replace a spreadsheet style application. I’m using it myself for task tracking and logging, but the other programmers don’t quite get it, and it is almost a personal application. I am using to provide the user interface forms for the REST service, sometimes doing page includes of multiple queries and other times just redirecting to the html output.

The planning prototype was nonetheless the inspiration for the web service. I started with a TWiki pre-installed on a linux virtual machine. I wanted to pull in a few database fields for the application, but the FoxPro drivers were windows only. So, the options were move to windows or make the web service. An entire web service seemed like overkill, so I took the windows option, first in a virtual machine (they are kind of handy), and then native because the windows virtual machine was dog-slow. Still, the wiki-odbc interface was mostly limited to a single SQL statement, while more complicated calculations lay locked up in our reporting application. So the web service stayed on my mind, and has since been born.

Posted Sunday, March 4th, 2007 under Review.


Comments are closed.