Wandering Thoughts archives

The clash between wikis and blogging

Suppose, as Phil Hollenback does, that you blog with a simple wiki environment not by augmenting it with blog features but by outsourcing the chronological navigation to Twitter, Facebook, and the other social networking environments where many of your readers probably already are. After all of this, is there any real difference between writing a blog and writing wiki articles?

My answer is yes.

(A disclaimer: this is a philosophical digression from what I believe that Phil Hollenback is doing, which is more or less using a simple wiki as a blog datastore. I think that that's sort of a neat hack that leverages social websites in an interesting lazy way, although I think it has drawbacks for getting people to explore your blog once they've landed on it once.)

At its heart, blogging is fundamentally a mindset, an approach to writing of 'write it and move on', of putting major corrections and updates in another entry (or very prominently marked in the original entry). This is fundamentally incompatible with the wiki approach to writing, where a wiki page is a living document that may be revised continuously.

Blog entries are mostly frozen once published not because of technical requirements but by social convention. Well, 'social convention' is too mild, because in the large blogs are conversations (even if no one ever replies out loud, you are in a dialog with your readers) and it's extremely hard to have a sensible conversation if someone is constantly revising what they said.

If you present something as a blog people will react to it as a blog, including expecting these social conventions. If you then approach it as a wiki and revise things out from underneath your readers, they will get angry because your revisions destroyed their commentary (and probably made them look stupid) by removing what they were commenting on. 'Commentary' here is more than actual comments on your entry, it's also things like their own blog posts in reaction to yours.

(I have written about this before from a different perspective, here.)

This is kind of abstract, so let me make it concrete with an example; as it happens I have a good one handy. Yesterday's entry is about a quite useful way to list file locks on a Solaris fileserver, and adds some additional information to an earlier entry from 2009. This is perfectly sensible in a blog, and perfectly insane in a wiki; in a wiki, I would have a single article on 'listing file locks on Solaris' and I would have just augmented it with the new information.

Wikis are not a simple solution for blogging

My Referer logs recently led me to a Stackoverflow question where I read philiph's reply:

I'm a big fan of using a simple wiki engine like PmWiki as a blogging platform. See for example how Chris Siebenmann does it.

I'm afraid I have to disagree here.

DWiki (the wiki engine behind WanderingThoughts) is not a simple wiki engine. In fact, there is no such thing as a simple wiki engine that is a good blogging platform or even an average one. What wikis do is sufficiently far from what you need in a blog that no wiki that is also a blog engine can be described as 'simple' any more.

Fundamentally this is because wikis and blogs present information in quite different ways; they look similar only when you're looking at individual entry pages and you don't think about comments. Past that, a blog engine needs all sorts of aggregation features that a simple wiki doesn't need and won't have. Classical wikis are simply not designed for 'group of pages' navigation, while blogs are all about aggregating pages together in various ways (primarily chronological, sometimes through subsets of your entries such as all entries in a category or with a given tag).

You can add all of these blog style presentation and navigation features to a wiki (DWiki is an existence proof) and it sort of looks simple when you start on this road. But having gone down it I can assure you that the resulting program winds up with a fair amount of code that exists only to support your blog interface; the simpler your original wiki, the more of the resulting program will be blog-specific.

(The features may nominally be generic in that they will work outside of the 'blog' environment of your wiki, but in practice you will have added them only to support the blog. This is certainly the case with a number of DWiki's nominally general features.)

Another significant difference is comments and possibly permissions to edit entries. The classical utterly simple wiki has no comments and anyone can edit entries; you're going to want to fix at least the latter. (As people have noted before, you don't have to have comments on a blog, but it's the usual expected approach and many blog authors want and like it.)

There are other things a blog has and a wiki doesn't (titles as important things, for example), but I think that this will do to make my point.

What would be nice for SSL is out-of-band certificate binding

One thing that creates the the SSL CA problem is that websites have no secure out of band mechanism for asserting what SSL certificates they use (or that should be accepted from them). With such out of band information, incorrectly issued SSL certificates wouldn't be a concern because they wouldn't work.

Well, 'secure' is an imprecise word here. The problem with SSL CAs is that they create a situation where SSL has multiple trust roots; in this situation your security is only as strong as the weakest trust root. Both available evidence and strong suspicions point to that being not much security if it's important enough to someone. So what you need is a system without multiple equivalent trust roots.

In theory DNSSEC could solve this problem, once it becomes pervasive. In practice there are both trust issues and significant operations issues that, I think, make it infeasible.

The trust issue is that DNSSEC doesn't give the browser clear and visible end to end security. With SSL CAs alone, the browser does all of the certificate validation itself; however, with DNSSEC, the security of the out of band information is probably at least partially in the hands of resolver libraries and local DNS caches.

The short form version of the operations issues are that this is extra work for no particular benefit (and so is unlikely to get done at all) and, more importantly, that DNS information doesn't update instantly. Slow DNS updates means that changing a service's SSL certificate requires much more lead time and planning; you have to start advertising the new certificate alongside the old one several days in advance, and then keep the old one for a day or two afterwards. With the current situation, you can change your SSL certificate with a configuration file update and maybe a daemon restart, and change it back just as easily.

An actual use for the CSS overflow property

I have written grumpy things about the limitations of the CSS overflow property a long time ago, but I've recently realized that it does have one actual use in an environment such as WanderingThoughts. And that is to deal with a problem I periodically have with comments.

The problem with comments on WanderingThoughts is that they can break the overall page layout. WT uses a table based layout, so an overly-long line in a comment forces the entire surrounding box to widen to contain it. The result creates a table with a huge width, causing the entry (and other comments) to also be absurdly wide and thus unreadable.

(I usually fix these page width busting comments with magic site admin powers.)

This is exactly the situation where CSS's overflow: scroll is the right answer (instead of the wrong one). The normal drawback of this setting is that it destroys readability, but here it is better to destroy the readability of a particular comment than to let it destroy the readability of all of the text, and the comment formatting isn't something that I control. This is a pretty unusual situation, although I suppose that it applies to anything with user-contributed content in constrained layouts.

(When you are writing main article text, the readability of your overflow: scroll content is presumably important for the text's overall readability (otherwise, why is the content there at all?), and you control the content so you can reformat it in ways that don't destroy your layout while still leaving it readable. And you should, for obvious reasons.)

PS: now that it is no longer 2006 (cf) I could solve much but not all of this problem by finally fixing my usual issue with <pre>. That still leaves lynx sort of out in the cold but increasingly I could live with that (especially just for comments).