The road to bad software is paved with good intentions.
In "what's my problem," I described why I wanted a web presence. Now it's time to explain my first attempt, why it failed, and why it still remains my ideal.
I was always interested in using computers to keep information organized. Back before the Web, I played with lisp code for Emacs, creating little hypercard-like modules that would let me link words in one file to other files. And once I'd discovered CGI scripting for the web, I often tried to figure out how to interact with web pages through a browser, but never had that breakthrough moment. I had to wait for Ward Cunningham to have it for me. A programmer with an engineering background, Cunningham invented the first wiki (which continues to thrive at c2). The instant I saw his solution, everything fell into place. It was without a doubt one of Those Moments in my intellectual life.
I began to experiment with all kinds of wikis: oddmuse, mediawiki, twiki, kwiki, moinmoin.... I was, one could say, rather promiscuous in those days. I was convinced that there was a way to make a wiki solve all my problems.
But no matter what wiki I tried, there was always something that chintzed me off - the look and feel was wrong, the editing shorthand was arcane, the API was obtuse, there weren't enough functions, there were too many functions, performance was sluggish.... It was incredibly frustrating because the more I worked with wikis, the more I became convinced they were The Right Answer, but I could never find The Right Answer For Me.
So I decided to write my own wiki engine. And thus was born xiki. I've been putzing around with xiki for years now. I even have a tiny bit of research funding to develop it as a tool for engineering designers. Xiki is written in perl, and is quite fast, faster than most other wikis I've tried. It has a syntax that is quite concise, compared to many other wikis. Of course, it's nowhere near as robust as most popular wikis, and I'm sure the code would make good perl programmers break into hysterical laughter. But it works well for me and my grad students.
Or so I thought.
Once I had the basics running, I started having big dreams about building into xiki all kinds of functions to help me handle my web presence. But as I started figuring out how to implement those big dreams, I started to discover problems in xiki.
For instance, it has a module to handle bibliographies in a reasonable and handy way. But it's really slow when you want to search a bibliography. Also, a xiki page is processed and then spat out right at the end. So xiki cannot build output a bit at a time. This is something most other wikis do, and for good reason. Even though it makes the software trickier to write and slower, it appears to run faster, because it starts producing some output much faster. That's one of those little tricks computers can play on the poor human mind. More practically, producing output a bit at a time does let one build pages in increments. These are things xiki just can't handle.
Adding event handling (like an appointment calendar), aggregating RSS feeds, and tagging interesting web sites are all things I want to add to xiki. But I can't - not at least with xiki as it is right now.
I ended up writing code that suffered exactly the same problem as every other wiki I'd tried - frustratingly close to what I needed, but not quite enough.
In the meantime, I still needed functionality and I couldn't wait for myself to get xiki right. So I started using other things. I use a web-based calendar system called Calcium to keep my work-day appointments. Calcium hits as close to the sweet-spot as it gets: it's dead simple to install and use, it's robust, it's flexible, and it lets others book appointments without needing accounts. This means my students can just book an appointment to see me whenever I'm free. As far as it goes, it's been a life-saver.
Another thing I'd been doing for years was accumulating links to interesting web sites. I had no idea what to do with these. I tried all kinds of social bookmarking software (like delicious, diigo, and twine), but they all suffered from the same problem: I could only browse by the labels with which I'd tagged web sites. This is a problem because sometimes (often, actually, I want to look things up by keywords that I hadn't thought of adding as tags. So I'd end up spending a lot of time browsing through many links without finding what I wanted - which rather defeats the whole point.
Also, as anyone knows who has been tagging things for any length of time, your tagging habits change with time. It happened to me. After months of tagging things, I found that the tags I'd used on my earliest links were somehow wrong. I tried to develop a taxonomy - a classification of tags - so that I'd have a usable set of rules to assign tags. But there was no way to develop a taxonomy that would cover all the tags I hadn't yet thought of. So the taxonomy kept changing... which rather defeats the purpose.
Then one day I realized that the reason I kept using so many tags is that I was trying to capture every keyword that appeared in the web site I was tagging. What I needed, I realized, was a way to tag web sites, and also index them (like Google or Yahoo do).
Of course, there was no software that did that. To this day, I still can't find anything that both tags and indexes web sites. So I wrote my own. The current incarnation of that software is called serf - and yes, it does look a bit like delicious. It uses a cool search engine library for Perl called KinoSearch. The neat part of serf is that it can search on either tags or keywords or both. Since most web pages have lots of good keywords in them, I need fewer tags. And also, those tags can be more consistent because they're more general - specific tags are just keywords, already in the index for that web page.
I still use, and develop, serf. But I wish xiki could have done it.
Serf may be working out well, but it's the only part of this sorry state of things. Xiki works fine as a plain wiki, but it needs serious help before it can replace any of the other tools I've become accustomed to.
Things finally came to a head a few months ago, when I realized I was spending more time pissing around with different bits of code and web apps than actually gathering information and using it for something. I realized I had to do something, because my productivity was shot. (Don't tell my boss.)
And being a designer, I decided I had to start designing a better answer. I'll write about that, next time.
In "what's my problem," I described why I wanted a web presence. Now it's time to explain my first attempt, why it failed, and why it still remains my ideal.
I was always interested in using computers to keep information organized. Back before the Web, I played with lisp code for Emacs, creating little hypercard-like modules that would let me link words in one file to other files. And once I'd discovered CGI scripting for the web, I often tried to figure out how to interact with web pages through a browser, but never had that breakthrough moment. I had to wait for Ward Cunningham to have it for me. A programmer with an engineering background, Cunningham invented the first wiki (which continues to thrive at c2). The instant I saw his solution, everything fell into place. It was without a doubt one of Those Moments in my intellectual life.
I began to experiment with all kinds of wikis: oddmuse, mediawiki, twiki, kwiki, moinmoin.... I was, one could say, rather promiscuous in those days. I was convinced that there was a way to make a wiki solve all my problems.
But no matter what wiki I tried, there was always something that chintzed me off - the look and feel was wrong, the editing shorthand was arcane, the API was obtuse, there weren't enough functions, there were too many functions, performance was sluggish.... It was incredibly frustrating because the more I worked with wikis, the more I became convinced they were The Right Answer, but I could never find The Right Answer For Me.
So I decided to write my own wiki engine. And thus was born xiki. I've been putzing around with xiki for years now. I even have a tiny bit of research funding to develop it as a tool for engineering designers. Xiki is written in perl, and is quite fast, faster than most other wikis I've tried. It has a syntax that is quite concise, compared to many other wikis. Of course, it's nowhere near as robust as most popular wikis, and I'm sure the code would make good perl programmers break into hysterical laughter. But it works well for me and my grad students.
Or so I thought.
Once I had the basics running, I started having big dreams about building into xiki all kinds of functions to help me handle my web presence. But as I started figuring out how to implement those big dreams, I started to discover problems in xiki.
For instance, it has a module to handle bibliographies in a reasonable and handy way. But it's really slow when you want to search a bibliography. Also, a xiki page is processed and then spat out right at the end. So xiki cannot build output a bit at a time. This is something most other wikis do, and for good reason. Even though it makes the software trickier to write and slower, it appears to run faster, because it starts producing some output much faster. That's one of those little tricks computers can play on the poor human mind. More practically, producing output a bit at a time does let one build pages in increments. These are things xiki just can't handle.
Adding event handling (like an appointment calendar), aggregating RSS feeds, and tagging interesting web sites are all things I want to add to xiki. But I can't - not at least with xiki as it is right now.
I ended up writing code that suffered exactly the same problem as every other wiki I'd tried - frustratingly close to what I needed, but not quite enough.
In the meantime, I still needed functionality and I couldn't wait for myself to get xiki right. So I started using other things. I use a web-based calendar system called Calcium to keep my work-day appointments. Calcium hits as close to the sweet-spot as it gets: it's dead simple to install and use, it's robust, it's flexible, and it lets others book appointments without needing accounts. This means my students can just book an appointment to see me whenever I'm free. As far as it goes, it's been a life-saver.
Another thing I'd been doing for years was accumulating links to interesting web sites. I had no idea what to do with these. I tried all kinds of social bookmarking software (like delicious, diigo, and twine), but they all suffered from the same problem: I could only browse by the labels with which I'd tagged web sites. This is a problem because sometimes (often, actually, I want to look things up by keywords that I hadn't thought of adding as tags. So I'd end up spending a lot of time browsing through many links without finding what I wanted - which rather defeats the whole point.
Also, as anyone knows who has been tagging things for any length of time, your tagging habits change with time. It happened to me. After months of tagging things, I found that the tags I'd used on my earliest links were somehow wrong. I tried to develop a taxonomy - a classification of tags - so that I'd have a usable set of rules to assign tags. But there was no way to develop a taxonomy that would cover all the tags I hadn't yet thought of. So the taxonomy kept changing... which rather defeats the purpose.
Then one day I realized that the reason I kept using so many tags is that I was trying to capture every keyword that appeared in the web site I was tagging. What I needed, I realized, was a way to tag web sites, and also index them (like Google or Yahoo do).
Of course, there was no software that did that. To this day, I still can't find anything that both tags and indexes web sites. So I wrote my own. The current incarnation of that software is called serf - and yes, it does look a bit like delicious. It uses a cool search engine library for Perl called KinoSearch. The neat part of serf is that it can search on either tags or keywords or both. Since most web pages have lots of good keywords in them, I need fewer tags. And also, those tags can be more consistent because they're more general - specific tags are just keywords, already in the index for that web page.
I still use, and develop, serf. But I wish xiki could have done it.
Serf may be working out well, but it's the only part of this sorry state of things. Xiki works fine as a plain wiki, but it needs serious help before it can replace any of the other tools I've become accustomed to.
Things finally came to a head a few months ago, when I realized I was spending more time pissing around with different bits of code and web apps than actually gathering information and using it for something. I realized I had to do something, because my productivity was shot. (Don't tell my boss.)
And being a designer, I decided I had to start designing a better answer. I'll write about that, next time.
COMMENTS