GNOME Bugzilla – Bug 86084
Titlebar's buttons placement are not the way usability proposals describe it should be
Last modified: 2004-12-22 21:47:04 UTC
Description of Problem: Titlebar's buttons placement are not the way usability proposals describe it should be, as is described in this url: http://developer.gnome.org/projects/gup/proposals/sawfish.html In short the orden of buttons proposed is (from left to right): [minimize][maximize][menu] (icon) Title [close] Additional Information: I've made a patch to change the buttons order. and other minor bug.
Created attachment 9363 [details] [review] change the order of the buttons in metacity to be more usable
FWIW, the proposal doesn't include a menu button. This is based on a few principals: (a) There are already buttons for close, minimize, and maximize, as well as the ability to shade by double clicking the titlebar (somewhat logical since it draws windows up into the titlebar), so you can access them via that convenient method (b) The rest of the menu items involve multiple workspaces and things that a first time computer user isn't going to need to know about, and can live without - if they never discover them, they can still use the computer just fine (c) you can already obtain a menu by right clicking on a titlebar (I don't have metacity in front of me right now, but I believe you can, and you certainly should be able to - but not by right clicking on buttons, as those are button controls on the titlebar, not the titlebar itself) (d) right clicking is easier than going over to a button for the same effect, and per point (b) users who do not know about right-click menus don't need to care Anyway... With a menu button, the order would be: [menu][min][max] (icon) Title [X] not [min][max][menu]... because then all the buttons are in consistent places, i.e. non-resizable windows will not have [max] but can still have [menu] and [min] - if menu was on the inside, it would move - and we don't like buttons moving if possible. [menu][min][max] (icon) Title [close] works and almost certainly will not move buttons around. It's also the MS order with [min] and [max] shifted to the left side, though I wasn't thinking of that when I made the order. I still say that [menu] should go, though.
I know that using the MS Windows button order per default is to make Windows users feel more comfortable. I must say though, this bug has been in the UI hall of shame for years, and even a lot of Windows users I talk to complain about this all the time. I showed one of my Windows-using friends a shot of Klarth a while back, and her first comment (without me mentioning a word of UI stuff) was "Great! You moved the close button away from the others! I *hate* closing my windows by accident, I do it all the time!" I've switched button orders several times - it typically takes me a few hours to adjust. I imagine a day or two tops is reasonable. In the long run, it makes it a lot nicer though. I just got a Mac OS X box, where Close is by the other buttons, and when I don't mis-click it (especially due to trackpads and other pointing devices that make it easy to slip), I worry about hitting it by mistake. I think that a few hours or even a few days to adjust to something new to make the environment much nicer and less error-prone in the long run is well worth it. In the big picture, GNOME desktops are certainly not at all like Windows, and the user is already going to be adjusting to a lot of things. This is one of the more trivial ones - I've already adjusted to the MacOS X frame (which I never use under GNU/Linux) in a day, but trying to use different applications is really killing me. I'm not saying that everything should be like Windows to make it easier to transition; rather, if we're going to be significantly different, a small short-term adjustment here is in the noise during a transition.
I can repatch teme.c again, to be more with Kenny Graunke first post. But I wonder if I should use: [menu][min][max] (icon) Title [close] or: [min][max] (icon) Title [close] letting the [menu] to the rigth mouse click. in the meantime i will go with the first option because it will break less themes around. but i can patch it to delete the [menu] (not knowing if it will break othrs things in the meantime ...
There's already an open bug to make this configurable I think. I don't currently plan to change the default however; similarity to Windows is just more important IMHO.
Created attachment 9370 [details] [review] a new patch to get a [menu][min][max] Title Text [close] title bar
I am not the maintainer or a developer of Metacity, but IMHO is more importatnt the usability, correctness and eassy of use of the gnome interface over MS Windows look alike. just my 2cts
HP: can the button order be made themable. Doing this would eliminated un- needed preferences (a preference for button order would be kind of cracky), while allowing theme authors to define the button ordering (for example a aqua theme could change the button ordering to resemble that of the mac). Imho this is the cleanest way to implement this from a ui perspective. Also I agree with HP that by default we should probably use the ms button ordering at least until there is a discussion and consensus reached on the desktop-devel and usability lists of what the correct ordering should be in the future.
I think that making the buttoms placement themable is a good thing to do, but it has the problem that it will break the themes that already exist. In my spare time in the next week or so I will hack the theme engine to add this feature.
Obvious solution is to make the current button ordering the default but allow themes to overide it via an extension in theming file.
No, I don't want it in the theme. That means that users innocently changing their theme may confuse the heck out of themselves by ending up with a different button order. Instead I plan to change the theme format so that the buttons are drawn in two components, one position-based and one function-based. That is, the theme author can provide instructions on how to draw a button in a given location (left-left,left-middle,left-right,right-right,right-middle,right-left), and also how to draw a given function (close, maximize). Usually you would draw the button background according to position, and the button icon according to function. There can be more than one left-middle/right-middle button drawn. i.e. on each corner of the window you have 0-1 buttons on the left, 0-N buttons in the middle, and 0-1 buttons on the right.
I'm marking this a dup of bug 83129 at this point; please reopen if anyone objects. *** This bug has been marked as a duplicate of 83129 ***