On Jan 6, 2007, at 4:13 AM, Christian Neumair wrote:
Am Freitag, den 05.01.2007, 14:51 +0100 schrieb Sven Neumann:
...
standard: [Reset] [Cancel] [OK]
alternative: [Reset] [OK] [Cancel]
I might be totally wrong here, but that's how we are arranging the
buttons based on feedback from Windows users.
I must admit that I also have no clue what the correct order is.
I consulted MSDN but I couldn't find any interesting/relevant documents
listing non-standard buttons, except some OK/Cancel/Apply examples [1].
The button order for dialogs in Windows Vista is described in the
Dialog Boxes chapter of the Vista UX Guidelines
http://msdn2.microsoft.com/en-us/library/aa511268.aspx#commitButtons:
* Present the commit buttons in the following order:
1. OK/[Do it]/Yes
2. [Don't do it]/No
3. Cancel
4. Apply (if present)
5. Help (if present)
* If you have many related commit buttons, consolidate them using
split buttons.
* Have a clear separation from commit buttons (which close the
window) and all other command buttons (such as Advanced).
The guidelines also specify that the tab order for these buttons should
often be different from their visual order: the tab order can be
summarized as in order of frequency, but with Cancel always last.
http://msdn2.microsoft.com/en-us/library/aa511268.aspx#interaction
...
So it looks like we should be able to adapt to the major desktop
environments. Regarding the implementation of this in GTK+, we could do
the following:
We might eventually end up with optionally keeping around a whitelist
of buttons to put on the very right and the very left in very a
specific order, which we might store as an XSetting or widget style.
Yes/No dialogs, or other dialogs that don't have exclusively buttons on
the whitelists could be dealt with by additionally reversing the
remaining buttons iff gtk-alternative-button is present.
In Windows, using Yes/No dialogs is allowed: you can purposely use
generic commit button labels to force users to read the main
instructions and prevent hasty decisions. In Gnome and Mac OS, Yes/No
dialogs should not be used, though their respective guidelines don't
make this as explicit as they could.
...
Proposed Windows whitelist (left): Help,Default,Revert
...
As quoted above, the Vista guidelines put Help rightmost, not leftmost.
If you're still game to attempt portability with Windows, remember that
Windows Vista introduces some new challenges:
* Secondary commands and navigation to other windows should often be
links above the commit buttons, not commit buttons themselves.
* Display of help should be available from a link under the commit
buttons, not from a commit button itself.
* Button labels should use sentence case, not title case as used in
other platforms (and earlier versions of Windows).
So if GTK (or Qt) are to handle this automatically they need to know,
for each button:
* whether it is (a) a primary command, (b) navigation or a secondary
command, or (c) access to help;
* if it is a secondary command or access to help, what its link label
should be (because link labels should be more longer and more
descriptive than equivalent button labels);
* if it is a primary command, which of its words are capitalized
because they are proper nouns (so that the label can be converted to
sentence case without accidentally decapitalizing proper nouns);
* if it is a primary command, a numeric value representing its
frequency of use, so that tab order can be assigned appropriately.
Have fun. ;-)
--
Matthew Paul Thomas
http://mpt.net.nz/
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list
