2 May 2007 Ankh   » (Master)

I need to remember to check back often enough to see if people reply when I do talkback stuff. Hmm.

Tomorrow I take the train to the Libre Graphics meeting in Montreal. After that I'm off to the W3C Advisory Committee Meeting and then www2007 in Banff (near Calgary, not to be confused with Calvary)p>At both LGM and WWW2007 I'll be talking about what we're doing with XSL-FO 2.0. XSL is a way to format XML documents, for example for print or screen. There are two parts, XSLT and XSL-FO. We just published XSLT 2.0 this January (at the same time as XML Query, as they both build on XPath 2.0) and now we're working on XSL-FO 2.0. It's pretty exciting, as we're considering standardising a whole lot more sophisiticated layout stuff than things like CSS give you, much of it stuff that people have been doing for hundreds of years with print and that are understood pretty well. So I'll show some examples of the sorts of things we're thinking about, and talk about how people can get involved.

Csv, yes, it's a big improvement, but from the perspective of graphic design and typography (the user interface of text and communication, if you will) there are still (as always, it seems!) some improvements that could be made. The most obvious to me is that the counter box is not aligned with the other boxes, and alignment is lost elsewhere. I'd get rid of the "Options" heading since the entire dialogue box is about choosing options such as destination folder. I had a quick go at improving it, I hope you don't mind:

EOG save-as dialogue

It raises a HIG question that's been endlessly and uselessly debated... The alignment of the labels in dialogue boxes is always difficult, as there's no single approach that works in all situations. It's similar to the problem of designing a table of contents for a book.

The best guiding principle is of proximity: put related things nearer to each other than to other, unrelated things. For example, a section heading should be nearer to the text it heads than to the preceding section, something Web browsers by default tend to get badly wrong. So, the label should be strongly associated with the value in most cases.

Now, the values are encased in vast and unavoidably ugly boxes which are the most visible things in the design. So we try to turn an ugliness into a strength by aligning them all, to give strength to the design. But if the value boxes are aligned vertically and the labels need to be near them, in a left-to-right world our choices become putting the value to the right of the label, or right-aligning the labels. In a right-to-left environment obviously the choice is the same, but in the other direction.

Of course, other factors come into play. One is familiarity with badly designed dialogue boxes that are already out there. Since familiarity is the most significant factor in comprehension, this is very important, and may be enough of an argument in itself to make an ugly dialogue box that flies in the face of what we know about human perception, but works better because people are accustomed to it. The use of Fraktur typefaces in Germany might be counted as another example of this.

Another factor is whether the labels or the values are the primary items of interest to the user, and this of course varies depending on the dialogue, the user, the application, and also the user's familiarity with the dialogue. I love Alan Cooper's idea of designing for the "perpetual intermediate" and assuming that people are only vaguely familiar with the dialogue, if at all. In that case the ability to scan down quickly and relate labels and values is most important, leading again to the right-aligned version. But sometimes people need to compare labels, or the labels perhaps are sorted alphabetically in a large list, and then left-aligned labels would be best, with the values to the left of them. But the HIG and I disagree in this area I think.

Oh, I should mention that I'd be tempted to treat the filename preview differently, since presumably it might be arbitrarily long and not fit in the dialogue box, but I don't know enough about the possible forms they may take to give a good suggestion I think. or maybe the dialogue resizes as they grow.

dwmem2, you're missing something about GNOME I think. The idea is not to get rid of all configurability, but to get rid of useless configurability (e.g. whether the rate of acceleration of the panel when it auto-hides should be linear or quadratic). That is, remove useless features without impacting functionality, and to get to a point where most things work without needing to be configured.

How well GNOME is succeeding at this can be argued, not least because it's very subjective, but I see it as a big improvement, even though sometimes I miss configuration options that I used to enjoy :-).

Latest blog entries     Older blog entries

New Advogato Features

New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.

Keep up with the latest Advogato features by reading the Advogato status blog.

If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!