[Usability] "Correct" Windows, KDE button order? (was: Re: alternative button order: Why don't we auto-guess the alternative order by default if appropriate?)

[Christian Neumair <chris gnome-de org>]

Am Freitag, den 05.01.2007, 14:51 +0100 schrieb Sven Neumann:
> Hi,
> 
> On Fri, 2007-01-05 at 14:25 +0100, Christian Neumair wrote:
> 
> > I'm mainly asking because in 99% of the cases one wants the alternative
> > order to be reverse from the original order
> 
> I haven't found a definitive source for this, but as far as I know, your
> assumption breaks as soon as a third button is added. Then the typical
> alternative order is not the reverse of the original one. See this
> example:
> 
>  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].

Unfortunately, KDE seems to have yet another policy according to their
developer pages [2]. It is not really a policy, but a traditional order:

  Help,Default,User3,User2,User1,Ok,Apply|Try,Cancel|Close

i.e. we would have OK/Apply/Cancel, which is totally inconsistent with
Windows. The KDE 3 HIG [3] doesn't even seem to mention button order and
just gives some samples that match the pattern noted above.

The current drafts of the KDE 4 guidelines [4] ("current" according to
the KDE usability/HIG project [5]) seem to be offline so I don't know
what the current drafts propose for KDE 4.

I've CCed the KDE [6] and GNOME [7] usability lists to get some more
feedback on this. I'm aware that this is an ugly cross-posting, sorry.


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 general, in case of two options, the cancellation button seems to be
located on the right of the confirmation button for both KDE and
Windows, and on the left of the confirmation button for GNOME, and if
this is correctly specified in the whitelists it should work for the
common cases at least. 

Proposed KDE whitelist (left): Help,Default,Revert
Proposed KDE whitelist (right): Ok,Apply,Cancel,Close

Proposed Windows whitelist (left): Help,Default,Revert
Proposed Windows whitelist (right): Ok,Cancel,Close,Apply

Note that Help would always be left-aligned while Default and Revert
would just be displayed on the left of user-added buttons.

Other buttons would go to the center, with the button order "swapped" in
KDE/Windows, i.e.
  [ No ] [ Yes ] (GNOME)
would be displayed as
  [ Yes ] [ No ]  (KDE, Windows)
and other odd setups like
  [ Cancel] [ No ] [ Yes ] (GNOME)
would be displayed as
  [ Yes ] [ No ] [ Cancel ] (KDE, Windows)

[1] http://msdn2.microsoft.com/en-gb/library/ms673346.aspx
[2]
http://developer.kde.org/documentation/books/kde-2.0-development/ch08lev1sec5.html
[3]
http://developer.kde.org/documentation/standards/kde/style/dialogs/index.html
[4] http://www.kde.org/areas/guidelines/html/
[5] http://openusability.org/projects/kde-hig/
[6] https://mail.kde.org/mailman/listinfo/kde-usability
[7] http://mail.gnome.org/mailman/listinfo/usability

-- 
Christian Neumair <chris gnome-de org>

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list