I HAZ TEH HOBBIES?

To sequel some of my other "soul-searching" posts (a series which really needs to end), I'm starting to think that having my "own" wiki is a good idea. I don't mean a mindmapping application like DEVONthink, which seems to trade "information overload" with "UI overload" but, rather, just a "collection" of "finished" data. I'm familiar with running my own wikis, my first being the interactive hypertext of Ghyll back in 2004. Since then I've started about five or six other wikis, only two of which actually became public. That's far too many wikis, and the cause is evident from my earlier writings:

Part of my problem may be because I try to make everything a "project", something that I would be proud of "releasing". That perfectionist mentality got me to where I am today but, back then I had a lot more free time.

[Wikis don't] require six months of planning for the next "feature" or the next "version" - it just requires little trickles, each week, applying continuous torture to the rocks that line its shores. You never notice a rock being rounded - you only appreciate the patience it took to get there. I'd much rather be trickling at creation than treading water with maintenance.

The above mentality left me with lots of little wikis sprinkled all over my hard drive, all nicely done but all devoid of a respectable amount of content. I tried to make them "sites" versus "collections", a distinction which sbp recently highlighted in "Organizing Hypertexts":

A site is something which is organised to be a collection of strongly related material. I have sites, for example, about Strange Lights, Samuel Taylor Coleridge, and Emily Dickinson. A collection on the other hand is a heterogenous assortment of materials, such as a weblog.

The article, still a draft at this time, is nicely done. Funnily, I hadn't known about it before a conversation between sbp and I last night, in which the lamentations of the haters of technology concluded that I should merge all my efforts into a single wiki all about "me", called initially "The Morbipedia" and then finally "Disobiki". Naturally, I couldn't make it that "easy", and I spent a fair amount of time complaining about all the "problems" inherent in such a plan. This post is primarily to recognize them for historical effect.

Audience vs. Self

This is primarily a distilled version of the "project" problem: it seems that I require "proof" that I put forth effort into something (I find myself consciously NOT playing a game that does NOT have achievements) and this effort then needs to have an "audience" of some sort. This seems to be the root of why I try to make things "projects": a single site or section containing all the effort I put forth into one particular subject matter increases the chances of gathering a like-minded audience, which then "rewards" the effort I'm putting forth. Again, this has gotten me to where I am today (which is a good place), but I think it's actively harming the modern day Morbus in the modern day Internet.

Unbeknownst to me, sbp addresses this in his "Organizing Hypertexts":

The main problem with my articles is that I used to keep coming up with new sites, but the sites didn't last as long as the content. Instead of thinking about sites, it would be better to think about the enthusiasms themselves ... When you find an interesting weblog entry, do you often browse the directory index? In practice, when I find something it's usually because I'm interested in that specific thing, and only very rarely do I want to see other things written by the same author ... Rather than indices, then, one should strive if possible to follow the Wikipedia method of indexing. We should simply weave together the content as closely as possible.

I can't speak for anyone else, but the only sites I visit every day are services (Facebook, Twitter, etc.) - there's no one community, no one subject matter expert, that is visited more than once a week. When I find a result in a search, I bookmark the result for reading later, but rarely do I have any dedication to the parent site or author. One might occasionally get added to my feed reader, but there it loses all identity and becomes just another bit of scannable content.

I need to recognize that my enthusiasms are wide, varied, and too time-consuming for me to be an expert in any of them. Only boring people or specialized experts should be making new site subjects nowadays. Everyone else should be making collections of who they are and entwining their fascinations together, instead of forcing them alone into a corner.

Moments Vs. Revisions

If a weblog is a collection, then why should one need a wiki? I see the difference as moments vs. revisions: weblogs are not structured or finessed data but, rather, moments of raw time, emotion, and thought. Most folks treat their blog as a journal or diary, never revising previous entries (though occasionally ripping out pages). Wikis are all about revisions: write fast, edit often, and let time improve the coherence, all metrics which tend to encourage wikis to be about transferring facts. As a researcher and obsessive about his hobbies, with a compulsive desire to organize and learn everything there is to know, I've created wiki "sites" in the past, but I need instead to focus on a wiki "collection": letting all of "me" and my data swim in the same soup. I'm just interested in too many things to have a site for each of them. I don't have a room in my house for each interest, and every few years, the shelves and nooks of my office are reorganized with the latest lovey lovey kiss kiss. The front page of a wiki collection can function the same way.

In the initial draft of this post, this was labeled "Creativity Vs. Data", but I've used wikis in the past for creative writing and world building: the retention of previous revisions and ease of diffing, and the ability to quickly link things together, is important to how I tend to work. Most wikis allow you to link to things that don't exist and, more importantly, see all the other pages that link to that non-existence. That's a nice feature when it comes to linking plot lines together, remembering where you last mentioned "the crazy old lady", and so forth: it allows mind mapping without the interruption of the current thought.

Technology Vs. Soup

I'm (or was) a Drupal rockstar, so it seems obvious that I would use Drupal for this mind dump of my interests. With Drupal 7's built-in Field API, I can strictly define fields for all the content types I'd ever need (pulps, trading cards, films, comics, books, characters, etc.), and then enable revisions on them. I can define custom sidebars based on what you're looking at, code my own views and custom functionality, and use any of a zillion modules to make things awesome!

Or not: it all seems like too much work, and the argument becomes: should I use technology to tightly define what I'm doing (where the smallest bit of data becomes a single column in a massive relational database) or should I swim in the primordial soup, where all the data is in a single column, and what it means, how it's searched, and how it looks is handled as loosely as possible?

I don't have a clean answer for this, save that a wiki "feels" better than Drupal. Both Drupal and MediaWiki share the same feature set at a basic level: whereas Drupal defines database columns for new fields, MediaWiki "fields" can be defined as parameters in the Template: namespace. This same namespace handles the display of these parameters, just like Drupal's node--CONTENT_TYPE.tpl.php. MediaWiki Templates also double as a rough equivalent to Drupal's blocks. For all the complexity and power of Drupal's third party Views module, there's MediaWiki's third party DynamicPageList extension. In both apps, you can define what blocks or templates appear on a page. Fundamentally, they both can do the same things, but MediaWiki seems "looser": unless you install an extension, everything worth doing is done via a single textarea. This both reduces (no need to edit external theme files, no tabbing between multiple fields) and increases (crazy ass Template syntax, small differences in formatting) its complexity.

If MediaWiki is loosely coupled, then Drupal must be tightly coupled. This means that software or API changes create a barrier to maintenance: every Drupal upgrade I've ever performed (from version 4.5 onward) required revised or new custom code, and I often had to wait on third party maintainers to upgrade. Every MediaWiki upgrade I've ever performed (from 1.2) has taken fifteen minutes and no code changes. Since all the data is in a single unstructured bucket, there's not a lot that can harm it.

I'm not hating on Drupal: I still code with it every day, and it's still my tool of choice for applications that require custom functionality or perform more on a "service" level. For my raw data needs, for when I'm building a resource where appearance or permissions isn't an issue, MediaWiki seems stronger, faster, and more collaborative.

The Gameplan

The end result is that I think a personal wiki is a way forward for me. It solves my obsessive need to organize and notate my hobbies, satisfies a general desire to share my random effort publicly, and is loose enough that it doesn't seem overbearing or like "work". It is, in essence, a modern day version of my detergent directory which, as far back as 1997, was my collection of "experiments", "unknown ideas", and "one shots", before changing to just a file listing in late 2002.

I'll probably merge all the existing Detergent stuff into this new wiki, along with Video Underbelly and the other unpublished wikis on my drive. I think the greatest aspect is that there's no longer anything for me to "prove", which'll probably mean the wiki will end up being a great mass of chaos with barely a hint of quality. You know, like the Internet.