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

[Jacob Beauregard <jake13jake comcast net>]

In my opinion, the logical way to order things is to have them weighted 
by use, most used being the furthest right. There is a psychological 
explanation for that. Also, affirmatives should always be directly left 
of their negative counterparts.

Will anyone shoot me for not paying attention to what anyone does, or do 
I actually have merit in what I say? I don't know!!!!!!!

Christian Neumair wrote:
> 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
>
>