- Journal
- What's Up With Window Controls?
What's Up With Window Controls?
Submitted by DanRabbit on Sat, 11/26/2011 - 19:56It's the stuff of epic flame wars. "My button position is better than yours" surely gets the blood boiling. So let's take a second and talk window controls. What do they do, why do we have them, what order should we put them in, and on what side of the screen.
What do we have here...
I think we’re all familiar with common window controls. We have Close, Minimize, and Maximize. But historically, there have been some other controls like Shade and the definition of "Maximize" kind of depends on what platform you're working with. Additionally, Apple has recently added a new "Full Screen" button and I think we all remember talks of Windicators. Then again, some others are going in the opposite direction, like GNOME, and only include a single close button. And we can't forget that on Tablet and Phone OS's we haven't really seen any window controls at all. So let's take a bit of a look at what controls do and how we can make them make more sense.
Close
This is probably the standard window control. No matter what environment, you need a way to close your apps. Typically, this is denoted by an 'x', sometimes red or orange. It's probably the most obvious button too. When you click, your app's window disappears. Poof, gone. But, uh, sometimes It's not really gone. For example, when you click close on a music player's window, you expect it still play music right? But wait, isn't that what Minimize is supposed to do? This is a bit of a dilemma. Does close mean close or quit?
Background Processes
When Apple first came out with the iPhone, it was not a multi-tasking device. You got to open one app, and then pressing the home button quit the app. The home button in their case, is the close button in our case. Close means quit. Except there's that darn music player again. Pretty soon, it was apparent that third party developers needed a way to have background processes. They needed to be able to watch for notifications, to play music, to use location services, the works. So, Apple added a second button to the iPhone for minimize. What? It didn't happen like that? Oh, I must be confused.
Saving State
Another thing that comes up in a multi-tasking environment is that when you switch from one app to another app, you resume your work right where you left off. If you switch from your word processor to your web browser, you expect that when you go back to your word processor it's going to show the same document you were working on. And likewise, when you go back to your web browser you expect it to show the page you viewed last, not go back to your home page. So we must need another button to save us from these woes.
Minimize
Minimize does about the same thing as close from a user's perspective (it closes the window), but it does something completely different from a developer's perspective. It lets the process continue to run in the background and it preserves the state of the application. This is huge! But one big question is this: if close and minimizing looks about the same to a regular user, how are they supposed to know which one to do?
Developer Knows Best
Some app developers provide work-arounds for this problem. Close sometimes means minimize and just keep running in the background anyways. You know, most of the time it works out. Some developers have even been working on making sure that their apps save your session when they quit. BeatBox and Midori both remember what you were doing when you quit and put you right back there when the app is opened again. This is becoming a trend. So in a lot of cases, close is starting to mean minimize to the end user. Let's keep that in mind and move along.
Our Friend, Maximize
It seems like there are quite a few views of what Maximize really means. One school of thought is that it means "make the window as large as it takes to display all the content you're viewing." Another is "make the window as large as possible without covering the panel or the dock". Yet another says we should automatically hide and show the dock to make room for the window. And Apple seems to have said "Go big or go home" by introducing a full screen button. So I guess the question is, when you maximize an app, what are you intending to do? Usually it's either that you want to show more content, or you want to focus in on that one app. So that puts two schools of thought to the forefront: our "make the window as large as it takes to display it's content" guys and our Full Screen lovers. But since Full Screen already does make the window large enough to display it's content, that seems like the way to go doesn't it? Since there is a fuzzy line between “Full Screen” and “Hide docks and panels when I Maximize”, we could get away with some intelligent hiding modes and using our normal maximize button. This would also allow for a customizeable behavior. Traditional maximize or a faux full screen, it’s your choice.
Placement
Let's assume for now, because of our previous talk, we're only going to use two buttons. We've decided that the developer knows best when it comes to what close means, so we're going to trust him and drop the minimize button. We've also decided that having both maximize and full screen is a bit redundant, so we're gonna go all the way with a wanna-be full screen button. But where in heaven's name do we put them? Commence flame war!
Let The HIG Decide
In our HIG, we say that we'd like the most commonly used toolbar buttons on the left side of the window, and the least commonly used on the right side. This is because of the way we read and where our brain says that our eyes should start on a page (in GTK, when you use a Right-To-Left language, the toolbar layout is flipped). Why not apply the same logic to the window controls? Let's place the most used ones on the left side, and the least used ones on the right side. And since we now only have two window controls to deal with, this should be easy!
Close is something that just about every window uses. We could get by without a maximize control, but we have to have close. And in fact some windows do get by without a maximize control. So we're definitely putting close on the left side of the window. Every window is closed at some point in time. As far as maximize goes? Well, now that we think of it, it's kind of more of a preference isn't it? I mean, you have some apps that you always maximize and a whole bunch that you never maximize. You hardly go around making apps big and small and big and small do you? So I think it's safe to say we can banish this one to the right side of the window without hurting anyone's feelings.
In Conclusion
We end up with a few things. We get a simplified button layout with only two buttons instead of the typical 3 or 4, and where we never have one button appear to do the same thing as the other. We avoid accidental clicks, and there has been a persistent (though sometimes quiet) desire to have the close button separated from other buttons. Finally, we get an arguably unique layout where we don't group all of our buttons on one side of the window.
BUT.. BUT.. BUT WAIT!!!
Before you explode in your chair and start a riot, let's just say that it's not over until the fat lady sings. There is still a long road to Luna and a lot of testing needs to be done. We're unsure about things like intellihide by default especially when it comes to Wingpanel and we need to be really confident before we start dropping things like the minimize button. Try to leave kind words in the comments and contribute only to constructive conversations :)
i think, it should have a option, for those die-hard users to common windows, to enable traditional window buttons. repeat, as an option, that should be easily configurable on system setting (like plank theme's, etc) with no subterfuge or thir-party apps. this is prolly the only thing i HATE from elementary.
i fell in love for elementary, but until this is contemplated, i repeat, as an option (because i do respect the devs and their) im moving away from elementary for the time being.
i havent been so enthusiastic for a complete distro like this, since buntu 10.04. so keep up the good work, and don't forget old-time-conservative-users! ;)
kudos!
I just want to say, that it is awesome and really natural and logical for me. I wanted mini. button too at the beggining, but I get into that "hot corners" feature really fast. Nevertheless I think that there sould be some kind of visualised and more obvious way to minimize, because there are allways things, which you want to have running for let them show up sometimes. And workplace should not be the best way to deal with this kind of apps.
PLACEMENT:
I tried having default setup, and I did not like it. I think it is same to say that most users are used to the icons being on the left OR the right side, not both. Help me to move my mouse less, instead of making me move it more. Also, remember, most Linux users are converts from Windows, not from Mac.
MINIMIZE:
I like the look of having only a maximize and close button, but not for the reason you provided. I always set up middle click on the title bar for minimize, so the button is not necessary anyway. I have maximize and close on the right with middle click set to minimize, and it makes the system far more intuitive to use for me.
How do you have to move your mouse more when the buttons are on opposite sides? It's not like you're ever going to use both at the same time.
I respectfully disagree with removing the minimize button and putting maximize and close on opposite sides.
Suppose I'm running a process in the terminal window, which I don't want to run in the background as I want to occasionally glance at the progress. At the same time, I do not want to clutter my desktop with windows. So naturally I'd minimize the terminal window.
As far as placement of maximize/close: humans are "habitual beings." It is easier to always drag the mouse pointer to the same corner, than to differentiate between the two corners based on intended action.
Since all these settings are easily controlled from dconf-editor, why not add a GUI module to system-settings->desktop where one would be able to modify button placement as well as which buttons should be present. I think this would be in the best practice of Linux experience and especially elementary OS (i.e. providing the end user with a clean interface, with options to modify the interface to the user's preference).
I think what you're raising here is the exact reason for which multiple workspaces were developed. You open terminal in a workspace and the go to another workspace to do something and regularily glance back to the terminal workspace. Plus, with the maximize, you have a neat window arrangement in each workspace.
Totally disagree with statement that Minimize is the same as close.
When I no longer need the program to perform what I am doing I am closing it. I f need visually remove window that I am planing to use in current tasks a bit later I am minimizing.
To prove your point please add option to show minimize and see how many users will vote to have minimize button.
You should remember that this is still Linux and Linux user is the person who would like to be able to customize system to infinity. If you will not give him possibility to do that NOBODY will use your distro. See that happened with Gnome 3 they tried to limit users and they lost a lot of users (now we have Unity, MATE, Cinnamon, you guys ;)) who gust forked GNOME and changed UI almost completely...
And my last point user still able to minimize window by clicking on dock. Thus not having button it is just inconsistent.
I actually agree with loosing the minimise button after reading all that. But I couldn't agree less with having the remaining two 'action' buttons on opposing sides of the screen. I mean, that's like having your pen and your pencil in opposite corners of your office. So while removing the minimise button will remove something which is actually clutter, separating the close/maximise buttons seems really counter intuitive, and elementaryOS seems to me to stand for efficiency and a clean sleek environment.
If it were up to me, I would have a default layout however you deem fit BUT have an easy option for a system-wide customisation for button layout/position. I know basically nothing about software development so I don't know if that's actually a viable solution. Whatever you choose, I shall assume is best and adopt, but that's just my thoughts on this. (: Good luck!
There is a tool called dconf you can use to change the button position if you so desire :)
Hi Dan! I understand the reasoning for removing the minimise button but some people, like me, are going to put it back at the same time as we put the close and maximise buttons on the same side. Any chance we could have an unused minimise button added to the theme so it shows up? Rather than just having a blank space to click on? (an option that shows minimised window indicators on the dock would be nice too) ;) Thanks for your work, looking forward to the release!
Hey!
Another option would be to let the user chose which windows button arrangement he likes when he sets the system up and leaving it as an option in system settings, i.e a drag-and-drop interface.
I personally think that this makes a lot of sense. However, I don't think that the Close and Maximize buttons should be on opposite sides. I think that, out of habit, people would go to the left before realizing that the maximize button is on the right. Also, people are resistant to change, and a totally new layout, no matter how logical, might annoy/deter Linux newbies and veterans alike.
Will you at least be able to bring back the minimize button with some settings? I'll miss it :(
What about the apps like Google Chrome/Chromium that are not using system bar by default? They'll lose the minimize button, and closing them is quitting them, right?
one simple reason to leave a way to minimize: not all the apps support the close&SaveScreenStatus.. leave minimize a chance!
Hello!
I respectfully disagree a bout the placement. And for almost the same reasons that Dan sed they should be there.
Because we read from left to right and so on, the left upper corner is the first spot we see, that's why almost every webpage puts it's logo there, and that's why there are the toolbar buttons. But do we rely need to see the close button all the time? Not me! I mean, why do you need to see it all the time if you know it's there, and it does what it does closes the window. Every window has one of thous. I think that there should be something that identifies the window like windows title or icon or whatever so if you have windows overlapping you would see at once what is what. And also in my experience moving the cursor with the mouse or touchpad to the top right corner is a lot easier then it is to the top left. And i am not saying this because I am not used to it, I use ubuntu and Mac with that layout it's no problem, but somehow it's much easier to get the cursor to the top right. So if I am right (maybe it's just me) and it rely is easier to move the cursor to the top left corner then the buttons should remain there. And so that no one would hit the close button instead of maximize you should just use bigger gap, like KDE does.
And about the action of close button, I think it should close the window. So if the program consists only of that window it would also close the program, if it consists of multiple windows and background processes the program would still be left running but current window would be closed.
Thank you for reading this :)
I Agree!
Dragging to the top to maximize : ok.
Dragging to the left or the right to maximize on this half of the screen : ok.
What about dragging to the bottom of the screen to minimize ? It's like dragging the window back to the dock.
Double clicking the title bar to minimize would be easier...
That would require a huge amount of dragging though.
Sounds neat!
Personally I rather like elementaryOS' new window control layout. Not for the reasons outlined (frequently used left-aligned, less frequently used right-aligned) but rather because left-aligning the close control seems to minimise incidents of accidental closure (I dual boot with windows mind, so muscle memory of a right-aligned close control may play a role).
I do miss the minimise control though, so to preserve the balanced two-button aesthetic I've configure my system to minimise windows upon double-click of the title-bar. A useful default for elementary? Perhaps, though it's not very discoverable.
I also have some sympathy with the 'developer knows best' approach to what action the 'close' control should trigger. However, I think it's very important that developers practice some restraint here. As has been mentioned here several times there is a use case for quitting (rather than simply minimising) a media player. A 'minimise on close' approach might well work for applications that are nominally resident within the messaging menu or an indicator AND which nominally operate in the background with little need for user interaction/initiation. Prime examples being e-mail clients, messaging applications, download managers/torrent clients, password safes, etc. However, applications like media players should at most come with a 'minimise on close' option, possibly not set as default.
Attention also needs to be paid to the consistency of indicating (within plank/docky) whether an application is running or not. Whether or not it is minimised in the traditional sense or via a hypothetical 'minimise on close' mechanism. Docky (and I assume plank, though I haven't tested this) still doesn't display empathy as running (FYI: I have empathy set to auto-start) until I click its Docky icon once and minimise the traditional way. Conversly, Thunderbird with the Minimise on Start and Close add-on (also set to auto-start and minimise) consistently shows as running in Docky even when I 'minimise on close' (in this case a function provided by the aforementioned add-on) Thunderbird. I'll probably look into filling this as a bug in Docky (and testing Plank for the same bug) later this afternoon.
It'd be great to have a similar discussion on scroll bars. The grab and drag behavior that one gets in tablet/smartphone devices is a great productivity enhancement. I acknowledge that one has to consider usage profiles (% of content creation vs content consumption) to tailor behaviors (drag vs select) and provide a simple transition between the two modes (drag vs select). However, I'd argue that most PC/laptop users are weighted heavier on content consumption for which the convenience of default grab-and-drag behavior would be a great improvement.
I think the problem is that behavior really relies on touch to make it feel right. I think it would be really awkward to click and drag with a mouse like that.
As we move towards touch being more ubiquitous, especially as the availability of touch-enabled mice increases, we'll get to do more fun stuff in that direction. But for now, I think we still have to consider what it feels like on a traditional mouse, even if that's not our primary target.
Several image-manipulation apps have provided grab-n-drag behavior for some time. I believe it's also a popular option on Acrobat Reader (even though switching between drag and select could be simpler). The best example I can find is the grab-n-drag extension for Firefox. It minimizes significantly the amount of mouse/pointer moving you need to do. It's not clear to me why mouse click would be different from a finger press on a touch-based device. Having said that, it think it'd be something worth looking at past Luna.
Yes, EOG does this and it's incredibly annoying. It breaks my expectations by assigning zoom to two-finger scroll. Pinch is a much better metaphor.
You should try Scrollbar Anywhere extension for Chrome: http://goo.gl/LWw7f
That is the bestest scrolling type I've ever seen. With one move you can go to any place on the page even if this page very big.
Guys, I agree with elgregor that the system tray is a must-have, but it must be redesigned. I myself use a tiny app, on Windows, called RBTray. It doesn't need to be installed and it allows me to minimize any window to system tray, by right-clicking the minimize button. I really think it's useful. I use it a lot, specially at work, when I don't want my boss to see the apps I'm running. (lol) ... Now, here's what I think... Minimize, Maximize and Close buttons should remain, however each one should have two actions, depending on the mouse click. For example: ... Minimize button - Left click: minimizes the window to panel or dock. - Richt click: minimizes the window to system tray. ... Maximize button - Left click: restores or maximizes the window as usual (without covering panels and stuff). - Richt click: maximizes the window to full screen mode (just like Mac's). ... Close button - Left click: closes independent windows (such as chat windows or Gimp toolbars alone). - Richt click: quits the entire app. Well, this is just a thought. ... Once implemented, people would get used to it. ... Gnome Shell, in my opinion, is modern and beautiful. But that's just it. It's very interesting the way they have idealized their new desktop, but when it comes to multitasking features and agility, I really don't think it's functional. Panels and docks are still the way to go for multitasking purposes.
Gnome shell is cool, but i need to minimize apps sometimes, so first thing I do after installing it is to install appropriate extensions. Playing with virtual desktops takes longer than just clicking the button.
Some of your ideas are kinda cool and somewhat similar to my post below. I think it not being discoverable is a main argument against it.
What cassidyjames proposed is the future of personal computers. But now it won't work. Opening the app takes longer than unminimizing it, especially when using older HDDs. Additionally lot of people aren't using new computers with 4 GB RAM. They need to control things running in background. My proposal is to visualise non-system daemons (like music player or antivirus on Windows). Initially system tray was supposed to do it, but it became bloated, because some app developers add daemons to apps that don't need it. So we need to think about resurrection of system tray or about any other way to visualise daemons.
Interesting thoughts. I think elementary has always been pushing to be more "the future of personal computers" than anything else, but I do understand that not all computers are created equally. However, I believe a proper multitasking system would take that into account and would manage memory even better than what's available now.
For example, right now if you open up an office app, music player, web browser, and game on an old computer, it's likely to slow down. Oftentimes you're really only doing one or two of those things at once, and minimizing things to get them out of your way. While they're minimized, they're still eating up your precious memory. What if you left your browser to come back to it later, and then while you were using your office app (and your memory was low), the system intelligently closed your browser, but cached everything so that when you revisit it, it comes right back up? It'd free up the memory you need when you need it, without you having to manually tell it to.
Of course there are cases when you'd want that not to happen, but in that case, you just wouldn't close the browser window and the system would know not to close the app in the background.
Right... But another thoughts: maximizing minimized app takes one click on the dock, but launching app not pinned to the dock takes longer.
Also what if I want some window to hide and at the same time system shouldn't close it? If I click close, it'll hide, but system can kill it. If I don't click close button, app will stay open, but not hidden. I know that I can play with workspaces, but classic minimize/maximize is easier. (there's also )
Reassuming: good idea, but needs some problems to be solved first if we want to use it.
Hmm I had a somewhat interesting idea, since it's inevitable the changes that are going to be made. What if there are 2 buttons in the control bar. One is a circle and one is an x. The x will minimize the application if you left click on it and will close the application if you right click on it. The circle will maximize the window when clicked and return to default size if clicked while in maximized state. Additionally you can hold down the left mouse button on the circle and scroll the mouse up to smoothly grow the window and scroll down to smoothly shrink the window.
Its complicated, and not discoverable.
Yeah you have a point, it wouldn't be obvious that you should scroll or right click. I guess it's good in theory though.
In respect to "close" behavior:
- The distinction between "close and remove from memory", "close all files and minimize window but leave app in memory" and "minimize window and keep all files" is indeed something you do not want the user to be faced with. The system should just behave right - the question is whether this is easy to identify.
- I would not just "trust the developers" - I would advise to compile a list of key apps and the recommended behavior, then circle this around so that people can envision what the behavior of the system as a whole will behave like, and then decide on the approach.
- None the less, for advanced users that want to manage the system resources manually, an option to remove the app from memory is desired - similar to the way MacOS has Cmd-Q. Such shortcuts to "fine tune" behaviors for advanced users should be added whenever decisions are made to simplify things.
In respect to "maximize" behavior:
- The maximize is simple on Windows and more complex on Macs (with the new full screen view). I don't think it should be complex - one maximize button should be enough.
In respect to "close" placement:
- Most users would expect "close" to be on the right side, as is common on numerous websites (lightboxes mainly) and Windows. Placing it on the left side does make some sense from theoretical perspective - MacOS does that - but theoretical does not always ring a bell with the crowds.
- I would definitely advise to do some usability testing with non-geeks and non-Mac users before making such a change.
But how are users supposed to temporarily hide applications that are not designed to save state?
I think the assumption is that all elementary apps will work really well, and third-party devs can make their apps do the same. The apps that behave consistently and properly will become more popular, etc.
Of course, until then, there's always the dock icon which can be clicked to minimize the app, or multiple workspaces to manage the other windows you're not using right now.
You can always click on the launcher in the dock.
but that would minimize or bring up all of the windows right? is there any way of selectively hiding an individual window?
The various elements and windows could be selected in the plank, by means of a check in the context menu of each application.
As layers in CAD applications.
I am using the "no minimize button" design since months now (on Pantheon or Gnome Shell) and if it's ok in Gnome Shell (thanks to the activity menu) it really is a bad way to go for Pantheon.
When you use applications with multiple windows like Gimp or Empathy it really is problematic, you often want to hide a window without closing it but how do you do so ? If you click on the dock, it will hide all the windows and if you click again, it will show alla of them, and there is no way to do so without a minimize button.
I agree that well designed applications should use only one window, but lots of them don't use this design and the users could want to use them.
The same problem exists with multiple instances of an app : imagine you have two spreadsheet opened : you might say that there should be only one window and that the app should use tabs, I'm ok but actually they don't, and I'm pretty sure that Pantheon user will have to use apps that behave that way too.
I like the idea to remove the minimize button but actually it is just wrong design and that's why I am using Gnome Shell now : they found a way to tacle this problem.
I totally agree with you.
My suggestion: add a shortcut for clicking the scroll wheel on the titlebar perform minimize. I've gotten used to it, and I think other users will prefer it too.
Actually that's a very good idea. Never thought about it.
I've made the same on my system.
I personally know a lot of people who do this. It should be enabled by default in every distro.
Why not just drag to the top for maximized windows?
It's implemented well in both Gnome 3 and Unity. So much so that I hardly ever use the maximize button at all, it seems much more natural to move it than it is to click a far right button. In fact, thinking about it the far right button would be better suited for "full" fullscreen while dragging to the top would be the standard maximize.
I also agree with removing the minimize, so long as we're able to keep multiple desktops.
I agree with this, it gives equally quick access to both actions and doesn't add another button to the window.