Re: HIG Text Alignment [was Re: [Usability] Better look Re: (no subject)]
- From: Alan Horkan <horkana maths tcd ie>
- Cc: Gnome usability <usability gnome org>
- Subject: Re: HIG Text Alignment [was Re: [Usability] Better look Re: (no subject)]
- Date: Thu, 15 Dec 2005 13:53:01 +0000 (GMT)
On Thu, 15 Dec 2005, Matthew Paul Thomas wrote:
> On 14 Dec, 2005, at 12:01 PM, Alan Horkan wrote:
> > On Tue, 13 Dec 2005, Matthew Paul Thomas wrote:
> > ...
> >> Yes, currently the HIG says: "Left-align components and labels,
> >> unless all the labels in a group have very different lengths. If they
> >> do, right-align the labels instead, to ensure that no controls end up
> >> too far away from their corresponding labels."
> > ...
> >> This encourages internal inconsistency, leftward imbalance, and
> >> columns of colons that almost line up but not quite. It's also an
> >> impractical guideline to follow, since you can't reasonably know how
> >> different the label lengths are going to be in every language your
> >> software is translated into, and translators can't specify the
> >> alignment themselves.
> > Surely internationalisation would mean the point about variable string
> > lengths could always be applicable if you wanted it to be.
> Sure, and I take advantage of that whenever designing Gnome-based
> software myself. But most developers don't realize the possibility; and
> it's bad form for guidelines to say "do X, except when Y" if p(Y) ≈ 1.
I agree but I see it more as a case for making less exceptions. Those who
do think an exception is absolutely necessary will still break the rules
but at least be more rigourous and properly justify their inconsistency.
> Recently I spotted a good example of why the Gnome guideline doesn't
> make sense -- ironically from Kontact in KDE. In Kontact's normal
> composition window, the header field labels are similar lengths, so
> left alignment looks nearly as good as right alignment would
> composer-normal.png>. But when you show more headers in the window,
Ick, buttons labelled "..." instead of "Browse..." but I digress.
Left alignment could work if you actually wanted it to, which as I said is
the problem with having exceptions to the guideline.
"Sent Mail" Folder could be shortened to "Sent Folder" (or FCC if you
want to be cryptic and old school and inflict acronyms on your users).
Since when was Dictionary a mail header?
Expanded mode yay as well expand To: CC: and BCC to Recipient, Carbon Copy
and Blind Carbon Copy, which would give more average text length.
Better use could be made of all the space in the drop downs, I might have
preferred to use the label Spelling and then had the Option "Ispell
Dictionary" which I think is a less ambiguous description.
> some of the labels suddenly become very far away from their fields,
> which looks awful
> composer-all.png>. And switching them from left to right alignment
> depending on the presence of *other* headers would also be silly. Using
> right alignment consistently avoids this problem.
I disagree and the lines are pretty clear and balanced, I dont think it is
too difficult to scan any more than it would be too read a
sentece with extra spaces in it.
> > The important issue is making sure the association of labels and the
> > control is clear. For accessibility this also needs to done
> > programmatically anyway so perhaps there is some better way than
> > alignment to better show this association to all users?
> I don't think there needs to be, if colon alignment works fine.
If, but I strongly believe the improved readability of Right alignment is
vastly better than colon (effectively left) alignment.
Having said that in the particular cases I was using I was most interested
in being able to easily scan the list of available options, only use a
few of them, and the size of the various strings didn't vary too much.
I think readability is extremely important, and the best dialogs are
usually ones which closely follow the flow of how one would read a page of
text, left to right, line by line.
> > (Some kind of visual cue, prelighting, clickign on the text label
> > would do something to the associated control I dont know maybe
> > something like that.)
> > ...
> I would much rather that clicking on a text label (not counting the
> text for a checkbox, radiobutton, or expander) began a drag to move the
> window, just like clicking in any other non-interactive part of the
> window ... But that's another story.
If you hold down Alt then it already does, at least in Metacity. (I
wonder if anyone uses SawFish anymore?)
] [Thread Prev