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