I have quite a few small text files lying around, containing everything from to-do lists to shopping lists to code snippets to small howto’s. Now, instead of having all those text files floating around as regular files, nine months ago I decided to move them into a locally stored, for security reasons, personal wiki.
Among the good wiki engines out there (most notably MediaWiki, MoinMoin, and FlexWiki), I went with FlexWiki, because it being asp.net based means that all the software required for a basic configuration ships with Windows. In addition, FlexWiki’s provider-based storage model lets you store pages in an MS SQL server, if you want to.
My incentive for going the wiki way was that I expected my documents to become more structured when making use of the typical wiki-like features …
Documents are automatically linked together.
I found my pages to be fairly independent, so hyperlinks are almost never present.
All modifications are recoded.
Versioning isn’t really that big an issue, because I usually add contents to the end of a page rather than changing existing contents, and for pages such as a shopping list, I don’t really need versioning.
More sophisticating layout capabilities.
Although I occasionally created a table and used colors, generally I can do with simple formatting. For those few cases where I can’t, a Word document is in place, since it’s equally well indexed by MS or Google desktop search engines.
… but most of the time, I didn’t make use of the features FlexWiki provided over text files. So, if you also factor in the disadvantages …
Extra infrastructure required.
Web server, and possibly an SQL server, is a must-have-installed. Also, you probably need to figure out how to configure the web server so you don’t share your live with the world.
Browser required for page edit.
After launching the browser, you must navigate to the wiki page, which may add considerable overhead for quick edits as opposed to simply double clicking a text file from within Explorer.
Lacking WYSIWYG support.
With FlexWiki, editing a page is a two-step process. First you write content in a markup language. Then you click “Save” and the browser switches to display view, where your markup is converted to html. Now, if the result is not what you expected, you have to repeat the cycle.
Build-in search less powerful than desktop search engines.
If you use the file system for storing wiki pages then the pages are also searchable by desktop search engines. However, if you opt for MS SQL storage, you have to rely on the build-in search capabilities of the wiki to find pages.
Backup is more involved.
Backing up and restoring a database is more complicated than copying a directory.
… I’ve decided that the wiki doesn’t cut it for me: simply because there is less overhead associated with editing text or even Word documents and because with desktop search engines I retain most of the properties I need.
This doesn’t mean that a wikis aren’t suited for maintaining a corpus of personal information; just that the corpus should serve a different purpose to make better use of wiki features.