Blogs and the problem of indexes
The other day I did something that I don't usually do; I wrote an entry that was an index to other entries. I don't normally create indexes to entries because they're an awkward fit for blog (style) writing; trying to write indexes raises a number of issues.
The first question is both straightforward and the core question: where do you put such indexes? Generally you have three options; the index can be the first entry in a series of entries, it can be the last entry in a series, or it can live outside your blog entries in some way. The first option requires you to repeatedly go back and revise the index entry (which makes it look more wiki-like than blog-like). The second option means that you have no index at all until the entire series is done, but at least you get a nice retrospective entry out of it. The third option requires a place to put it (one that may not exist) and potentially places it outside other features of your blog environment that you may want (for example, comments).
(I say that a non-blog place to put indexes may not exist because some captive blogging environments have no provisions for new non-blog pages at all; you have at best a few canned 'about' pages and the like, and everything else has to be part of your blog.)
Once you have an index page, somewhere, the next question is how you draw people's attention to it. There are two aspects of this. First, for real blog usability you really want individual entries in the series to link to the index page for the series; this lets someone who winds up one entry easily branch out to reading the others. Ideally these links would be created automatically and would go to the index and to the next and previous entries in the series (for series that have orderings, which many do).
(Manual creation of links is not so much error-prone as omission-prone. It may also require going back to edit entries, especially if you only realize that you should organize an index after the fact.)
The second aspect of this is drawing general attention to your indexes in a way that encourages people to use them to explore. In a sense indexes to a series of entries are a great way to condense and summarize your archives and thus should make exploration easier, but you need to get the indexes in front of people for that to work. I don't have any particularly good answer to this right now, although I can think of various approaches if you have a lot of time.
(Some blogs feature 'things I think you should read' indexes in their sidebar, but I consider those a special case. It's much easier to find a spot for one or two very important indexes than to figure out how to organize an unpredictable random number of them.)
(As I've noted a long time ago, one of things about blogs is that blog pages are only weakly connected to each other. These issues with indexes are one manifestation of this, because indexes are strong connections. So how do you add strong connections in on top of a weakly connected environment?)
On a side note, categories and tags are both kind of attempts to add low-effort indexes. I'm not convinced that they are a good match for the kind of situation with things like my Python metaclass index, partly because they are too generic in presentation.
Why I still have a custom-compiled Firefox
Not that long ago, I mentioned that I still use a custom-compiled version of Firefox and some people asked why I do it. I have a long history of compiling my own browsers, extending back to when the Mozilla browser was Mozilla instead of Firefox. Unfortunately, at this point I can't entirely remember why I started, but I do remember what the end result was.
(It may have been that Mozilla wasn't available as a system package at the time for Red Hat Linux (back when it was RHL instead of Fedora), or perhaps that the system packages were outdated due to the rapid pace of Mozilla development. This was during a time when Red Hat was doing minor update versions of RHL and thus trying to keep program versions relatively unchanged for a year or more.)
Starting from the early days, I piled on a variety of modifications and hacks. Some of them were simply differences between how Mozilla worked and how Netscape worked (I had a long history with Netscape and was very used to some aspects of its behavior), but others were bugfixes, font hacks, and strange alterations. For example, early versions of Mozilla did some strange and not necessarily desirable things with font mappings in X, and I overrode some of them and took others out. Since I wanted to be able to run Mozilla and Netscape at the same time, I believe that this is where I started customizing how the remote access works.
Over time, the need for most of these customizations and bugfixes dropped away (a bunch became obsolete when Firefox eliminated support for old style X fonts, for example). Today, the only necessary changes I make are my hacks to remote access and changing the Delete key act like the Backspace key in HTML content. I also fiddle the branding for obscure reasons.
(I used to have to hack things so that Backspace would scroll the page up the way control-space does, but Firefox added a preference for that. I care about this because Netscape used Backspace to scroll pages up and I have years of reflexes that I have carefully carried forward from the days when I used Netscape. Besides, control-spacebar is two keys and Backspace is just one.)
Just to show how crazy and recursive this gets, the reason I have to map Delete to Backspace in Firefox is that for reasons well beyond the scope of this entry I already swap Backspace and Delete on my keyboard; the Backspace key generates 'Delete' and vice versa. I believe that in the old days of Netscape both Backspace and Delete scrolled the text up, but I no longer have a runnable Netscape binary to check that with.
Sidebar: on keeping up with the main version of Firefox
Honestly it's not difficult. I build from the Firefox release source
repository, which changes only very infrequently and generally on a
predictable basis. Because Fedora is now generally shipping the current
version of Firefox, a Fedora Firefox package update makes a good prompt
for me to '
hg pull -u' the latest source repository update and do a
rebuild. And Fedora is basically certain to update for security issues,
which are the ones where I care most about being current.
(I'm generally not in a rush to update Firefox for functionality. If I wanted the latest and greatest bleeding edge Firefox I'd build from the beta repositories or the development source, but the days when I did that are now long over.)