© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
If the design team is on the ball, they should recognize that the position of the buttons is not arbitrary, to be changed on a mere whim, or the observation that not all window system do it the same way give one license to place them wherever they please. Moving the buttons to the left because there may be other interesting things to do with the space appears equally arbitrary unless the proponent can suggest something concrete to do on the right with all that empty space.
There are logical reasons for placement of the controls. For example, the controls can suggest a hierarchy of controls where controls on the left (and top) have more dramatic effects (such as closing the window) than controls on the right (or bottom) (Menu items). Posters in this thread have observed that left-to-right readers see controls on the left before the right. Internationaliz
Consistency of use interface is extremely important, and a late chance of this type is going to lead to an enormous number of applications that don't follow such a late-breaking trend - it would have been, and still could be, much more orderly to make the button positions set in a gconf-string as in a theme, also have a similar effect on applications - thus the applications can be altered first to make them consistent with a dynamic theme setting - then changing the theme makes all the applications stay consistent.
There are more subtle choices to be made in the user interface that should be made in conjunction with such a change. GUI's have struggled with scroll-bar placement over the years (left-scroll-bar vs right-scroll bar). I make the personal observation that my mouse position tends to gravitate toward the right because of the right-scroll-bar, and making the scroll-bar position match up with the window-manager controls would further reduce eye and mouse motion. Minimizing large motion is important because Fitt's Law (which has been frequently misused in the discussion above) suggests that it take extra time to make a precise positional move when the initial motion is large.
Personally, I'd be fine with having the window buttons on the left, but I'd rate the importance of having the close button in the corner very high, and I think it's also extremely important that these choices should be made consistent with the applications. If the applications can't be altered to be fully consistent with the UI change in time for the release, the best solution is not to change at this time. As to Mark S's comment that there's something interesting to do with the space, I fail to understand how that motivates the placement of the buttons so much as perhaps aligning the title to the left, so that the empty space can be coalesced into one region,
One additional note I would make is that unlike other user interface elements in the GUI, the window-manager elements do not self-identify when one hovers over them (eg "Close" "Minimize" "Maximize"). Especially when the appearance and location of these elements change, making them self-identify with hover is key to making the transition easier between inconsistent GUIs.
Finally, when I worked at NeXT, there were similar observations to be made about the placement of objects in the window system. Application menus came up on the left, and the Dock was on the right, so interacting with multiple applications made one's arm tired really fast. When I tried to give reasoned comments on how the placement could be improved, I was "politely" reminded that Steve liked it the way it was and that it wasn't going to be changed by mere reasoning. I'm sorry to see Apple's management style to be as slavishly emulated as their button placement.