- 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 :)
But also double click to maximize is a good idea. We can combine both.
I think it would be really awesome if full-screen windows registered as new workspaces. Somehow Gnome Shell automatically adds workspaces in order to keep one blank at all times; that may be a good place to start.
We can do this *as well* but it's not a discoverable behavior for most people. It's like the swipe-to-delete thing in iOS. It's awesome to have for people that know it's there. But for people that don't, it's not an acceptable all-around delete solution.
I think it would be really awesome if full-screen windows registered as new workspaces. Somehow Gnome Shell automatically adds workspaces in order to keep one blank at all times; that may be a good place to start.
Well I am thinking, the color of the "Close" button can be different in different Applications, given that few Apps, like Music-Players actually "Minimize". For instance when the "Close" button means to quit then it's red, otherwise in the case it means minimize it's yellow or green (or whatever) :P Just an Idea... :)
What about changing shape, not colour? "X" for "exit and remove from memory" and "-" for "close window, but run in background (including messaging/sound menus and so-called system tray)".
I can live only with close button and each window maximased when the expose of windows is provided like in gnome. More: I installed gnome for several people they are noobs in computer but they said wow so easy like in my mobile phone. They are really liky with switching from windows to ubuntu with gnome shell.
I think the problem with window controls and UI design is general is that there are certain limits to perfecting something. That's not to say that one shouldn't look for new ways to improve and expand upon a certain design or an element of that design, but at some point you're trying to improve just to say you improved, not actually improving.
The steering wheel has largely went unchanged since its inception. Sure you can put a cover on it, give it some ridges for fingers, but at the end of the day it's a steering wheel. People know how to hold it, they know what to expect. I look at window controls this way. There are certain expectations with them. It shouldn't be a riddle or a puzzle to figure out how to minimize/maximize/close applications for the sake of saying "Hey look, we saved a few pixels of space off our windows!!" Or just for the sake of being different. Sometimes, being intuitive is going with the expected and common sense approach.
I don't think we should ever limit creativity or finding new ways to do things, but for the sake of something as basic as a window control, sometimes it's best to stick with the tried and true.
This may be slightly OT but the topic of windows controls made me want to say this..
I don't think the car would have been invented if everybody thought "Oh I've got a horse and it works, why would I need anything else?". elementary OS wouldn't exist if they couldn't be bothered trying to improve every aspect of an OS, even basics like window controls.
You might want to ask yourself the question:
Why do we quit applications?
I think we used to do it to save resources because older hardware just couldn't cope with multitasking very well and CPU usage was fairly high even while only browsing the web or listening to music. With most apps that just isn't the case anymore.
My point is, quiting applications has become obsolete. It's inefficient, not intuitive and mostly unnecessary.
There's no need for a maximize button either, just drag the window to the top of the screen. Not having something like compiz-grid enabled by default would be a huge step back in my opinion.
So all that's left is the minimize button. There might be problems if you run multiple instances of an application but I'm sure there's a solution for this.
With the growing use of tabs in a lot of applications in Linux, I feel like this will become less and less of a problem.
Well I made sure to qualify my statements in that you shouldn't stop trying to improve just because, but that sometimes the common methods are the best methods or at least best in the sense that some people don't want to relearn something as integral to an OS such as the ubiquitous window controls.
As to the car/buggy comparison, I think that's more along the lines of Windows/Linux. The window controls are minor when compared to the grand scheme of things (The operating systems, The Vehicles). Why can't you have those forms of maximization and other window controls in tandem with the other methods of handling windows? Is it that important to save real estate along the title bar? It confuses, at least initially, new users. I still have adjustment problems and I've been using various linux distributions for a while now.
I'm not happy about killing the minimize button.
What if you work with documents? When I'm working I often tend to have two or three pdf documents side by side. Of course I use multiple instances of the pdf viewer to do that. Especially on a multi monitor setup you can't just put that in window and tell the people not to use multiple instances of their apps.
If you close one document and you want to reopen it, you have to go through the file browser to find it. Thats a major de-simplification.
So in conclusion, I like my minimize button and while I agree it is not the most used button, it comes in incredibly handy in times.
I use the middle-mouse button to minimize.
Sounds like you didn't read the whole article ;)
There are two good solutions for this. One is apps that save state. I even used this exact example in my article. If you close the wood processor, it should open again with the same document.
But also, we need to strive towards one window per app. For a word processor with multiple documents this probably means tabs.
As for the auto-save philosophy, what about after you edit your file you just decide not to save it? I am an artist and like to painter some random stuffs in Photoshop (under Mac) and then I just quit it without saving anything.
The F3 key in the file manager should work as well in applications with several tabs.
I want this opportunity in gedit and then even in scratch.
In this case reopening is not an option (unless you are using SSD, but even in such case it's faster to minimize/maximize than to close/open). It takes too long and is annoying.
I'm writing this from my old PC with 512 MB RAM, 1,6 GHZ proc...
As long as dragging stuff you have selected to a tab opens that tab up so you can drop I am totally in favor of this.
What about when we need to keep 2-3 documents open, for reference and what not? Like when I'm designing for the web, I need to have two text editor instances, one with html and another with the css, and more if I'm copying off of something. One window per app is one thing (unlike GIMP) and multiple instance windows of the same app is different. They are two entirely different things. Or you can find a way to place tabs side by side within the main window, each fully visible, or to detach those tabs for multi-monitor setups. Maybe some HIG update is in order?
I believe "close" means "close this window" in a window-centric environment.
I mainly use daemon/client apps. MPD (daemon) handle my musique, I launch sonata (client) when I want to do something. When I clic on "close", my only expectation is to see the window disappear. When I want to stop the music, I do that from the client's window and it has nothing to do with the button on the frame.
Same example with my deluge (torrents) setup, the daemon is running and I can spawn a window whenever I want to pause my download, or "quit" the process. Here "close" just make that window go away and I still sharing files.
What happens when there's no background process ? Well... "close" remove the last window, so here you can talk of a "quit" like function.
Really nice article but I'm soooo used to the keyboard shortcuts that I'll use ALT + F9 to minimize what I want :P
Anyway, I think it's a good thing to remove the minimize button and keep close and expand at the opposite in order to keep away the wrong clicks (bad experiences...)
So now, it's time to developers to adapt their codes!
Hey All.
I personally, prefer to keep things, simple, and i think its only a matter how to adapt, what ever it's software, machinery, teatching stuff, and accept how things works,in a clean and easy, and understandable way, and if there is confusion about it's functionallity , i'e buttons running banshee, or what programs you would prefer for your daily tasks, you automatic adapt, and accept, sometimes without knowing that you did, just like having a iPhone for the first time, or what else your phone, you have, you adapt things without further notice.
When i first saw the theme with only 'two buttons' i downloaded it for my elementary desktop, and i thougt, "Now What ?", but i soon realized "What is your need" the minimize button is in your gnome panel at top, depending that you unlocked it, with i.e ubuntu tweak, or what you else prefer,
and i must say i tweaked elementaryOS a bit, for my needs.
Some might say, that the maximize screen button is more or less useless, but i use it every day for my CAD programs, so i can focus on my work.
The only useless thing on my PC is 'CAPSLOCK' on my keyboard ;)
Btw. i adopted the 'two button system' to my xubuntu desktop as well, and i'm quite happy with it.
Remember there is all ways the freedom to decide what theme and what OS' you like prefer.
Personally i prefer a nice clean linux system like elementaryOS, and a xfce desktop like xubuntu for my needs, at home at least.
Have a nice weekend to all, whats left of it.
S.D-H
"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."
Just for clarification, does this apply to *all* programs or just elementary apps? I'd really hate to lose the minimize button on many non-elementary programs.
The window borders are global, so this applies to all apps.
How can you "trust the developer to decide what close means" when said developer didn't even think about such thing? I really hope there would be a way to enable minimize for specific programs (for example, GIMP).
That's not how window borders work. The settings apply across all apps.
You can always change your window button configuration in gconf editor if you really can't work with it, but from those of us who have made the switch we really don't miss it.
Well, in Compiz you CAN set specific apps to be minimizable using Window Rules. But obviously you must know what you're doing.
I don't miss it :)
Here's a good article regarding explicitly quitting apps: http://design.canonical.com/2011/03/quit/
He linked to that in his post. ;)
I linked to this in my post xD
awkward
awkward..
What if there was just a global setting in Switchboard - "The close button on windows ( ) closes the window OR ( ) quits the application" ?
I think we'd rather decide what the more sensible solution is in the scope of the entire system than make the user decide something as technical as that.
http://princessby-tor2112.deviantart.com/art/THE-SEAT-BELT-181593888
Sounds like a good idea to me, but hard to implement..
I think the behavior is determined by the program, not the system.
Yay! I love seeing design- and UX-related stuff here. Great conversation regarding the window controls. Here're my thoughts:
I've been using the two-button layout for quite some time now on my desktop and laptop, and I've grown used to it. At very first, I did miss minimize because I was used to it being there, but now, especially with the combination of a dock and multiple workspaces, I don't miss it at all.
I've also been using mobile devices (phones and tablets) for a while now, and have gotten used to the smarter multitasking there. Now I miss it on my desktop, and I wish we had something other than just "yeah, uh, close sometimes means close, sometimes means quit, and your computer can grind to a halt if you accidentally leave to many open apps sitting around." I think Apple is heading towards the direction of intelligent multitasking and whatnot on the desktop with their state-saving and auto-closing unused apps, and I feel like we need to be figuring a lot of that out as well.
I almost wonder if, eventually, we'd want "closing" to actually perform, on a technical level, what minimize does (keeps the app running, but hides it from view), give some sort of API for the apps to say they're doing something important, and then auto-close non-important-action-performing apps in the background when memory starts to get short. That actually seems to be very close to what Android and OS X do if I'm not mistaken, and if designed properly, could suit us well.
Random other thoughts: that idea about caching pages in Midori when closing the app is awesome; I'd love to see that (I hate having to reload the pages when I just had them open recently). Also, it'd be interesting to see if BeatBox can close itself while continuing to play music in the background... especially when looking at the dock and how mobile devices/tablets handle things, that'd make sense. If you want to pause the music, you pause the music. Of course there's the opposite argument of "if I close the music player, it should stop playing music," but closing a window isn't as explicit as telling the music to stop. But then again maybe I've just gotten too used to my mobile devices.
minimize button has more divine role with running but not to be viewed option. It prevents application window to be popped during alt-tab switching. Or you may want to make some "windows" not to be in the scene for some situations but make it visible again when the situation is altered.
If the concern here is to keep window titles minimalist by removing an innocent dash-like icon, then a toggle (like good ol' pin button) can be used to determine close button behavior, whether removing the output from the screen without closing the application or killing it. You may configure this toggle within the application preferences, like remove visible output but keep sound or remove sound but keep it visible.
Non-important-action?
What kind of non-important-action? Will the system decide for me what's important and what is not? If I leave my work in the plain text editor and go do something else (surfing for some lulz, for example), will the machine decide that's not very important to actually do my work?
If you left work in an open plain text editor window, that's deemed important. If you closed the window, the app would just hide at first and would stay that way unless the system's memory got low, in which case the app should auto-save the state, allowing you to start right back up. You're still in control, the system just manages the behind-the-scenes stuff for you so you don't have to.
Well, that's better. But then, I still need a way to kill the freaking app if I want to. Certainly, I can do it via the CLI, but it would be nice to have an option in the Dock, for example.
And by the way, if you do state-saving, please do not do it in annoying way, the way Libreoffice and Openoffice work.
I'm not sure about this, but won't that slow down the system and consume more energy?
I'd rather like the idea of a timeout: If an app isn't important, auto-close after 5 min idle and save the state.
If it would slow down the system, then the system would close it first. I think it'd be implemented with an intelligent daemon that checked how long it'd been since you interacted with it and if it was doing anything important.
Something like how android handles it? Unlike iOS, Android doesn't feature close functionality for any of its apps, you just close the app, but its still running in the background, and it auto-closes based on memory usage, cpu usage, data usage, timers and what not. And yes, the state is saved, Lion style, so you don't miss anything. As for music apps, there'll always be exceptions. Hey! How about making Lion style Auto Save & Resume, and Versions systems, that'll get things done efficiently and that might be adopted by most other distros. I know its good, you know its good, lets do THAT!
Dude... let's do it! :D
Actually, I doubt we need it, because most apps consume only memory when idling, and zramswap makes memory plentiful... and I doubt we'll need that without a minimze button anyway - the user will run out of workspaces before they run out of memory.
On the other hand, I saw a guy never rebooting a multitasking iPhone, and because of Apple's awkward and non-discoverable maximizing all the crap he launched was running in background, slowing the device down and draining battery power.
However, I had WinMob-based devices for 5 years, and keeping all the apps running in bg worked fine there.
Closing apps automatically sounds like a good idea theoretically, but it doesn't work at all on Android phones. That doesn't mean you can't do it, Google seems to be fairly incompetent when it comes to their Android OS but that's another story...
Most elementary apps are fairly lightweight anyways and start up instantly on newer hardware, so in quite a few cases it's not necessary. Other apps take forever to launch and eat up memory like a mad Pacman and you don't want them to get closed automatically just because you've run out of memory.
Yeah, Postler is such a relief compared to Evo/Thunderbird - I actually mapped it to a screen corner because it was so easy (un-painful) to launch.