Chris's Wiki :: blog/web/TemplateLimitations

The limitation of templates for web design changes

August 25, 2010

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.)

Comments on this page:

From 120.20.25.168 at 2010-08-25 08:02:57:

There is only one solution. Discus, or Diqus or whatever the crap it's called. I hate that damn javascript thing, but at least I don't have to go through four pages to post a ocmment.

By Dan.Astoorian at 2010-08-25 12:53:38:

Hmmm. You've already previously observed that:

...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 you put the comment page and the existing entry on the same page, it seems fairly clear to me that you will generally end up having to scroll back and forth between the two. I predict that eventually you'll get tired of this and go back to having two windows open.

You may want to consider some alternatives, such as

giving the comment page a button to open a new window containing the original entry (this would probably require javascript); or

limiting the amount of real estate used by the original entry by putting it into a box with scrollbars.

By the way, if you do want to put both the original entry and the full comment on the same page, why not just put the original entry at the bottom of the page, rather than putting it at the top and trying to navigate past it using fragment anchors?

--Dan

From 141.84.9.6 at 2010-08-26 06:49:39:

I'm not even sure if you can POST to a URL with a fragment identifier.

Fragment identifiers are never sent to the server.

--chris2

By cks at 2010-08-26 08:30:55:

The question is what the client does if the POST target has a fragment identifier. What you'd like (in a situation like this) is for the client to POST to the fragment-less target, then scroll the resulting page to the fragment identifier. What you actually get is what I don't know; it could be anything from the client ignoring the fragment identifier to an explosion.

By Dan.Astoorian at 2010-08-26 09:41:13:

I'd be very surprised if fragment identifiers were handled differently for different methods, since it's really a property of the URI, not of the HTTP transaction. RFC3986 (which defines URI syntax, including fragments) makes no mention of HTTP methods.

It's pretty common for the result of a POST to be a "303 See Other" redirect (i.e., a URL to be fetched via GET), to avoid the client resubmitting the form upon reloading the page, but as far as I've seen, clients seem to preserve fragment identifiers across redirects as well.

Of course, DWiki doesn't redirect POSTs that way (at least not for comment previews), but if you were determined to use fragments and wanted a POST to land on a fragment anchor, and didn't want to rely on clients handling fragment identifiers for POSTs the same as GETs, you could presumably make the POST redirect to a GET to a URI with the fragment identifier (although I haven't actually tested that).

However, doing so would typically require saving information about the result of the POST request within the session, which is likely far more work than fixing whatever the original problem was.

--Dan

Written on 25 August 2010.

«	A design mistake in my comments form

A Windows moment on my laptop