I’ve been thinking about blogging tool usability again. There are various aspects to usability and blogging, including writing, site-mechanics, publishing, installing, customization, and managing publishable stuff. I maintain a few sites using Blosxom, and it’s the wrong tool for the job — though it does gets many things right.

A problem I’ve been having is that it’s difficult to see what the better system should be. There are features that the tools lack that would be useful, and features the tools have that I don’t care about. All the blogging tools I’ve used so far have a common problem: each make at least one part of the process of writing and publishing annoying enough to get in the way of expression.

Some blogging tools, for example, take too long for recording simple ideas, or don’t have a useful way of storing them. Other tools make it difficult to produce more than one form of output. Sometimes it just takes too long to get the tool out, record the idea, and publish it. The limitations result in avoidance, at least some of the time.

Actually I think I do know what I want, but it’s not clear how it will work. I’m reading a Bradbury book on writing fiction, and he mentions that he writes about things better when he’s not thinking about them specifically. For example, he was in Ireland for a year writing a screenplay for Moby Dick, but didn’t write about Ireland in his stories for another 10 years — he let the details find his subconscious, and then his subconscious wrote the stories on its own terms.

How is this related? The details of a better blogging tool are in my head, but are still a bit jumbled up. I just have to let the ideas percolate until my subconscious orders them, filtering it all into something better. This is how I’ve always done design, it just happens that Bradbury uncovered the mechanics of it for me. Forced design is why a lot of software is bad, that and all the compromise added to it. Well, there are probably other reasons commercial software sucks, like honesty and integrity, but that’s not the point.

Bradbury also harps on the fact that he writes (and reads) endlessly, which is how he feeds his subconscious. He’s right: that’s how creativity works, it needs to be fed and cared for. I never realized it, but that’s how my design process works, as it’s really a creative force (versus a pedantic force). Pedantic may be the wrong word, but when designers attack a problem from the meticulous, anti-creative angle, the result is not cohesive — and is often forced beyond the workable.

So blogging is related to creativity, which is related to feeding the subconscious. Design is also related to creativity, and is better when it’s a product of the subconscious too, so a well-fed mind is a better design tool. The point? Writing about design, especially in a public forum, will result in better designs. I think mailing lists, email, IRC, are also great design tools, but blogging is a more intentional medium.

Writing about design is important. A design represented in a single specification will be weak, no matter how well written it is. A lone specification is a rare piece of writing by a designer, lumpy and awkward, passing meaning poorly to its readers. Designers need to write more, and they need to be read more on a topic before a good design can result.

So blogging is a design tool, and a writing tool, and a way to feed our subconscious. And this is why I’ve been having so much trouble describing the tool I want — it’s an important tool for me, for both writing and design (and I want to get it right). I know most of the things it should be, and some it shouldn’t, but they’re just memes floating in the primordial mist of my subconscious. Or at least they have been for the last few months.

Designing is a lot like writing fiction. There are characters, plots, subplots, and then the damned implementation (full of syntax, etc.). The symmetry and orthogonality of the writing is a critical part of the design, as a lack of balance results in a non-sensible work.

The problem with what exists is that they force the technical limitations of their design on the user. No, they /impose/ limitations on the writer making writing difficult. This is where magical markup can help, except that markup of any sort is a geek medium. That might be OK, as writers have to be aware of some details of publishing (just like they understand the pedantic details of language syntax), but the features can’t get in their way. Writing is an ethereal experience, a private, sacred experience between a person and the page. A writing tool needs to respect this experience, and understand where the tool fits in perspective.

Blosxom has some pure goals: plain-text, minimal-configuration, minimal-dependencies, and an intelligently-simple category system. But, the approach is all wrong for writing, as the minimalism forces the writer to weave and dodge the prickly design limitations while writing and publishing. The goal of the Blosxom project, as far as I can tell, is a simple implementation — which results in some excellent usability points, but it also introduces several usability problems. So the goal has to be to make writing and publishing easy, and only after that can the design try to provide minimal design points.

One frustrating aspect of most tools is the forced understanding of client and server issues. Fog-creek’s blogging tool is one of the few that get this right. It has a simple client interface, and makes the process of writing, and the details of publishing fairly simple to understand. The result is a static-rendered site, based on a local tree of documents and other resources. I don’t think that static-rendering is a hard-requirement, but the workings of client-server, and how a web server serves cannot dominate the tool.

Templating and configuration need to be useful, but also cannot overpower the tool. MoveableType is an attractive tool that has great templating, but the writing interface is terrible. Publishing in the tool is complicated, and there is no site-preview mechanism. All of the waiting (client/server) is shit, as it gets in the way of writing.

The user has to be able to choose their writing tools. The writing interface is probably the most important part of a blogging tool, despite being distant from the end-result. I’d love to build the perfect editor, but trying to do both in a blogging tool is retarded. This hints to me that the tool needs to have an API for posting (luckily there are several existing ones), and that the client-side needs to be an exoskeleton, connecting to various tools to a hub of publishing functionality.

Plain-text is a kindly-agnostic form for storing articles, but I think that a number of formats should be supported, just as a number of writing tools should be supported. Databases are not a good fit for storing documents either, despite how handy they are from a development point of view. Data is held captive by databases and data formats, which is an imposition of design and implementation details on the writer using the tool.

The tool also has to observe the writing-modes authors go through, and provide ways to make the tasks easier. Modes like writing versus publishing, versus drafts, versus preview, versus configuration, versus templating — these are all parts of the process, but they can’t inflict complication on the primary use of the tool. There has to be a balance in the way the modes are exposed, so that each are never too far away, and yet they never cloud the task at hand.

The mantra for my dream blogging tool is to empathize with the writer, and the publisher-part of the writer’s life. Developing a simple tool, technology-wise, is good for adoption, but can’t be the primary goal. The tool needs to avoid back-end rot too, and has to expose the writings in an immediate, and easily accessible manner.