Wandering Thoughts archives

Why you (probably) want to have blog categories (and topics and more)

It started with an Eevee tweet:

like does anyone actually care about blog categories, considering you can just skim the list of titles and get a pretty good idea

It turns out that I have opinions on this, perhaps unsurprisingly. My answer is 'yes', or at least potentially yes. In fact I think there are several different levels of things that you want to have in a fully featured blog system.

The pragmatic purpose of categories is to allow people to easily follow only a subset of your blog, both through syndication feeds and perhaps other mechanisms. The more disparate the subjects you cover in your blog, the more likely people are to want a way to follow a subset of it; conversely, if you already have a narrow focus there may be no point in trying to subdivide it. Here on Wandering Thoughts I definitely have feed readers fetching category feeds for several of my categories. Of course you can choose not to provide this sort of thing in the interest of broadening the minds of your readers, but this may well cost you readers.

(Some form of restricted scope feeds are also handy if you think you may someday want to feed selected entries to, say, a specific planet-style aggregator. The importance of this depends on how many of your entries would be irrelevant to a particular aggregator; for example, I'd definitely want a category for Go if I ever wanted to be part of a hypothetical 'Planet Go'.)

Relatively broad topics are there so that readers can easily find more of your writing on specific areas of interest to them. This is the domain of 'that entry on ZFS was useful, has she written more about it?', where a reader is expanding outwards from some initial entry they've landed on. My view is that topics are less predictable and more retrospective than categories; they sort of emerge organically from your writing as you find you've written a bunch about a specific area.

(You might as well provide syndication feeds for topics too if you can support it easily, but I think it's less important than with categories. Among other things, your writing on any particular topic may be extremely sporadic or even stop.)

Finally, I definitely feel that real blog usability means that you want some mechanism that will let you create a collection of direct and visible links for things like '(strongly) related entries', 'next/previous entry in this series of entries', and the like. I don't think tags (as conventionally implemented) are the right answer for this because they're not clear enough (I discussed this in my thoughts on tags for blog entries). These sort of strong relationships between entries are your best hooks for getting new visitors to read more, so you want them and their relevance to be clearly visible in ways that you wouldn't do for categories and topics.

(For instance, for 'next/previous in series' I think you should not just mention that here's where a reader finds more but also show the entry titles.)

I've wound up feeling that to the extent that you have tags as such, they're an implementation detail that may be used to create any or all of the above. This means that your tags may be namespaced into some structured namespaces, and tags in these namespaces may be presented separately from each other (and perhaps in different ways). The sorts of namespaces you want for tags may vary between different blogs, depending on what the blog is used to write about.

(For instance, consider a blog that's used to write about TV series. You're going to want a way to clearly tie all entries that cover a specific series together and you probably want it to be clear to readers and distinct from how they find all your writing about, say, one director or writer. So you probably want not just a big generic 'Tags: ...' thing that smashes all of these separate namespaces together but instead specific 'Series: ...' and so on, and then maybe a 'Tags: ...' as well.)

What creates a good wikitext dialect depends on how it's going to be used

One of the things I've learned over the course of writing DWiki and then using it here on Wandering Thoughts is that what makes a good wikitext is partly context dependent. In this case, 'context' means 'what sort of things the wiki is going to be used to write about'. This comes about because of two things; the rule that a good wikitext dialect doesn't get in your way, and the limited supply of special characters that we have available to use as markup characters. Good wikitext markup is short, distinctive, and uncommon in your regular text. And of course what is common and uncommon in your text can depend on what you're writing about.

There are two corollaries of this. The first is whether something is a good or bad wikitext dialect for you depends on what you're going to use it for. I feel strongly that there is no more or less universally good wikitext dialect (and probably won't be until we embrace the use of uncommon Unicode characters for markup). The second is that what looks like a good wikitext dialect can turn to bad (or at least 'not as good') if what you're going to use it for changes over time.

As I've mentioned before, a glaring example of this in DWikiText here is the _ character, which is used to create monospaced computer text. I originally created DWiki to write sysadmin documentation. This has the twin features that you frequently want to mark off literal computer input and output (conventionally set in monospaced) and _ is a relatively uncommon character in things like command lines and so on. Thus it seemed to make good sense to use _ as a short, unobtrusive, yet visually distinctive marker of such text. Then I took up blogging with DWiki and started writing about programming and code; of course _ is extremely common in identifiers, and this causes heartburn for both me and commentators (errant _'s is in fact one of the most common errors here and I've committed various hacks to try to sidestep them in common cases).

(This origin is also why bold is created with ~~ instead of the shorter single ~. Single ~'s occur periodically when you write about Unix paths. Also, looking backwards I have to admit that it turns out that there is a certain amount of sysadmin things that involve _'s, because people put them in file names, kernel parameters, and so on as word separators. Linux /proc is full of them, for example. This makes _ a somewhat worse choice than it seemed to me at the time, although I still don't know what I'd have used instead.)

(This is something that I've sort of written about before as parts of other entries but that I now think is important enough to give a full entry to, just to make it explicit and visible.)