comment 1
> (Which also means we should probably put "OK" rightmost in all dialogs
> to match the order given in the "ESC/Enter" scheme)
comment 2
> I vastly prefer the "positive choice to the left" rule - of dialog
> button ordering, but can't seem to find any backing material right
> now... <snip> and seeing the most positive choice first when reading
> somehow feels a lot more natural than having to skip over the (more
> seldom used) cancel/negative buttons.
1) I would have to disagree with this one. Maybe it's just me but I have
yet to see a program that follows this kind of arrangement. If you have
it, I would like to see screenshots, or better yet videos of users going
nuts trying to use it.
2) Indeed, the "left to right" "most positive choice first" is documented
in the book that probably none of you want read called "Designing User
Interfaces" published by none other than "Microsoft Press". In the same
book it also mentions things like default dialog border width, button
placement, control grouping by similar function, keyboard shortcuts (yes,
them again) for each control on a dialog box, intuitive tab order to jump
between controls, etc. Again, most of these things are usually shrugged
off a "useless fluff" by most people that only care about what
"they" like. Unfortunately I demonstrated a bad version of this in my
first email where I made it sound like all of these issues are "my
PERSONAL" issues, rather than making it sound like these are "important
usability improvements" for everyone in general. Again, as I mentioned
before, adding underline keyboard shortcuts to items on a dialog would
require writing extra code, and a lot of it, especially for situations
where you have a label and a text entry box, where you would naturally
assign a shortcut key to the label, but pressing it would send the cursor
into the entry field:
_Label: [ entry ]
Since these two things are separate controls, my
uneducated-only-knows-0.01% GTK guess would be that a handler would have
to be attached to the dialog box or to the label control to set the focus
to the entry control when "L" or Alt-L is pressed at any position inside
the dialog. Note, if you are already inside another text entry, obviously
the only choice would be Alt-L since pressing "L" would just type in that
entry. That could theoreticaly lead to some ugly code that again, would
be considered "useless fluff since I don't use it".
Again, if general usaibility, rather than a particular developer's own
preferences were used when creating tools such as The Gimp, then maybe I
would not be trying so hard to explain these issues right now, and getting
tons of personally-addressed flame email about it. :(
tc
--
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
timecop at japan.co.jp | ＯＡ通信サビース株式会社 | NTT DoCoMo
I thought everything that Linus Torvalds is involved with was divine
perfection? Must be a problem with NEC and Sony -about Crusoe recall
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
