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

Sorry, but if I'm going to read a book about user interface design,
it will definitely be the Macintosh user interface guidelines and not
Microsoft's one.

After all, _this_ specific thing is again a matter of personal taste,
let it be Apple's or Microsoft's. "The" way to do it simply does not exist
(at least here)

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

Stuff like that is easily doable with Gtk and keyboard shortcuts are of course
a good idea. We are close to a release and it's unfortunately too late for
any fuctionality changes.

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

Haha, you wonder why you get personally addressed flame email?

I don't wonder,

Reply via email to