Re: [mitch n] Tab order, OK/Cancel/Esc/Enter

[timecop]

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 ・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・