<timecop@xxxxxxxxxxx> writes: > 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, --Mitch
