Re: [Usability] "Correct" Windows, KDE button order?

[Matthew Paul Thomas <mpt myrealbox com>]

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/