Wandering Thoughts archives

The limitation of templates for web design changes

Given that DWiki is template-based, in theory I could fix my comment form design mistake from yesterday. All I would have to do is revise the 'write a comment' template that's used here so that it included the entry and the existing comment, as well as a preview of your new comment and the comment entry form itself.

Except not so fast, because this revised version would be a usability disaster as I've described it. The problem is that all of the links to the 'write a comment' page have no fragment identifier right now, so they go to the top of the page.

When the top of the page was either the comment entry form or a preview of your comment, this was the right decision; you immediately see the important thing, what you clicked on the link for (or the 'preview entry' button). But if I just changed the template to put the existing entry text at the top of the page, well, that's what you'd see. This would be a terrible interface; you would click 'add comment' and get what looked like exactly the same web page unless and until you scrolled down (possibly quite a bit). Given that websites are often broken, I'd expect most people to immediately conclude that something had gone wrong in my comment process and give up on the spot. And if you persisted, you'd get to scroll down again every time you previewed your comment (which you have to do at least once).

(I generally assume that most would-be commentators are not all that strongly motivated.)

Fixing this is beyond the power of DWiki's templates. While I could easily add a fragment anchor point to the 'write comment' page, the links to the page are generated by hardcoded logic that lives outside the template system. I could go fix the logic too, but this level of redesign clearly requires me to step outside the template system.

(Plus, I'm not even sure if you can POST to a URL with a fragment identifier. Probably you can, but I'd have to look it up to be sure.)

I suspect that this is going to hold true for most template systems. If they automate things like form creation at all, they are likely to contain assumptions about the possible shapes of your design and thus limit your ability to change it radically. You can flesh out the skeleton in many ways, but how the joints move is going to show through sooner or later.

(I noticed this usability issue when I talked about this back when, but since I wasn't thinking about actually changing it it didn't occur to me that I couldn't do it inside DWiki's template system.)

A design mistake in my comments form

It's slowly become obvious to me that one of the mistakes with the 'add a comment' form here on WanderingThoughts is that it doesn't show you the entry and existing comments. I know, a while back I thought that this was a good idea, but I've changed my mind since then; it's a design mistake.

Why I know this is pretty simple; I base it on personal experience. Whenever I write a comment myself, I invariably wind up with two windows open, one showing the existing entry and comments and the other one for writing my new comment. And these are real windows, not tabs, because I need to see both the comment draft and the current entry plus comments at the same time, which means that they consume quite a lot of screen space.

If I find myself using a workaround all of the time, it's pretty strong evidence that the design is wrong. Good design doesn't need you to fix things for it, it just works. Conversely, the use of workarounds means that the design still has friction points left, places where it doesn't really work right and users have to fix it themselves. Clearly this aspect of my comment system falls into the latter category.

The friction imposed by this design might be worth it (or even desirable) if I had hordes of commentators who would otherwise quote things all the time, but I don't; if anything I have the opposite problem. That makes the friction an unnecessary annoyance and thus a design mistake.

One of the lessons I draw from this is that designs for high volume, high activity sites are not necessarily appropriate for low volume ones. In a way I knew that already, but it hadn't necessarily sunk in that this applied to inobvious things that seemed like good ideas when I first heard about them as well as to the obvious stuff that was clearly too complex for my modest needs.

(DWiki's comment system was not deliberately designed to not show the original page you were commenting on; it just happened to be the easiest way to set up the 'write a comment' template way back when. At the time I did this I didn't think it was important either way, and then later I came to think that it was a feature. Now it's clear to me that it's a mistake, one not justified by other needs.)

A clever blog anti-usability trick

Here is something that I have run into more than once. Through one of my various sources of links, I'll wind up somewhere reading an entry that is called '<interesting title>, part 1'. At the end of the entry, I'll decide that indeed, it was interesting, and I would like to see if any part 2 has been written yet. So I try to look around.

The best answer would be a 'next part' or 'related entries' link that pointed me straight to the next entry in the series. Failing that, blogs traditionally have a lot of internal navigation that lets people poke around; it's more time consuming and I might get lost in the archives (or discouraged), but if I'm interested I'll at least take a quick stab at looking for the part 2.

You can probably guess the punchline by now: several times, I couldn't even find a link to the main blog page, much less any useful topic or archive links. There was nothing that looks like a link and any of the usual places to hide one didn't work (it's common for the blog banner graphic to be a link to the main page, for example, but not in these cases). So much for seeing if there's a part 2; even if there is one hiding somewhere, it's not that interesting, not when the site evidently doesn't want me to find it.

If real blog usability is getting people who visit one of your entries to go on to read others, this is real blog anti-usability, making it hard or impossible for me to do that.

I am pretty sure that I've also seen this failing on websites that were article-based, not blogs per se. In an article oriented website this is an even weirder failure, because multi-part article series are not exactly uncommon; you'd think that the content management software and the editors would both be up to making it all work right. Blog software at least has the excuse that 'related entries' and similar features are not an immediately obvious need.

(This is especially striking when it happens on sites that carry ads. Here they are, passing up more pageviews and ad impressions that are basically theirs for the asking.)