March 7th, 2011 byThe “Quit” command in applications today is a relic from the days when the original Macintosh had no hard disk and couldn’t multitask. Modern applications have made this command increasingly annoying. Fortunately, though, modern PCs have also made it increasingly unnecessary. Mobile operating systems have, for the most part, eliminated the “Quit” command completely. In Ubuntu, the messaging and sound menus will help us do the same.
A compromise that got out of hand
It’s easy to forget just how much more powerful personal computers are today, compared with the machines on which some of our user interface conventions began.
In 1983, the Apple Lisa had a 5 megahertz processor, 1 megabyte of memory and two floppy drives — but failed largely because it was too expensive and slow. So the first Macintosh in 1984 instead used an 8 megahertz processor, only 128 kilobytes — kilobytes! — of memory, and one 400 KB floppy drive.
Implementing a multi-application graphical user interface on that original Macintosh required many design tradeoffs. Most importantly, while the Lisa could multitask, the Macintosh just didn’t have enough memory. Except for a few small accessories, only one application could run at a time.
This raised an interesting problem. If you had an application open, and you closed the only document you had open in that application, what should happen? To open a document belonging to a different application, you’d need to go back to the file manager (which was the main application launcher back then), and that would require unloading the application. But if the next document you wanted belonged to the same application, unloading and then reloading that application (from a floppy disk, remember) would be an annoying wait.
So, the Mac designers made two decisions. First, they introduced a way to open a file within the same application, without going back to the file manager: the Open File dialog. And second, they required users to specify manually when an application should remove itself from memory to make way for another one — by invoking a “Quit” command.
This was a reasonable, if awkward, compromise. As the years went by, though, something weird happened. The Amiga copied both these ideas, and then so did Windows, and OS/2, and KDE, and Gnome, and many other environments — even though they could all multitask and (except for early Amigas) used hard disks. It was a classic case of cargo-culting.
To be fair, Open dialogs eventually became more efficient than file managers for the specific task of opening files. But “Quit” (which Windows called “Exit”) became less and less relevant. Mac OS X moved the “Quit” menu item from the “File” menu into the junk drawer that is the application menu. But quitting has remained a basic part of how Mac applications present themselves, and it has persisted for many applications in Windows and Ubuntu as well.
A few behemoth applications, such as LibreOffice and Gimp, still keep “Quit” separate from “Close” for the original reason — to save you from having to wait for the application to relaunch after closing its only document. But that is fixable, and all other applications have become fast enough that they don’t need it any more. After all, they’re running on hardware that is hundreds of times faster than it was in 1984.
People who have been using computers for a long time sometimes get a sense of reassurance from the idea of controlling application unloading themselves. Meanwhile, though, the presence of “Quit” has been getting confusing and even a bit destructive.
The problems with “Quit”
Most obviously, there is a problem with Web browsers. First, people have gotten more comfortable with the idea of having multiple Web sites open at the same time. Second, Web applications have become more common and more stateful. And third, since 2003, Web browsers have competed partly on how minimalist their interfaces can be — which has made the browsers less and less obvious as applications themselves.
As a result, the effect of “Quit” in a browser is now bizarre. For example, imagine that you have windows open for Amazon, Banshee, Calculator, eBay, Empathy, Facebook, Gmail, and Shotwell. What happens if you choose “Quit” in the Gmail window? Gmail quits, but Amazon, eBay, and Facebook quit too, while Banshee, Calculator, Empathy, and Shotwell stay open. How much sense does that make? Not much.
Browser designers have tried various hacks to lessen this problem. Some browsers ignore the standard Ctrl Q keyboard shortcut for “Quit”, because of the damage it can cause. Some put up a confirmation alert, asking you if you’re sure you want to quit. And some offer, in that confirmation alert, to remember your windows and tabs for next time you launch the browser.
The existence of a confirmation alert is a fairly reliable clue that the original design is broken. And that’s true in this case: none of those workarounds make it obvious, ahead of time, which of your applications are about to disappear. And even if a browser restores all the pages you had open, usually it has still lost any work you were doing in those pages. In Ubuntu, the Epiphany browser avoids the problem much more simply: by not having a “Quit” command at all.
It’s not just Web browsers, though. The same problem exists in any application that has windows for apparently distinct tasks.
For example, if you have a presentation open in KPresenter, and a spreadsheet open in KSpread, and you choose “Quit” in KSpread, the spreadsheet closes. But if you have the same presentation open in LibreOffice Impress, and the same spreadsheet open in LibreOffice Calc, and you chose “Exit” in Impress, the presentation closes, and — surprise! — the spreadsheet closes too. How much sense does that make? None whatsoever.
KPresenter and KSpread are coded as separate applications, so they quit separately. LibreOffice Impress and Calc happen to be coded as a single application, so they quit together. But why should you have to know that engineering detail? On 21st-century computers, it’s irrelevant.
Finally, “Quit” is confusing for any application that can do useful things in the background without windows open. A long-standing example is the file manager, which typically controls the desktop as long as you are logged in, and so doesn’t have a “Quit” function. A more recent example is the Mac App Store, which — like Ubuntu Software Center before it — continues downloading and installing applications when its window is closed. Surprisingly, though, the Mac App Store continues downloading and installing applications even after you “Quit” it. In Ubuntu Software Center we avoided that weirdness by not having a “Quit” command in the first place.
In other cases, though, the behavior needs to be more flexible. You might, or might not, want to be notified of new e-mail messages when your mail client isn’t open. You might, or might not, want to receive incoming chat messages or calls when your IM client isn’t open. And you might, or might not, want to keep playing music even when the music player isn’t open. In these applications there is at least a useful distinction between “Close” and “Quit”. Unfortunately, the result is that “Quit” is being used to mean several quite different and non-obvious things: “don’t check for messages any more”, “go offline”, “stop music playback”, and so on. A single term probably isn’t a good presentation for all these things.
In summary, then, “Quit” is more confusing than useful. For many applications, it can be either removed altogether, or changed to the more straightforward “Close” if that item isn’t present already. But for applications that run configurable things in the background, the design is a little more complex. Fortunately in Ubuntu, we have some elements waiting to help out: the messaging menu, the me menu, and the sound menu. (It’s almost like we’ve been planning it.)
Messaging
Since Ubuntu 10.04, Ubuntu has had a messaging menu, which shows incoming messages from humans, as received by any application that integrates with it. (It’s been great to see Thunderbird integrating with the messaging menu, for example.) Ubuntu also has a “me” menu, which — among other things — lets you set instant messaging status, for any IM or VoIP application that integrates with it. It’s possible the structure of these menus will change in the future. But the basic idea will stay the same.
One awkward detail has been that if you have used the me menu to go offline for instant messaging, you can’t use it to go online again. Last week, Ken VanDine fixed that problem — which means that for any IM application that integrates with the menu, it’s no longer necessary for it to have a “Quit” item. If you want to go offline, you can do that from the global menu. And if you want to close the program’s contact list, you can do that without affecting your online status. The functions will no longer need to be tied to each other in unpredictable ways — they will be completely independent.
For e-mail and similar messaging clients, things are a little trickier. At the moment, these applications typically stop checking for messages when their window is closed. However, many people apparently want these functions to be independent too — as shown by the variety of separate mail notifiers available in Ubuntu.
The engineering solution here is for messaging clients to split out the code that checks for new messages, so that it can optionally run even while the rest of the application is not. Gwibber already does this, for example.
Music
There are two main kinds of media player application. For standalone players like Totem and VLC, which mainly play individual files, the behavior when you close the window is fairly straightforward: the media should stop playing, just like a game or Web page would.
For jukebox-like players like Rhythmbox and Banshee, though, what should happen when you close their window has long been a source of debate. With Ubuntu’s sound menu, we have a chance to resolve it clearly.
The basic design principle of the sound menu is that in a multi-window environment, it’s reasonable to want to control a jukebox-type player quickly without its window being open, and that a menu is a good way to present that. Again, it’s possible that the exact presentation will change in future, but the basic idea will stay the same. We’re delighted that thanks to the Mpris standard, Amarok, Banshee, Clementine, Exaile, MPD, Rhythmbox, Spotify, Symphony, and Xnoise will all integrate with the sound menu in Ubuntu 11.04.
Having a separate quick-access interface reinforces the basic idea that whether a jukebox window is open, and whether music is playing, are completely independent things. You can close the jukebox window without interrupting playback. And you can start or stop playback without opening a window.
Implementing that much has been easy enough for our friends working on Banshee, for example. But it introduces a new issue: If you want to start music playing from the sound menu, you can’t be expected to know or care whether the player is already running. So in Ubuntu 11.04, the sound menu will show the Play button even for registered players that aren’t running. If you choose Play, the player will launch and then start playing.
If a player takes a while to launch — because it scans a database of media each time it launches, for example — making this a smooth experience will be a challenge. There are several possible solutions, though, depending on the player. For example, it could remember which track it was playing when it was last running, and postpone any database scanning if it has been launched for the express purpose of playing a particular track. Or it could even keep running in the background for a couple minutes after you stop playback with no windows open, just in case you’re going to start playback again.
Always be closing
Phone and tablet operating systems, such as Android and iOS, have abolished the ideas of “quitting” or even “closing” applications altogether. In Ubuntu, running on screens large enough (and with pointing devices precise enough) for multiple windows, “Close” remains a very useful idea. But with a little effort, we can reduce frustration and simplify Ubuntu overall, by making “Quit” something that humans no longer have to think about. Let’s stop being quitters, and start being closers.
The toolkit
247 Responseshide comments
You apparently aren’t using a laptop at all like mine. It’s a few years old, has 2GB of RAM and a 5400 rpm hard drive. Startup for almost any GUI application takes a non-trivial amount of time. Your assertions, at least in my experience, don’t fit the hardware that a lot of people actually use.
The issue with this is that ‘close’ would no longer be a familiar idiom.
Right now, ‘quit’ means a multitude of things depending on what application the operation is being done to.
The ‘close’ function means to me ‘make this stuff go away’, whether that’s a web page in a tab, a single text document, a conversation. Your solution seems to risk pushing the overloaded quit functionality onto the close function instead.
I think it’s important to enforce ‘close’ as a simple idiom. If I click ‘close’ on a document, I expect that document to disappear[1].
On the jukebox points; you’re describing an ‘activity’ that I’m doing, of course this is fundamentally different to viewing a single document. For things in this class, it doesn’t make sense to have a ‘close’ operation. It would make sense to instead clarify the difference: you’re acting on the ‘activity’, not a single document. ‘Hide’ could make more sense.
To that point, it no longer makes sense to have a separate window for Banshee when you can click on it’s activity in the SoundMenu to manipulate the activity. Perhaps when I click, it should show the Banshee ‘main’ window with a nice window decoration visually linking/embedding it back to the SoundMenu. If I load Banshee from the main menu, the same should happen.
[1] What happens to the application, I don’t care about as a user. Whether it’s still in fully memory or not is an implementation and optimisation detail – arguably this might be different for different classes of device.
For example, cupsd runs regardless of whether it’s working on a document or not – why shouldn’t firefox be running/hidden ready for use if the system knows I’m likely to want to use it?
Have you seen the RSS of Firefox after it has been running for a week or two?
“If a player takes a while to launch — because it scans a database of media each time it launches, for example — making this a smooth experience will be a challenge. There are several possible solutions, though, depending on the player.”
Read the article more thoroughly next time
On older hardware (and particularly with slow hard drives) it’s not just certain things it’s pretty much everything. Read my comment more thoroughly next time.
*Only* 2GB of RAM? Poor you!
There are a couple of applications I use every day which seem to fill up RAM freely while I use them (X, Thunderbird & Firefox come to mind) and it would be nice if they garbage collected better, but overall, with 2GB of RAM you’re only 20,000 times better off than I was with my Sinclair Spectrum 128k+2 in 1986.
FYI, my laptop here is very slow with 1GB of RAM, so I can sympathise a little, but the “poor me, my hardware’s so shoddy” argument doesn’t hold a lot of water in this day & age.
Dave.
Dave, he’s not whining about his hardware, you’re reading the wrong part of his comment. He states not quitting will make apps hog system resources while still running in the background.
Answer: configure enough swap space. But yes, I’d like to be able to “quit” rather than “close” applications too. I often find myself doing it from the command line, using “kill” or “killall”.
not a very good answer though – just adding more swap space now just moves the oversubscription problem to the VMM and the a posteri decisions it will make on what you may want to do – for many people fine and dandy (or they learn to live to with it) – but this is like trying to deal with traffic problems by building bigger cattle cars and filtering everyone onto the trains and shuttle them back and forth (typically in an egalitarian fashion) – hoping there’s no track issues .. in my mind the swap paradigm is probably more in need of an overhaul than the quit/close/exit paradigm
When having lots of swap space, the apps still need to be moved from memory to swap, and this is slow, especially when you have a very slow hard drive. Just quitting the application, will free the memory, without having to write on the slow hard drive. So, no, swap is not the solution.
xkill is my personal friend for killing the Firefox and other misbehaving apps. None of my computers has more than 1GB of memory and the laptop I use daily for my work is 384 MB 600 MHz iBook. Running Debian, of course.
Really? Your answer is “configure enough swap space”? Have you SEEN how much memory Firefox uses when it’s been running for several weeks? There’s truly a need to periodically shut down ALL of Firefox, and then restart it, tabs and all. Firefox is not the only offender (it would be moot if there were only one), it is just one of the more obvious.
Swap is so many times slower than real memory that anyone who cares about performance will make every effort to avoid any significant use of swap.
Religious arguments about “how applications should function (in an ideal world)” shouldn’t get in the way of pragmatic resource considerations. If options for absolutely shutting down an application are removed, then it will increase the frequency that one needs to use killall. It just moves the problem without solving it.
Gosh, statements like this are naive.
In essence, you’ve had some kind of religious experience and decided to alter the user interface to reflect your new spiritual insight.
However, unless every single application provider a) undergoes your same sudden burst of insight and b)
is motivated to:
- rewrite every bit of software
- fix pre-requisite libraries so that they solve all possible problems with resource usage
- fix all possible resource allocation issues
and
- guarantee a clean shutdown
- without leaving zombie processes running…
… well, good luck with that.
It might be time for you to give up technology and consider politics. One size fits all directives issued from on high by people who don’t know what they don’t know are generally better tolerated there.
One more thing. You said “Applications don’t have close buttons, windows do.”
I don’t know what apps you use, but most applications have the option to close.
So, I wish to add that apart from being frequently laughed at and ridiculed, it’s great to be a UI designer with new ideas. I wish you the best of luck.
DON’T REMOVE THE QUIT API/USER INTERFACE
Although I appreciate Mr. Thomas’ reflections on wanting to remove the Quit interface from applications, I support Mr. Bollingmo’s position: Don’t remove the “Quit API” because applications will hog system resources.
Users/Developers alike need the “QUIT API” for 2 reasons:
1)the sake of saving mobile battery life and desktop energy usage.
2)users do want certain apps to squeeze extra performance out of their hardware. This can’t happen if the operating system lets other zombie hogs hang around forever. Interesting to note I recall a certain compiler benchmark adding more loops to slow the benchmark down if it detected a certain CPU type. This is the kind of system hog evil application you especially don’t want hanging around. When a user says quit/kill an application, he means it, needs it and wants it.
The above QUIT API is a necessity in legacy PC hardware, but it is astoundingly relevant on Mobile devices with Android on them. Install enough apps on your mobile device and start running them all and you will witness all your mobile devices’ applications will run slower because they will hog all the system resources. Ditto for Apple hardware with or without swap.
No one is advocating this. At most, doing what OSX did and move the “kill this application” function to a catch-all junk menu. In the long term, I think, a specialized UI for stopping tasks, similar to what Android has, could be beneficial.
man, we have have 2011!! buy some additional 2GB of RAM and a SSD! I never quit/close/whatever programs and I still have enough resources free..
I definitely agree with this blog post. When I click on the “cross” in the titlebar I don’t want to quit the programm, just want to put the window out of my face. And no, minimizing is something completely different coz that would include a minimize effect which I don’t want to have.
Any GTK-Theme hackers around? Maybe just switch the minimize button with the close function – problem solved.
On the other hand, maybe I should just try installing mac osx on my thinkpad again.. Apparently they already fixed this problem in 2000…
Thunderbird background mail check ++
The title of this post scared me horribly.
The content, however, was very exciting
For a moment, conversely, I was very excited at the promise behind the title. Oh well, we’ll just have to wait a little longer this time…
Yeah, we don’t want no design team. The design was good enough! Let’s just leave things the way they were!
http://www.seopher.com/images/ubuntu/feisty5.jpg
Is that sarcasm? Because that screenshot is actually not ugly, even if there’s “room for improvement”.
Actually, it is quite bad, in my opinion. Very antiquated. I appreciate your sarcasm, Chauncellor. Made me laugh.
Very well observed. I really appreciate the work you do at the Canonical Design Team: You are on the right track! I love how you are looking at things that everybody just takes for grant and take a step back. Reconsider it. Wonder whether it actually makes sense. And if not, come up with something new to improve it.
That really drives innovation. Keep up the great job
!
i like how you think about this problem.
btw.. i only use the quit-command in browsers to empty my memory. two browsers with many tabs at the same time is too much for my 4gb
The title scared me too!, but ok the content is really exciting, the meaning of “Quit” is different from”Closing” so if i want to quit i go to the System and specify to close entirely the program, like Rythmbox if i don’t want listen music anymore i just Quit, but if i want to listen music in background i just close the window but not the entire program.
This speech is interesting i hope tha you can implement this function very well.
Better than OSX
It is really encouraging to see more and more talk about consistency and coherence appear on this blog, which is so important for a good experience. You make very valid points in this blog post.
The Sound Menu is a good step forward, but I am concerned that it could become quite cluttered. If you have three media players registered with the menu, will it also display full controls for the three of them? Only controls for one of them and just entries for the rest makes it already quite a busy place.
To be present in the sound menu, a music player needs to be (a) installed, (b) one you personally have used (or the default), and (c) not configured to be absent. https://wiki.ubuntu.com/SoundMenu#compliance So it will be rare for anyone to have more than about two players in their sound menu.
Still, a button to minimize (i.e. show the name only) for a Music player might be helpful, expecially for users who are just trying out other player. It might be a good idea to only keep the item for the default player on there (as long as users are easily able to change this).
Thank you for your reply. I’m assured by the criteria for Sound Menu presence.
I was actually making a slightly related post when I saw this one come up so nice coincidence. Mine is about workspaces and application opening…etc.
I wonder if there are any implications for power usage on laptops, if applications are left running in the background?
My guess: applications will still quit when their last window is closed, or at most they will keep running for a couple of minutes if that makes sense (see the music player example by mpt). They certainly won’t force all applications that were once started to keep running until the PC is turned off!
If I’m not mistaken, some OSes kind of resolve this issue in different standard ways (please tell me if I’m wrong).
Under AmigaOS, there was the concept of “Commodity”. Commodities were pieces of software that remained loaded, which you could control thanks to the “exchange” program (or keys combinations) in order to make them pop up, configure them or quit them completely. They could pop up at startup or not when placed in the WBStartup drawer, depending on the “popup” tooltip that could be enabled or disabled. That was built in the system so tons of Amiga apps were commodities.
Years later, OSX, if I’m not wrong, allows to right click on apps in the dock to ask the OS to keep them loaded, but with no window open. (?) To me, this option is an amazingly great solution, to enable the user to choose which apps should remain loaded all the time / startup at launch time without appearing.
I think Vista / Window 7 do preload apps depending on their usage frequency ? (or so does the preload daemon under linux, but it isn’t supported anymore).
Well, considering memory is rarely an issue nowadays, and provided there aren’t too many memory leaks, it would be great to allow user defined apps to remain loaded all the time, even when all their windows are closed. It’s a bit ‘stupid’ to quit and restart the same apps again & again… Unless you really need to free memory or unless the app do eat some CPU usage in an unexpected way.
My problem with the current implementation in ubuntu is that applications live in the sound / messaging menus. A typical experience with somebody else using my computer who wants to close the music program (intuitively quitting it and stopping the music from playing) is to click the x in the upper left corner and then be shocked and surprised when the player disappears and the music keeps playing? Why didn’t it stop and where did it go? I have to explain to them that it is now in the sound menu hidden under that little tiny status icon / button up in the corner of the screen. Of course, their response is always, “That’s stupid. When I close an application it should close.” This has happened on numerous occasions. On top of that, I find it way too difficult to close empathy. I always click on the x thinking it will close and log me out. Instead, I remain online with no indication. To quit empathy, I have to traverse the menu and figure out where it went, click on the right menu item to open it, and file->quit.
Instead of all of this excessive close/quit cruft, which has only made things less intuitive IMO, a system where a user can right click an item in the panel and mark it as “persistent” or “always run” is a much better solution. Closing rhythmbox, for instance, can be made to continue to play music or to close entirely depending on the user’s desire. On top of that, the item in the panel would still display that the application is running so the user wouldn’t have to HUNT down the closed application in the menus.
This could also be easily fixed with a nice zoom animation displaying the closed window that shrinks in the sound menu, or some kind of highlighting of the sound menu when you close the banshee window while it is still playing. Or, again, an arrow similar to the one used by Chrome for dowloads, poyinting to the sound menu.
That’s the conclusion I came to as well. http://launchpad.net/bugs/692368
How about simply staying with minimize?
And if a “minimize to tray” option is really needed, how about a new “minimize to tray” window decoration?
In contrast: I got quite irritated some time ago at a bug in empathy that caused it to quit when I closed the contact list. When I close the contact list, I expect the contact list to close and for me to remain logged in to the messaging server!
If you want to go offline, use the menu provided for that…
(incidentally, I’m looking forward very much to having my email checked without actually have to run UI for it…)
Yes, Justin, I think the same.
If I want the application to keep running, I’ll minimize it, not close it! Then, I’ll configure it to “minimize to the system tray” or something like that. Why change this if it is SO DAMN SIMPLE?
Sorry. I’m not against innovation, and I love some of the things the guys here are doing (I can’t wait to see 11.04!), but the innovation is not good if it makes something easy and clear looks hard and confuse.
it’s called the principle of least surprise, and it’s something that ubuntu seems to constantly move farther away from.
That’s the one. IMHO, That’s an excellent solution, of course, as long as the “persistency” parameters (e.g. kill-after-idle-timeout or kill-at-memory-excess, because there are tons of leaking programs), can be configured by the user.
My personal experience with computers taught me that a computer should do what you expect it to do, when you tell it to do so, meaning that I want it to behave as I see fit depending on the need, and not vice-versa. The ability to customize freely and to make decisions freely, were the things that brought me (and many others) to GNU/Linux in the first place. IMHO, dumbing the end user down and taking the awareness of the option to decide on important stuff is not a path to success, but to degradation, in the long run. To make things shorter – I believe that yes, there should be an option to put processes to sleep while retaining limited functionality, but that option should coexist with the option to kill the process altogether. I am aware of the fact this approach is a bit more cumbersome and a bit less “user-friendly” (In the modern sense of this expression), but it’s a matter of respecting your user’s intelligence, again, IMHO.
OS X doesn’t keep applications “loaded” in the way described. Rather, you can ctrl + click on them in the Dock and choose to have them remain in the Dock even when not running. The idea is that the programs you use most frequently can be quickly launched from the Dock without having to navigate the file system.
I keep Firefox (actually TenFourFox now) in the Dock at all times but I certainly don’t keep it _running_ all the time. As has been said, if it was not possible to quit TenFourFox, that would be a very serious problem. For most users, it would mean a restart, I’d guess. Until somebody came up with a GUI for the kill command…
If you want an application to keep running with no windows, you just close all the windows. OS X users don’t seem to have a problem understanding the difference between Quit and Close. So I’m not sure why Linux users should.
Typical of Linux these days – god forbid you teach anyone anything. Close and Quit DO have different meanings and to say otherwise is like saying a Car and Truck are the same thing. You would do computer users a world of good to educate them about the differences rather than treat them like idiots. After all, they do know the difference between buttoning a shirt vs zipping a jacket.
See, the problem is (as was explained) that there is no good way to educate people on the differences! Examples were even provided that demonstrated the inconsistent behaviour between different applications and different situations.
Your comment is sadly typical of the standard computer nerd. The question that should be asked is why is there so much required arcane knowledge needed to drive a computer? I don’t mind complexity, but I’m a programmer… I think and model mentally similar to computers (tree hierarchies are easy, logic operations simple)… My parents are not the same people. My mother struggles to remember her location within the abstract concept of a “file system”, and doesn’t know all the correct places to look to figure out how to navigate it properly. Yet she can figure out complex financial arrangements, and plan projects of 100+ people to exceptional accuracy. Maybe the things you take for granted as “simple”, are not so simple for people not wired as you (and me) are…?
Regardless of how you model complexity in your own head, you still have the issue of predicting what’s going to happen when you do hit quit: if it’s application you’ve never used before then there is always a moment of excitement where you find out what’s actually going to happen…
No good way to educate them?
How about they learn themselves? You do it a couple of times and see what the differences are. You have the ability to remember this. Suddenly you’ve taught yourself. What you’re talking about is training – and training is useless. People can and should educate themselves on such trivial TRIVIAL matters.
People are quite capable of learning the differences (and there are VERY VERY few) between the 3-4 applications they might use on a daily basis – unless you consider all users to be SEVERELY mentally retarded.
What a load of bollocks. I use quit very often because quite simply i’m fagged if i’m going to hunt every window of an application down to close all the windows/tabs one by one. I always just want to be rid of whatever parts of the task I was doing and start afresh on the next one. If that was not an option i’d have to resort to ‘killall’.
With so many applications being so badly coded that they suck cpu when they’re not even being used, sometimes quitting them is the only option so that your knees don’t burn or you can play a video without stuttering.
What? You haven’t learned to use the “Close All Windows” option yourself?
Amusingly one of the most popular applications on Android is Advanced Task Killer. It is very hard to get the application lifecycles right and even harder to keep people happy even when it was designed that way from the very beginning. (The situation is also exacerbated on Android due to uninstallable bloatware.)
I love this idea but I think there has to be an easy way to also kill an application outright for memory or other reasons.
Also amusing is that though this site is devoted to design, its design makes hyperlinks quite hard to see. So it’s not your fault that you didn’t notice my links to one article about Android’s lead designer discussing the silliness of task killers, and another article by an Android engineer explaining in detail why they’re unnecessary.
I’ll see if I can persuade our visual designers to add some underlining.
Yes! It’s hard to find the links among the text! Even after you said so, I had to surf in Ctrl+F. Yes, you should persuade the visual designers to do something about the links (bold or underline).
But, most of all, you should consider the comments on this post.
I’m a regular user (not a geek) and I want to be able to control my apps. If I close it, that’s because I dont want it anymore. If I wanted to hide it, I’d look for the “hide button” or even the minimize (that’s what that is for, isn’t it?).
Regarding to Android, the kill widget is the most clicked icon on my phone’s desktop. I’m really curious to read this guy saying that it is stupid! I though that stupidity was not to be able to pick up a call becouse my phone is running some apps!!
Personally I do actually notice the difference. I can run a few apps and then start a 3D game and notice it being sluggish. Then I got open Advanced Task Manager and kill a most apps, and then start the game again.
Voilá, the game now runs smoothly.
Usually when engineers and users don’t agree on something the engineers are technically correct, but the behaviour still annoys the users. That is even worse than inconsistent behaviour, because it just keeps on upsetting users, _on_ purpose.
Yes, on Android, you don’t _need_ to close applications. Most people I know who use Android phones, have experienced the slowness that resource hogging can cause. Task killers can alleviate symptoms of an automatic system that works well, but not perfectly.
I personally think that the similar system on Mac OS X is one of its many design flaws. I don’t like having to chase applications down to know that they’ve relinquished their memory. Especially since so many modern applications leak so much memory and resource that they hardly would work on an older machine.
To my dismay I see more of the (mostly) useless but pretty eye candy of Mac OS X coming to gnome and ubuntu via gnome shell and unity. These things seem to be built more out of envy than any real ease of use.
As I have said twice already, this change will make Ubuntu less like Mac OS X, not more.
I’ve found that if I leave the last.fm application running overnight, when my alarm goes off in the morning (and last.fm still playing because it lacks a sleep timer…like too many music streaming apps), it can take 5–10 minutes to switch to last.fm to stop the music so that the alarm clock can show me the math problem dialog without taking 10–15 seconds between keypresses (I use Alarm Clock Xtreme since nothing else has snooze or trigger rules that are rigorous enough for me to actually wake up to). Anything short of a task killer is unable to get the thing usable since the last.fm is near impossible to get to once the alarm has started going off.
Also agreed about the bloatware. I don’t need Facebook or the Twitter app running in the background when I don’t use either at all.
I uninstalled that very same alarm clock app due to it’s sluggishnedd when it goes off.
Right now I prefer AlarmDroid on 2.2 and the original alram clock on 2.1. Alarmdroid is however sluggish in it’s main UI, but not when the alarm goes off.
Of course I always set multiple alarms to make sure I wake up properly.
So the “x” in the window control will change then?
right now it does both “close” and “quit”
Right now it does close(hide) or quit depending on the application. To me (and to every other person who has ever used a computer) the x button on the window manager is a way of saying “I’m done using you, get out of my face.” This is where the confusion comes into play. If the application has something it needs to finish, it should stay in the background and do so. Otherwise, the application should quit. Turning the x into an even more inconsistent hide button which sometimes quits (depending on the application) and sometimes hides (in the literal sense of whyTF didn’t my application stop and where did it go?) is not making things better. Canonical needs to make a clear and precise decision on what the x button is and what it does. This “sometimes it quits”, “sometimes it hides” inconsistency only confuses users.
When you have to educate your users on the subtle difference between close and hide, something is wrong with your user interface in the first place.
The clear and precise definition is this: A window’s close button should always close the window. Anything that happens after that should follow the principle of least astonishment.
congratulations, you just explained why this is a bad idea.
And congratulations to you on your evidence-less assertion.
A wonderful and thought-provoking article that is sure to stir debate, as all good rethinks should. Ubuntu is moving in a new direction and I don’t see why everything can’t be rethought.
The bottom line is that Ubuntu needs to become a platform different to Linux, and it’s doing that. Generic GTK+ apps need to be patched and recompiled to fit _exactly_ the Ubuntu design philosophy. Dev tools and tutorials need to be available and clear. There needs to be a preferred language, set of libraries, and toolkit. Packaging and publishing to a Launchpad PPA need to be simple. You probably need a preferred IDE for all this to happen. Less choice? Not really. Experienced devs can still use whatever they wanted to use; you’ll just get a lot of new ones on board. Quickly is on the right track.
Why “quit” at all? Why not simply save state unless the application has been updated, the way mobile platforms do? This means that applications will probably have to be patched, but the functionality can be put into a lib and the patch process automated, right?
Also, I don’t really understand the assertion that open dialogs are better for opening than file managers, when opening files is 90% of a file manager’s job in the real world. Wouldn’t it be better to have a great search- and tag-based file manager that displays the appropriate type of files when a program wants to open an unknown file, sort of extending Unix’s “everything is a file” paradigm?
More radical rethought and change, please. Even if I don’t personally like the change, it’ll be good to see divergence from generic_gnome_distro_plus_patch and the like.
You need to solve the issue of memory consumption, and runaway processes. Firefox – and Chrome, and any other browser I’ve tried – is a good example of the issue.
As you keep using the browser, it will gradually allocate more and more memory for itself. After a few days my whole system starts to feel the strain when I use other memory-intensive applications like Gimp, OOpresent or the NEST simulator. Any time you switch windows you slow down when the system hits the swap space for context change.
Another thing that may, and infrequently does, happen is that a process goes runaway. The browser is again a good example; you may load a webpage with buggy javascript, flash or java code that starts running busy, and it drags down your entire desktop. I’ve seen inkscape get into such resource-hogging busy-looping as well, and I’m sure you could add many other applications to this list.
And even when that doesn’t actually happen I at least sometimes want to preemptively quit applications for safety. When I’m due to do a half-hour presentation for a roomful of people I very much do not want my system to start stuttering, the browser to go into some busy loop, or some backgrounded application pop up a warning that it can’t find a network or something. I want to quit everything that isn’t my presentation, so I can be sure nothing will happen.
In all of these cases you need something with the functionality of “Quit”: “please remove yourself from the process list and let the OS reclaim your memory. You are to take no resources at all until I call on you again.” You may not want to call it “quit” and you may not want to have it in the File menu (though that’s where people are going to look) but you do want it available.
If not, you’re simply going to make people use some kind of separate “Killer” application instead. Is a separate process-killer really better UI design than the ability to kill right in the application itself?
The “killer” application you describe already exists and is installed in Ubuntu by default. It’s called the System Monitor. It lets you quit buggy processes that have gone runaway or if you have pre-presentation paranoia. It’s not perfect: it would be nice if there was a system-wide keyboard shortcut for it, for example. But it satisfies the basic case you’re talking about.
When an application is runaway – especially one that starts chewing large amounts of memory, as has happened with Firefox – I can’t easily start another application. It typically takes several seconds just for a single mouse click to actually register.
But yes, if there was a hotkey to some tightly focused app only concerned with killing processes and releasing resources (or just a hotkey to xkill I guess) then that’d be a second best. Even better, make it easy to access the killer from each application menu and make the current application root process be pre-selected in the killer tool since it’s not always straightforward to know which process corresponds to your current UI. Could even make the menu choice just kill the current application directly by default.
This is a bug with the I/O scheduler and a different issue entirely. I can fully empathize with you as I have the same problem but this is design and not implementation
Would the “close window” still kill say firefox in the new setup? If no, that would suck.
Why would I have to use the task killer in the first place? Most people don’t know about it. You’re making a perfectly valid use case (killing apps) harder to handle. I find that very misguided, sorry. Why not do this on a case by case basis, that’s more reasonable.
No, you shouldn’t have to use the task killer in the first place. You shouldn’t have to kill tasks in any way in the first place. That’s the whole point.
I shouldn’t HAVE to, but I should BE ABLE to do so quickly. It’s a *NIX system. It’s not for the computer to decide what root should or shouldn’t do. I need to be able to let the process run in the background, or to kill it, or to save state, or keep tray functionality, or whatever. I should also be made aware of these options, because I’m not a monkey, I’m the computer’s USER. It shouldn’t be the default option, but it should nevertheless be an option, and not one buried in some “task-manager”-style program. Seriously, what’s the next step? “You shouldn’t use command line in the first place”?
THAT is your solution? Seriously? When the user can manage to take care of everything nice and tidy with a simple quit; instead we’re relegated to using the system monitor to take care of it?
Can I give my mom and dad your phone number when they wonder why Firefox is behaving badly?
I explained why it is not “a simple quit” here: http://design.canonical.com/2011/03/quit/#problems
giving the System Monitor a facelift was on my #1 wishlist for a while now, i think it needs a UI focused primarily on giving us back that feature which you are suggesting be removed from the window manager level.. quit.
your article is excellent, as always, and i’m quite amazed by the clarity of observation.
Thanks again
In Windows, the nice little program Process Explorer has a button to select a windows. Click the button, click the window and that window’s process is highlighted. You can also kill a “process tree” directly (like killing the Chrome main process and all it’s “children” at once).
Please add the same thing to System Monitor!
The decision when to quit an application should indeed not be left to user. The problem is not this idea but the deficient implementation in Ubuntu. The reason recent versions of Ubuntu feel so slow and clunky is because the software has taken over this decision in some visible cases, and squandered it. You constantly find yourself waiting for some program to reload, whether it’s Rhythmbox or Gwibber or something else. When you ask for something to happen, it may respond immediately, or take a few seconds, and you have no way of knowing so you’re always on edge. It’s terrible.
The Ubuntu developers have made the worse trade-off possible: they’ve traded the aspect I most care about – the responsiveness of the system – for something I couldn’t care less about – maximizing the amount of memory available at every moment.
The weird thing is that the technical aspect of this issue is a solved problem – it’s called swapping. If the user stops playing a song, you just leave the player running. If the user wants to start playing again in a few minutes, the application responds immediately. If the player isn’t used for a long time and that memory is needed, the player memory is swapped out to disk so it doesn’t take memory. If the user wants to play at that time, they wait – but even then, swapping in is quicker than starting up a new application, and the application appears in the same state it was before. If no other program actually needs the memory that the player takes, the user might start playing 24 hours later and still get an instant response.
If the music player does something in the background, like check for and download podcasts, then it keeps doing that the whole time. The memory pages used for handling podcasts stay in memory, but those that store the music library are swapped out because they’re not in use. It’s ideal.
The Linux kernel has sophisticated algorithms to shuffle data around between RAM and disk to make the most of the available physical RAM. Instead of using them, Ubuntu is essentially always choosing the most aggressive swapping out – whenever an application doesn’t have a concrete reason to be running right this second, it’s closed. Instead of balancing, it always prefers to free memory and keep the user waiting. That doesn’t make sense.
If you have any specific example of an application where Ubuntu “has taken over this decision” of quitting it, please report a bug with precise steps to reproduce the problem. That would be the first I’ve heard of it.
If the Linux kernel you laud can’t find a swap partition, the kernel itself terminates processes when it runs out of memory. That could be the problem you are experiencing. As far as I know, nothing either warns people that Ubuntu can’t find any swap, nor explains where a reaped process went. Both would be useful enhancements for Ubuntu.
I believe his point was that by closing the App right away, you force the swap, rather than just letting the Kernel swap the process out naturally.
My understanding of your post is that you think the OS should “take over the decision” when applications are started and stopped, and I agree. That’s not a bug, that’s the intended behaviour. My point is that Ubuntu is making the wrong decisions, agressively quitting applications.
Example: you click the “Close Window” on Gwibber.
In Ubuntu 9.10: the window disappears immediately. When you click the notification area icon, it immediately appears. That’s because the application stays running.
In Ubunbu 10.10: the window does nothing for a second while the disk churns, then the window disappears. When you ask to see your broadcast messages again, you wait a few seconds and then Gwibber appears. That’s because Gwibber was stopped when you closed its window, and is now reloading.
That’s a huge regression in user experience. Exact same thing with Rhythmbox.
Design-wise I fully agree with your post. “Quit” should not be part of the workflow of (almost) any program. It’s the implementation that bothers me. The question Canonical engineers need to ask themselves is: why are we trying to solve a problem that’s already well solved by swapping? Systems without swap are a tiny minority, and it makes sense to create specific logic for them. The vast majority will get the best user experience from using swap, rather than simplistic “quit whenever the main window is not visible” logic.
The best solution is: when in doubt, keeps applications running. Let the kernel optimize use of RAM vs disk. Then implement a kernel-userspace bridge so when running out of memory, userspace gets to decide which application to kill. When the OS decides a program should quit, like the Gwibber example above, put it at the head of the queue instead of actually quitting.
> Then implement a kernel-userspace bridge so when running out of memory, userspace gets to decide which application to kill.
I was impulsively going to reply something about how this would create all kinds of security issues, but actually it would be great to have this kind of functionality, and maybe you can risk it on a quasi-single-user desktop system.
How does this work on Android? Does userspace get a vote there when you run out of memory?
Before posting a piece like this, I rewrite, and I rewrite, and I rewrite to make it as clear as I can. But I always know that someone, somewhere, is going to read it and get completely the wrong idea.
I did not say anything like “the OS should ‘take over the decision’ when applications are started and stopped”. For Ubuntu to do that would be an interesting idea, but it would require applications to use APIs that, as far as I know, don’t exist. And as far as I know, Ubuntu doesn’t quit any applications externally, except at logout or in the out-of-memory case I described.
Any change in Gwibber’s or Rhythmbox’s behavior between Ubuntu 9.10 and 10.10 should be taken up with the developers of those applications.
I don’t understand what this article is suggesting, then. How do you want to “remove” the quit option from every application in ubuntu? Will you just publish some guidelines like Gnome’s HIG, telling application developpers to remove this option from their “File” menu? Will you patch ubuntu’s default applications? Will you automatically remove it from the global-menu?
I understand the use case of allowing an app to stay online when its main window is closed (with the messaging menu etc). But I don’t understand how do you plan to support the opposit use case: Now I’m done with it, I don’t want to just close the view to the application (its main window), I want to QUIT the application.
Maybe I’m going out with my laptop and I don’t want my mail app, Ampathy, Gwibber etc to try and check for new messages.
Maybe I’m on a laptop (again), and want to quit ressource-hungry apps to focus on one task while keeping enough battery.
etc… You’ve answered the questions about using all the memory available and being able to start apps fast if they have been kept running, being clear about what we are closing (a tab, a window, but not some unrelated windows like webapps in Firefox, a spreadsheet when closing another document, etc), which are all strong arguments. But I would like some explanations about other arguments like not eating all the battery, etc and how you plan to implement it.
Is it just an idea, or is it something that will be implemented in Natty or Oneiric?
In order to make both of these points of view co-exist, Ubuntu is in the perfect position of providing a solution which delivers two different configurations to please the requirements:
1)One proposed configuration could do exactly as you wish to hide the details from the user and let the user fill up all the system resources to the max. Call it the New Standard GUI Mode.
2)Another proposed configuration could do exactly what the control freaks like. Add the necessary “advanced user” window/menu decorations/buttons for access to the ugly kill and graceful quit API’s. Call it the “Classic GUI mode”. This is akin to VUZE’s GUI that has new and classic with extra settings for both to target beginner/intermediate/advanced.
The above names of the modes intend to prevent ruffling any feathers by avoiding the “new user/intermediate user/advanced user” descriptions.
This solution would please both parties on legacy and new hardware, mobile or not. It places the decision back to intended user where it should be. I’m not a big fan of Governments and Institutions making decisions and imposing laws on it’s citizen “for the sake of the greater good” without my consent before hand. This approach falls in line with that by letting the community decide. The users themselves decide which window manager/GUI/performance features they want enabled.
To close-reload or quit-kill, that is the question?
Perhaps the sound menu should only show the preferred music player by default?
I know my system has at least rythembox and banshee installed and I don’t want to have 2 play buttons in the menu all the time
Aha! I’ve been wondering how all this inconsistency was going to get fixed since the indicator applet grew in prominence! I must admit I am pleased with these musings. And I appreciate the consideration for those with large libraries to be scanned on startup (The conversation in Ayatana’s mailing list regarding the issue had me a little worried).
I imagine that if the player needs to be reloaded when using the sound indicator there will be feedback (a throbber?) telling the user that it’s thinking first?
Also, the possibility of having the computer keep applications alive for a while until it’s obvious the user doesn’t want it is excellent. I think it’s a great idea to have my Banshee silently quit after fifteen minutes without my love and attention. If I remember how much I love it and want to use it, BAM, it acts like I never abandoned it.
These concepts essentially eliminate the ideas of an application ‘launching’ or ‘quitting’. They’re merely there.
The tough part is finding out WHEN a user has officially stopped using the application. It’s silly to have the program close super-soon after the person has used it (especially if one has the resources). It’s equally silly to have the program stay running forever and ever (My girlfriend’s macs are very often bogged down with 10+ applications running all at once).
Gr, somehow I ended up replying to you, Jason Taylor. Apologies, I borked something!
One idea is to terminate apps faster when on battery and let them run longer when on AC and when you have lots of free RAM/CPU.
A most incisive article – very much food for thought and when one thinks about it, it is something that is well overdue for some solid debate and understanding. Well presented, thank you.
..Phil – Perth, W.Australia
Hi there. Sorry to lob a tangent into this very interesting thread, but I was wondering if there was an update on the monospace version of the Ubuntu font – specifically, if it’s still in the plan for Natty. The several-months-ago thread on it hasn’t had a response:
http://design.canonical.com/2010/11/the-monospace-is-coming/
Hello JP! I’m sorry that there haven’t been many updates to that article for a couple of months—I think the status is still reasonably accurate! The wonderful thing about the Monospace is that because all of the characters are the same width and there’s no kerning (overlapping of pairs like ‘AV’ or ‘Te’) it will be possible to retrospectively fix the design of any particular characters that aren’t correct and do so easily.
Ubuntu 11.04 is a time-based release while the Ubuntu Font Family is trying to be sensitive to quality; with several of the fonts we were wishing to get them out for Ubuntu 11.04 but having rushed I fear that we’ve tripped up and will have to look a bit harder (which of course takes time).
Specifically on Ubuntu Mono, the shape of (most) of the glyphset has been fairly stable. The major blockers at the moment are working out what level of scaling (if any) to apply so that the Ubuntu Mono works with the regular proportionally-spaced Ubuntu (Bug #727733 “Technical: Mono: discern level of scaling to fit in terminal cell”). A monospace requires internal leading so that it can butt directly up against its neighbouring cells (Bug #724022 “Wishlist: Enable use of Ubuntu Mono as .psf console-setup font”) for box-drawing and the partial-shading blocks. These need to be got right first, because of the huge metrics implications.
At the moment the phased-beta process for the Monospace is on step 2 of 4 (internal Canonical testing) and about 80 people have been testing various interations in normal use, although only one of those is making any heavy use of the Cyrillic monospace and I don’t know anyone know is testing Greek monospace on a day-to-day basis.
It should then move on to wider public beta test team for a better shakedown. Have a look at the “mono” milestone bugs list and see if you can add thoughts to help it get there! Expertise help is always valued.
Excellent – thanks for the update!
hmmm, “quit” sounds so antiquated.
So, I might be misinterpreting this, but here’s my two cents.
My primary computer is a desktop with 4gb of RAM, and a dual core 2.8ghz proc. On that computer, I completely understand your argument. It has enough processing power and spare RAM to handle leaving a few processes open when they’re not being used, or even to leave a co-process open for the express purpose of launching the main one (example: OpenOffice taskbar notifier). Eliminating the Quit command on that computer makes perfect sense.
However, my secondary computer (a laptop, that accompanies me a lot) is running on a measly 2gb of RAM and has a single core 1.6ghz proc. I can barely run Chromium, GIMP, and Banshee at the same time without a bit of lag on that. Damn, I can barely run chromium /alone/ with more than 10 tabs open and not get lag. Quitting programs to free up memory on that computer isn’t just a feature, it’s nearly essential.
I got rid of the Messaging menu via apt-get remove for the sole reason that I never use it. It was sucking memory (even just a little bit) and if the interface is (imho) too clunky for the average user, then what’s the point? I guess that’s another topic though.
My point is that while eliminating the Quit command on medium to high-end computers makes the computing process much simpler and faster, on lower-end computers it might render the computer nearly unusable.
Anyway, that’s my viewpoint. If anyone wants to correct/comment on this, please do.
Remember, the Lisa didn’t need “Quit” because it had one whole megabyte of memory. http://www.guidebookgallery.org/videos/lisachi98
Your secondary computer has a measly two THOUSAND times as much memory as that. Of course software is getting larger too, so you could keep making that argument about “lower-end” computers forever, but at some point we need to say “enough already”.
Don’t force this, application developers will always want to use the latest technology and space available to make the best experience. Can’t you freeze the app instead? Maybe make room for simple processes running for notices etc.
I don’t think forcing the user to leave applications open and hog resources is a good solution. I’d like to hear your thoughts on this.
Please note that the term “resource constraints” includes not only the main memory but also, for example, *battery* life. Ten or twenty processes running at the same time may easily be a huge difference.
Should we make ‘Quit’ and ‘Close’ behaviors consistent and predictable? Yes. Should we leave users without the ability to *choose* whether free up resources? I don’t think so.
What impact on battery life does running the hard disk to swap out pages have? I’d say using enough memory to swap is draining the battery.
A running process clearly needs not only memory space, but CPU power and I/O access (that is energy consumption) as well.
That said we could freeze processes when closing the last window and no task in the background is strictly *required*, forcing a clear behavior.
Understand too that the Lisa had applications that were designed for it, and could utilize resources from ROM or whatever else. I’m sure if you ported a Lisa Application, along with the OS and other goodies, you’d probably use more than the one megabyte that the Lisa had. And those applications were designed to work together quite nicely, as opposed to Firefox, Rhythmbox, and the like.
The point is that people’s actual experiences of current software on this convincingly over-powered software does actually involve processes that (gradually or slowly) run away and hog system resources. It’s critical that a design decision like this appreciates that that’s a fact of current software experience, or an apparently courageous decision, with good insight into how things should work, can be based on only half the facts and therefore flounder.
Interesting perspective!
Applications will always seek to do more if you give them more resources to work with.
It’s an interesting article but I’m not convicned yet.
Something is (more) intuitive if someone with no experience of it can come along and figure it out quickly. As another poster pointed out: you are listening to the player, quit it but it just disappears and now go looking for it: this is all but intuitive.
Next one: so now you know about the soundmenu. You go to it, because want to check out something quickly, click on the item, it appears, click again and it does NOTHING, you have to go all the way to the other side of the screen to close/quit/minimize it. This is all but intuitive and efficient. Just about any other solution let you minimize/maximize from the same place: panels, windows corners, launchers, etc.
Some of your decisions are hard to argue against: integration with top panel, new scroll bars, etc and seem very genuine improvements. Some other decision are hard to understand.
There has been a shift in ubuntu lately: up until the last year or so it was undeniable that ubuntu was getting easier and easier for everyone’s grandmother. And now it is coming up with solutions that are disconcerting us “hard-core” users. Why is this?
Currently, clicking an application item in the Unity launcher never minimizes it; it only ever launches or switches to it. If that changes in future, I agree it would make sense for player items in the sound menu to change accordingly.
Yes, not being able to minimize from Unity launcher is the other BIG grievance. It gives me hope that changing this behavior is a possibility for the future. I’m still trying to come up with just one argument to justify such thing.
Regards
“Phone and tablet operating systems, such as Android and iOS, have abolished the ideas of “quitting” or even “closing” applications altogether.”
Err, no. iOS reintroduced “quitting/closing” individual apps when they added multitasking. Prior to that, you’d quit the application you were running by returning to the home screen.
Overall, I don’t like the idea of removing quit. I’m having to quit applications all the time because I keep running out of memory, and I’ve got 4 gigs! That said, 90% of the time, the problem is Firefox…
Apple’s Web site describes quitting an iOS application as being a troubleshooting step, not as something you need to do normally.
As a troubleshooting step, is it more desirable to have developers carry it out than make it a UI-based edict (Canonical to dev community: make Quit meaningful, or drop the command) instead of making users into casualties? Nevermind Apple, that’s the kind of crap I expect from Microsoft (MS Public Rep: “Don’t like the Ribbon UI? Then you’re a dinosaur, like it or stop using it.”) At least from the dev side, if an app sees no windows open (in most cases: banshee, daemon-launchers, and the like being exception) it should unload itself from memory… the assumption the user makes on closing windows doesn’t have to be an assumption at all. If Canonical simply carries out a UI hack to remove the Quit command, well…
There’s already been a bit of backlash that Unity brought to the table (imagined or real, consider the decision of many distros to either keep Gnome 2 downstream of Natty or switch to Debian Squeeze. ) It may not be the vast majority, but it is significant.
Asking your users to carry the weight of a dramatic change should be done incrementally. If you want to sting users out of the Quit command, 11.04 was your best opportunity to consider that change.
Quit and Close are VERY consistent in Mac OS X, they work always the same and they are wonderful. Windows and Linux lack that consistency, every program reinterpret what quit and close means; and that’s the reason it is a mess and a source of frustration. BTW, iOS didn’t remove quit, it has a consistent quit and close.
I’m glad you are trying to fixit this long problem in Ubuntu, but removing Quit is a bad idea. Put Quit and Close in a CONSISTENT place, that’s all what we need.
Quit and Close are ridiculously inconsistent in Mac OS X. Even in the applications installed by default, Calculator, Dictionary, Font Book, and Image Capture quit when you close their windows, and have “Close” in the “File” menu; App Store, DVD Player, iSync, Photo Booth, and System Preferences quit when you close their windows, and have “Close” in the “Window” menu; Address Book, Automator, iCal, iChat, iTunes, Mail, Preview, QuickTime Player, and Stickies stay running when you close their windows; Chess has a main window where “Close” is completely disabled for no obvious reason; Safari alone puts up a confirmation alert if you quit with two or more windows open; and Finder, being the file manager, is alone in not having “Quit” at all. It’s a trainwreck.
Wow. It took almost 15 years…
“Quit” has always meant (to me): stop using my limited resources (CPU/bandwidth/memory/disk access)!
This is why I detest applications that “minimize” when I click the close button. Close (to me) doesn’t mean “go hide somewhere”.
A lot of ideas in this area only address one limited resource (memory) and completely ignore the other limited resources that are consumed by background applications.
I would also argue that CPU and bandwidth are more important than memory is. Memory can be swapped out, at the very least. CPU and bandwidth don’t have an equivalent mechanism.
Yes, what I suggest is that a real quit always is an accessible option and that there would be a hide option.
But I’m quite confused myself of how to implement it. Four buttons in the window title bar? Minimize, maximize, hide and quit? Maybe that’s the only same way to solve it in some cases.
And use minimize to tray as default for software of the kind like music players and IM, where the main interface only is a “control board” and you are likely to want it running continously. I really don’t think that the quit option ever should have the effect of just hiding something. Although I am actually used to closing Pidgin’s contact window by clicking the X resulting in it hiding in the tray instead of quitting.
Whenever there’s a chance that the user might want to quit OR hide something, BOTH options should be available.
Allowing users to terminate an application is one of their most fundamental rights, and taking that right away seems like terrible design.
this is just a justification for the Me menu and Sound applets horror. First they fu## up the close/quit by replacing with hide in an obscure place and now they want to justify that move.
Oh, the fact that Canonical doesnt produce a phone or tablet operating system (yet) is irrelevant, again.
I’m surprised that it hasn’t been mentioned that this is somewhat similar to the direction that Apple is taking in Mac OS X 10.7 “Lion”. They’re also planning to eliminate “Quitting” in new applications, although not quite in the same way: They’re planning to have applications automatic save their state and allow the OS to terminate them when they’re in the background and the resources they are using are needed elsewhere, and then restore their state when the user actives the application again. This has the similar effect to this proposal of users only needing to worry about what they’re using, not what software is responsible for it.
Glad to see multiple OSes working towards paradigmal changes of this sort. It’s difficult to say in advance which will end up working out the nicest but if nobody tries we’ll never get anywhere.
Completely nonsense.
When I close a window, I really mean “quit”, not hide, nor go waway, but quit, exit, stop running, die, kapput.
For hidding windows but keeping applications running there’s the “minimize” button. Please, don’t second-guess me. If I say quit, just quit. If I say hide, just hide. Any other path leads to madness.
And BTW, confirmations are a clean sign that you can lose information, nothing else. It sometimes happens that I WANT THAT INFORMATION LOST.
I agree with this summary…
A great way to sum this up.
I generally use three Firefox windows with related tabs (one for monitoring, one for general use, one for webmail/webapps) plus the occasional short-lived windows.
If I use “Quit” I find all my windows/tabs again when I restart the browser, if I quit Firefox by closing all the windows one at the time I only get back the last window I closed.
So if you’re going to remove “Quit” what the hell I’m supposed to to, open everything in a single window? ‘killal firefox-bin’, potentially leaving it in a disrupted state?
Nothing is “simple”, by removing things you’re losing, not improving.
I totally agree with this. I also use firefox consistently with a lot of default and some varying tabs and want to be able to close them all at once to get them all back the next time (I use Session Manager to help me with that as well). (Or to enable an update or a new addon for example.)
Also: although I have a 8GB RAM quadcore machine, I still prefer not to use all my CPU all the time, simply because more CPU use means more power use, which costs money and isn’t preferable in terms of sustainability. So I want my quit options. Perhaps behaviour could be made a bit more consistent and intuitive between one application and the next, but removing the option altogether is not a good idea. (And I would move away from a distro/window manager which takes the option away from me).
Yup, I LOVE Session Manager. It has helped me on several occasions.
You omitted to mention why you’re quitting Firefox in the first place. Nothing about removing “Quit” prevents an application from reopening all the same documents the next time you log in.
> You omitted to mention why you’re quitting
> Firefox in the first place.
Maybe because update-manager told him he has to do that in order to surf safely?
Or because Firefox memory got fragmented or there is a memory leak in some extension or such a reason.
Session Manager!!!!
https://addons.mozilla.org/en-US/firefox/addon/session-manager/
This is a very interesting point of view and to be honest I’m sort of like it. But removing it directly would be a migration flaw. Please first solve the issue first, that every time I login that I need to start my mailclient and IM-client and god knows what of basic services. Windows with Communicator can do this for years now.
The other thing that needs to be done, is to make application not handle multiple documents at the same time, but just one document. For this would break things liked LibreOffice for now and some tabbed applications if we’re not careful.
Removing the quit option is a way forward, but only if other design issues are being solved as well. I think simple-scan may be an example, where a wishlist item is to just to be able to close simple-scan and continue where you left. Something like Android apps, where they need to be able to be stopped. I see design requirements coming for a general and solid caching solution for application data on a device.
But again, I think this a good idea in the long run.
“make application not handle multiple documents at the same time, but just one document”
That would be a seriously bad idea – why would you want that??
1. You are assuming that everyone always has memory, disk bandwidth, battery capacity, and CPU power to spare, and ignoring the existence of popular low-end machines (netbooks) and popular resource-intensive software (modern games, compile jobs, etc). On a single-core 1.6 GHz Atom, making Linux usable means using the “quit” button frequently. Requiring a user to use the system monitor every time she wants to quit an application would be terrible user experience – instead of a menu item, she would be required to launch a new application and look for the process she wants to kill (whose name is likely not the one she sees in the window title bar); and leaving the system monitor always running isn’t a great option either – drawing all those pretty graphs takes CPU and memory.
On my reasonably fast desktop, when I am running a 3-hour compile job (a pretty regular occurrence), the 15% of CPU that Firefox+Flash take up suddenly matters. I want to have an easy way to quit resource-hogging applications to maximize the resources dedicated to the compile. The same is true for a gamer who wants to maximize his FPS and doesn’t want applications that he isn’t currently using taking up an appreciable fraction of the system’s resources in the background.
2. You are ignoring software updates. When I install a security update for Firefox, I want to be able to “quit” the browser and start it again (with the built-in session saver restoring all my windows and tabs), so that the security holes are fixed. I assuredly do not want the package manager to kill the browser for me (I may be in the middle of a long download or writing an important message!); instead, I expect to be able to reliably and easily do it myself at the time of my choosing.
3. You are ignoring the real need to close a whole bunch of documents at once. When I am working in the GIMP, I usually end up with a dozen windows open – for various versions of a picture, one-off experiments, samples, and so forth. When I am done, I want to be able to get rid of the whole mess with one button press. Clicking on “close” 12 times is really a suboptimal user experience in this case. And them open until the next time I reboot is an even worse user experience – they take up *a lot* of memory and clutter my alt-tab window list.
4. Worst of all, you are implying that Android UI design is somehow relevant to the PC. Android is designed for devices with small screen sizes, and so lacks the ability to display multiple applications on the screen at once. As a result, working on the same task in multiple applications becomes highly inconvenient, and Android users rarely do it; so leaving it up to the OS to decide when to quit an application makes a lot of sense (if a user hasn’t looked at an app in the last minute, chances are, he won’t be needing it in the near future). By contrast, on the PC, tasks that involve multiple applications at once are the norm, not the exception. This means PC users *need* a powerful window manager, a well-designed task switcher, and a way to manually manage application lifetimes, since the OS cannot possibly predict which applications the user will need when.
1. “Requiring a user to use the system monitor every time she wants to quit an application” bears no resemblance to what I wrote. Most applications will still exit when you close their last window, just as they do now.
2. I maintain the specification for how Ubuntu’s software updates should be presented, so you can be sure I’m not ignoring them. Perhaps you have forgotten that when Firefox has been updated since it opened, a banner appears inside the Firefox window inviting you to restart it.
3. Closing a bunch of documents at once is an interesting use case, but closing every document that happens to be open in an application is not a reliable way of addressing that use case. You may also want to keep open unrelated documents in the same application, and/or close a related document in a different application. One example of a better solution might be a “Close All” command for windows in a workspace.
4. I’m not sure that “tasks that involve multiple applications at once are the norm” on a PC, though I agree that they’re much more common than on a phone or tablet. http://ignorethecode.net/blog/2011/03/04/multitasking/ But I don’t see how it follows that “the OS cannot possibly predict which applications the user will need when” (if the application currently has open windows or other findable tasks, that’s a strong clue), or how that leads to “PC users need … a way to manually manage application lifetimes”.
1. In a comment above, you recommended using the system monitor’s kill function as a replacement for the quit menu item. Yes, most applications will close when you click “close” on every single document you have open. But if anything, repeatedly clicking on “close” is even less convenient than using the system monitor. This is the reason why I never use Epiphany: it lacks a quit command, so getting rid of it to free up resources gets far too annoying once more than 2 or 3 tabs are involved.
2. And if I have updated a vulnerable plugin (Java, Flash) or a vulnerable system library that Firefox links against (libjpeg, libpng)? And Firefox is certainly not the only application on the desktop that is a potential target for attacks. For instance, do Evince and Okular show a restart banner when yet another security vulnerability in libpoppler is uncovered?
3. Unfortunately, a “close all windows in a workplace” command wouldn’t be the right solution, because, at least for my workflow, there are also other applications in the workplace (a terminal with a bunch of tabs and lots of state, some nautilus windows) that I would not want to close after finishing processing images. The ideal solution would be some way to tag a group of windows as a “task”, independent of the workplace involved, and be able to close them at once. However, until such a functionality is implemented, the good old quit menu item is the best approximation.
4. Tasks that involve multiple applications at once are the norm. Programming = lots of terminals + several gvim windows + devhelp + firefox. Writing = lyx + terminal + lots of evince windows + firefox. Working with images = lots of gimp windows + nautilus + terminal + inkscape. Gaming = game + spreadsheet + firefox + voip…
A system’s resources (memory, CPU, disk and network bandwidth) are finite. If you deprive users of a way to easily manually quit applications, the system will soon enough end up with too many applications running at once, and will have to decide what to kill to free up resources. On an OS that’s designed around single-application use (e.g. Android), the OS can simply kill any apps that haven’t been used recently, and the user almost certainly won’t notice. On an OS that’s designed around multi-application use (e.g. desktop Linux), there is no good way to decide what to kill. (If you don’t believe me, google for the history of the OOM killer: two decades have passed, and we still don’t know the best way to tune its heuristics.) You cannot simply kill an application that the user hasn’t interacted with for a while because (a) it may be something that the user expects to continue running and processing in the background (a terminal with a compile job, a video transcoding application doing its thing, a download), or (b) it may be something that the user has minimized for the time being but still expects to be available instantly, and that cannot be painlessly restored after being killed (a web browser with a few dozen tabs will take appreciable time to restart, and the user may not appreciate the resulting network and disk activity). So desktop Linux cannot automatically decide what applications to kill when, and therefore must provide the user a way to easily do it manually – the quit command in each application.
1. You are mistaken: I did not mention the System Monitor as a replacement for the Quit function. I mentioned it as a way to “quit buggy processes that have gone runaway or if you have pre-presentation paranoia”. In both cases, a “Quit” menu item would be ineffective: in the former case the menus would be just as unresponsive as the rest of the interface, and in the latter case there would be no menus at all.
2. I disagree strongly that users should be expected to know that a libjpeg update requires restarting Firefox, or that a libpoppler update requires restarting Evince. And if they shouldn’t be expected to know that, the message that explains that they need to restart a particular application — wherever it appears — can itself provide the button for restarting that application.
3. I didn’t say it would be “the right” solution, I said it would be a better solution.
4. I’m not sure whether you actually believe that programming is in any way representative of “the norm”, that working with images normally involves a terminal, or that gaming normally involves using a spreadsheet. http://eeggs.com/items/29841.html But in any case, you are still apparently under the impression that it would be the OS deciding when to quit an application. I did not say anything remotely like that.
> you are still apparently under the impression that it would be the OS deciding when to quit an application. I did not say anything remotely like that.
Okay. So when the system is getting sluggish and running low on resources, the OS won’t (unlike Android) pick some applications to kill for you. The user, under your proposal, can’t do it either (you’ve taken away her quit button, and you say that you don’t expect her to be using the system monitor’s kill functionality).
Then please tell me, who decides what to kill and then does the killing, who frees up resources, who ensures that the system remains responsive? Who makes certain that the system does not swap or do too much disk IO at once to avoid the infamous kernel bug #12309? Who is it that gets rid of applications that the user is not interested in so that the applications that the user is interested in run sufficiently fast for the user’s needs? Do you expect Archangel Gabriel or Linus Torvalds to descend from the skies and do it?
PS. As for games and spreadsheets – I wasn’t joking. When playing RPGs, I find it to be quite useful to have Gnumeric open for comparing the stats for a large set of items or possible setups, or for figuring out which course of action would be the most profitable.
Why would you want to model your UI after Macs/OSX? They have the worst UI design on the planet.
Retiring “Quit” will make Ubuntu less like Mac OS X, not more. But as I’ve said before, that’s not the reason we do things.
Er, okay. Way to fix what is not broken, I stopped using *buntu a long time ago and every now and again I see things like this and it makes me laugh. Way to spend time engineering useless things!
So basically you came all the way around from somewhere to troll?
Goddamn! The problem is void, really.
Just expand the menu items or button’s captions, changing these to “Close this document” and “Close all documents and app”, like it was long ago done in StarOffice.
And use informative dialog window with list of opened documents:
“you’re about to quit (app name). It have the following documents opened: (list of docs). Are you sure you want to close all these docs simultaneously?”
More, this “good-bye” list may be extended with the possibility of closing of individual docs within that list.
I think there is should be something like “process manager” for opened docs per application: it should display all opened docs and provide a way to do different things on these docs, like “process manager” allows to do something on running processes.
The complexity of your suggested confirmation alert is an excellent example of the principle that a confirmation alert indicates the design is broken.
A process manager that shows Amazon, eBay, Facebook, and Gmail but not Banshee, Calculator, Empathy, or Shotwell would be just as awkward as the “Quit” command is in the same situation. If you really want one, though, Chromium/Chrome has a Task Manager “for nerds” already. (That’s an excusable case, because it helps nerds to see that it’s a particular Web application or plug-in that’s consuming CPU and memory, rather than the browser itself.)
It was a very rough sketch, written in seconds just to portray an idea itself, not detailed specification neither blueprints.
More, “f*ing nerds” [(C) IT Crowd] mostly know the difference between “quit”, “close” and “close window and go TSR”, because they do not rely on first impressions, they exploring the software to make themselves sure that the button pressed is doing what it intended to do.
But usual users have no useful habits of, and not inspired with the spirit of exploration. They aren’t interested in knowing the underlying technologies. They believe in first look impression and will not even think different.
I’m the sysadmin (one of 5 IT specialists in local place) in small office with about 200 PCs and 10 servers. And I have everyday observations on user’s behavioral manners. They, the users, aren’t stupid – my ones are perfect electrical engineers, el.power traffic controllers etc… And they aren’t interested to be experienced omnipotent gurus. They just want to do their job and to be sure that the PC will cooperate them. For example, providing (may be annoying, but easy to turn on/off) reminders for potentially dangerous actions.
IMnsHO, there should be used approach like the same SO/OOO/LO uses for its help system: it allows to use short or extended help tooltips. I’m with computers since 1986, but when I started to use SO5.2, I turned extended help tooltips on in order to see the EXPLANATIONS, not the brief HINTS.
Similar approach may be used in GUI: short, cryptic, abbreviated names and titles for experienced users, and longer, extended ones for beginners.
Yeah, I know that such dual-GUI will require enough overhead. But it is also a sketch, not a finished picture.
More, I’ve double-quoted “process manager” because the proposed window MAY look similar to “PM”, but will perform very different task. I just don’t know more appropriate name.
If you want Amazon and Ebay to be on the same level as Banshee and Calculator, why does Unity only show one launcher item for your web browser regardless of the number of web browser windows open? In other words, when a Banshee and a Calculator window each get a separate launcher icon, why do an Amazon and an Ebay window get grouped together in one browser icon? What’s the difference?
Who prevents you off launching Amazon & eBay as separate web-applications in order to give them separate windows and launchers? For example, using PRISM?
Nothing prevents that, but my question was about a perceived inconsistency in the presentation the Canonical design team is pushing…
Unity engineers are concentrating on getting the basics done first. Meanwhile, though, designers are investigating better integration of Web applications for future versions.
The line along which you are thinking about the problem is fine. There is some redundancy of the Quit function in many cases. However, the line along which you are thinking about the solution does not seem quite right. There are a few important issues to consider: -
1. Consuming resources like memory unnecessarily simply because they are available is a bad idea. It leads to the ever increasing software bloat and forces users to keep investing in increased hardware power. This practice is typical of proprietary software houses and should not be followed by free software, one of the promises of which is to allow complete computing capability to all users regardless of their circumstances.
2. Your proposed solution also may not be compatible with or may cause confusion during the use of applications that use alternative GUI frameworks such as Qt. Similar cognitive problems may occur for users using different desktop or window managers (GNOME, KDE, *box …) at different times. Also, the same application can run under different desktop environments, aggravating the problem.
Of course functions like checking mail when no mail window is open need to be present, but creating a cognitive gap to implement such features is not a good idea. Doing so at the expense of hardware and thus monetary resources is even worse. This needs much more thought. You might consider alternative ideas such as renaming the various quitting functions, incorporating a separate menu item and title bar button for hiding a window (and optionally a visually distinct area on the panel for such windows), etc. Whatever you do, I hope the engineering teams will not hasten with drastic structural changes without sufficient forethought.
Regards,
Saurav
Thanks for your thoughtful comments.
Memory that isn’t being used does no-one any good. What is important to minimize is the amount of swapping, not the amount of memory in use. It’s nothing to do with whether the software is proprietary; that’s an association fallacy.
Difficulty in implementing things in other toolkits is an example of the problems of toolkit proliferation. http://design.canonical.com/2010/05/menu-bar/#proliferation And if we hesitate in doing something because other platforms haven’t done it, it will be difficult ever to be better than they are.
I’m sorry to hear this. This simply leaves users with limited means in the lurch. I’m from a country where this still is a reality in many places. Software like Ubuntu promised to bring affordable computing to the masses. Ubuntu still consumes lesser amounts of resources than its proprietary counterparts but that advantage appears to be disappearing slowly, and I don’t think this is an association fallacy. Besides, having control of memory usage is an important ability for the user in some other cases too, such as when the computer is used for resource-intensive tasks like scientific computation.
As regards the second point, I had expected better commitment to the integration of the various available tools from GNU/Linux development teams.
I don’t mean any offence here and the continuous improvement of GNU/Linux spearheaded by the likes of Ubuntu is definitely a praiseworthy attempt but I’m posting this because, to be frank, I’m somewhat disappointed by your reply.
Regards,
Saurav
MPT’s reply makes sense: Why are you calling it bloat if it’s optimizing the resources used on the computer? If anything, it will reduce resources because you won’t have to unload the RAM immediately after closing the program.
You know, the Linux kernel actually caches to RAM very aggressively take a look at how your RAM is being used. If it’s got room, it’s cached. Are you going to stop using Linux entirely because it’s too bloated?
Caching at the kernel and userspace application levels differs considerably. Please do not assume that the weight of the data the kernel has to cache is equivalent to the weight of the data that needs to be cached from the userspace (and graphical) applications, especially when the latter has to go through many more levels of indirection. It is quite obvious that keeping huge things around in memory is going to cause more swapping if the user runs multiple unrelated programs either simultaneously or in quick succession. Microsoft Windows takes this approach and I think you know well enough what the gargantuan amounts of RAM present in contemporary PCs are used for. GNU/Linux can currently run on computers with half a gigabyte of RAM or less (think mobile phones) and can do animation without a 3D card. And if we want to use the RAM to simultaneously run multiple resource-intensive applications, it allows that too. If they can keep it that way while still keeping apps in memory, I have no problem.
Regards,
Saurav
People mostly seem to be ignorant of the nature and effects of loading and unloading programs to and from memory. The following illustrate some common perceptions: -
http://androidforums.com/g1-support/8659-closing-browser-app-screens.html
http://www.google.com/support/forum/p/Android%20Market/thread?tid=7d7fed04181f1406&hl=en
@Suarav as the reply tree has run out:
Very good points. But it seems that _Linux_ can and should run on all devices big and small. Ubuntu is not designed to run on a calculator, it’s designed for the desktop, server, and mainstream-mobile market (netbooks, tablets). These all have very sizable RAM sizes. Half a gig doesn’t really work with any modern OS anyway. I have a friend that uses Lucid on her half-gig and there’s still quite a bit of swapping despite my disabling many services.
I do recognize these dangers but I have faith that they will be properly executed. Many ayatana designs have been met with the same apprehension but in the long run they really have helped define a solid Ubuntu user experience.
My last comment never made it through moderation although it was purely a technical one. Don’t know how this comment system works and don’t know whether this one will make it.
As I pointed out, the sizeable amounts of RAM in modern PCs are not actually necessary for a GNU/Linux GUI. As far as performance with low amounts of RAM is concerned, there are always varying results. I have seen (K)Ubuntu and some other distros running smoothly with 3D effects on old PCs with around 512 MB of RAM. Still, as I said, if it doesn’t hurt performance and allows enough control to run heavy apps simultaneously, I’m happy with it.
This is blind faith but I’m confident that they would do serious testing to ensure that all use-cases are properly appeased. I don’t find your concerns unfounded by any means: I too would be disappointed if it worked out to ruin the experience.
But again, I am confident.
No one has mentioned that some programs fail to hibernate. Its not predictable that just because they hibernated yesterday they will again today.
Several of the above commenters have given valid reasons why one may want to keep control of what is loaded in memory.
I want to keep that quit button on every application so I can say to a program GO AWAY NOW.
I do not want the program to just hide its interface. That is not responding to my clear message QUIT.
Keep both quit button and the close button. They are different things. Overloading them with the uncertainties you propose is daft.
It’s not clear why you think this issue has anything to do with hibernation.
You can’t “keep that quit button on every application”, because hardly any applications have a quit button to begin with. Those that do are mostly from the Gnome 1.x era, where application designers sometimes put a quit button in the toolbar when they had little else to include in the toolbar.
Let me explain, if possible.
1. some programs blocks hibernation with warning (like Rythmbox player, if I’m not wrong) or silently.
Imagine: power outage. Sound speakers aren’t plugged into UPS because they aren’t important. So, they dies, while battery-powered PC continues to work. And Rythmbox continues to send the chords to died speakers.
You pressing “hibernate” button and move yourself to another place. For example, to take a coffee break. Or to shut down some other systems. You’re ensured that your system sees its computer sheeps.
After the power restored 30 minutes later, you will find the depleted UPS and “lost clusters” because of hard poweroff.
And it is because Rythmbox hides its window on pressing “close” button on its window.
2. No one talks exactly about “quit button on main toolbar”. It may be menu item, window manager button or something else.
As far as I can tell, you’re describing a bug in Rhythmbox, not a design issue.
Nope.
The problem is: if some program closes its winmdow(s) and goes TSR (excuse me this DOS-style term) after “X” button pressed or “close” command selected, and it will prevent hibernation/suspension, this program may lead to different problems.
Rhythmbox is only first example.
BTW, the author of FCM Notifier (www.fullcircle.org) did the right thing: after user presses the “close” button in program’s window, there the popup reminder appears: “it will close just a window, the Notifier will continue working in background”.
This reminder can be [en|dis]abled by user.
I found it is the best possible approach: let user know what exactly will happen.
While you’re at it, could you please make Ubuntu start every application installed on the machine at boot time. That will make it much quicker to get to apps.
It worked for Microsoft. Didnt it?
[ As for removing "quit"... please make it optional - not eveyone wants their computer to treat them like stupid imbeciles who should never be given a choice about anything because they would surely screw it up - they can buy a mac if we do. ]
“not eveyone wants their computer to treat them like stupid imbeciles who should never be given a choice about anything because they would surely screw it up”
The thing is that’s Ubuntu’s target market, that’s why they come at it like they do. More power to them for doing it, it’s not a distro I use but it’s one I keep a keen eye becasue it’s an important part of the eco-system.
Just a quick suggestion.
I’d quite like it if the indicator applet entry for a program just behaved like another window, with the rule of thumb being “an application quits when there are no more windows open”. For that to work the indicator entry would need to gain a little close button (e.g. to the right of “Banshee”).
This has a few advantages:
1. The application won’t quit unexpectedly and you don’t need to resort to hacks like restarting it and pretending it didn’t quit.
2. It is possible for the user to fully quit an application (e.g to save resources, kill a misbehaving program, stop it checking for messages etc.)
3. It’s simple and consistent
This is the way I see things working currently in Linux:
If the application has multiple windows or runs a daemon, close just closes the current window. If there is a single window and no daemon, close becomes quit. Quit functions the same way no matter what.
I do agree this can seem a bit convoluted. I think a better solution would be to enforce single windows for all apps. (multiple windows themselves are an annoying non feature) Now close functions as quit in all cases besides when applications are running in your notification area.
The other option would be to have close function as quit and have minimize become “hide window”, but then you are either obsoleting the notification area or having to decide between some apps (those without daemons) minimizing to the taskbar and other apps (with daemons) minimizing to the notification area.
Note: As long as you have apps in the notification area like empathy, a quit function to aid in restarting them is quite useful. Using the system monitor to deal with this situation is unintuitive and rather crude.
I think this will be a challenging decision to make and I will be watching ubuntu’s design team with the persistence of a turtle.
Uhmm….
Let’s say you are working on two projects at once. You are editing a bunch of images and writing a bunch of documents at once. You are a heavy user of multiple virtual desktops.
You keep all of your GIMP windows and office windows for one project on one desktop and those for another project on another desktop.
How would you suggest that this would be done with only one window per app?
Personally I prefer adding a hide option.
My suggestion is an icon that resembles the maximize button a bit, but rather like a box with an arrow to a box with dotted lines, as an illustration for hiding the window (making it invisible) but not closing it.
I have no idea if this would be a sane solution for most cases, it would probably need extensive testing to see if users understand it and can handle it.
I don’t think this will be a good idea, if you think your machine is so strong , please try to run these things at same time:
1. OpenOffice.org with 5 documents , 1500 pages per doc .
2. Gimp with 3 4000x4000pixels large picture .
3. Firefox with 20 web pages .
4. A movie player with a HD movie like sintel , pause status.
Then , please open a sintel non-line editing file with blender. and render it in HD quality ! You don’t need to quit the other programs ?
Maybe you do, but the presence of “Quit” would make very little difference in that case. It would still take you many mouse clicks to switch to each of the applications, open their “File” menus, and choose “Quit”. Closing individual windows would have much the same effect.
Hey Matt,
I read the article twice trying to understand if I missed something. I completely get you point, applications should close rather than quit and I’m completely for it. However, Ubuntu also need to provide a way to quit the app and from the discussion so far system monitor seems the only way to do so. So, if I have to QUIT an app do I have to goto system monitor in future versions of Ubuntu?
Also, I’m a little concerned about consistency among apps. Will all apps behave this way in future versions of Ubuntu or will it vary from app to app (like the apps u cited in Mac). If the behavior is consistent, its just a matter of time people understand the feature.
So your suggestion is to close all the apps, and the OS will then terminate them when you start the HD rendering? Then yhe user will see that the computer first will be sluggish AND THEN get responsive as the OS fully terminate the closed apps.
It is not about strong of machine.
“Quit” is so simple,so nature,if I can’t to do it,is what design about it?
is this like Shortcuts on GNOME a long time ago?
In the words of Douglas Adams: -
CHAIRMAN:
Yes, and, and, and the wheel. What about this wheel thingy? Sounds a terribly interesting project to me.
MARKETING GIRL:
Er, yeah, well we’re having a little, er, difficulty here…
FORD:
Difficulty?! It’s the single simplest machine in the entire universe!
MARKETING GIRL:
Well alright mister wise guy, if you’re so clever you tell us what colour it should be!
The ‘Close’ will be take as a ‘Close Window’ while ‘Quit’ as ‘Quit the program/App’
These makes Mac OS X feel very smooth when you are multi-tasking using your day by day apps. I think Linux as Unix are capable of dealing with these processes without problems such as Memory Leaks or Programs Hanging, and my 3 year old MacBook with only 2 Gb of ram has had no problems with that AT ALL (Leopard then Snow Leopard) even using VMWare to run Windows 7 working with MS Office’s Excel setup with 1 gb of ram… BUUUUT!!! I think this “New way of Multi-Tasking” will get new PC Users that are switching from Windows kinda Confused, since they are gonna need to learn all of this stuff along with using the features of the Unity Interface such as the Launcher.
I hope I’m wrong though
You found some arguments pro removing the quit command. But what’s about cons? Several scenarios can be found where software is more demanding than usual. Second, it would be very confusing if not all apps have same behavior. And, most important to me, user might feel loosing control over applications if he or she cannot quit it completely.
I mentioned the issue of control already (“People who have been using computers for a long time sometimes get a sense of reassurance from the idea of controlling application unloading themselves”).
As for confusion from inconsistency, well, we already have that problem. Some Ubuntu applications have “Close” but not “Quit”, some have “Quit” but not “Close”, some have both, and some have neither. We won’t be making it any worse.
Cononical’s hubris continues to amaze me. Every single time they try to improve user-application interaction they do it 100% the wrong way. The option for a user to quit/exit any application is so fundamental I didn’t ever imagine having to defend it.
If I close/quit/exit an application it is because I want that application to stop processing and leave memory. If I want the application to continue processing in the background then I minimize it instead. There is absolutely no grey area.
If I close a music player application why would I ever expect the music to continue playing? If I close an e-mail application why would I expect it to notify me when a new e-mail arrives? If I wanted that functionality I would instruct the application to perform that task.
Why should anybody besides the user ever determine whither or not an application should really close when the user tells it to?
“If I close a music player application” is begging the question. Applications don’t have close buttons, windows do.
Only if you break one of the core features of desktop UI design for the last 20 years by introducing a layer of unnecessary abstraction. The window is the application for any user sitting in front of the machine, it is the interaction point. It doesn’t make sense to break the link between the UI instance and the computer process, it’s an additional complication that will only result in greater confusion and less understanding of the operation of the computer as a whole. The close button should always close the application.
Adding extra layers of abstraction between the low levels of the machine and the fundamental aspects of the UI is a backward step.
If you do get rid of the close button by default please, for the sanity of those of us who like control, please provide a configuration option to return the close button to the UI. Don’t go a Gnome on us and deny us options.
I already provided several counterexamples to the idea that an application should always exit when you close its windows.
I don’t know of anyone who is proposing to “get rid of the close button by default”.
Although I’m not against innovation, I find your idea is trying to convert something simple into something more complex.
It’s about the GUI being as intuitive as possible, I’ve seriously never used File->Quit in any application on all the years I’ve been with computers. For those applications that fork themselves to the background “torrents” first comes to my mind, they have Options to close them when you hit the “X” on your windows manager or to put them in the background when you do so, I fail to see why is this a problem, and for those who don’t have that option it’s as simple as right clicking on the system tray->quit.
A perhaps ultimate solution is just adding an extra button to the Title Bar, so it would be:
Background / Minimize / Maximize / Quit
I’ve seen some applications in Windows (and I think a few on linux too) with this implementation and is not a bad idea. It’s intuitive, you can access it easily and the not-so-savvy users won’t have to tweak the “arcane” options, while still retaining all the possible states of an application without having to reinvent the wheel.
If you have a background concept, why do you need minimise? or in other words just re-task the minimise button as background. Oh look its the same, sensible ui design that has existed for years, because what is minimisation….. oh that’s right backgrounding an app.
It the hiding aspect of windows that is the real area of UI design that could be addressed, currently there are many ways of doing it which aids confusion for the new user:
virtual desktops
minimisation
iconification
tray hiding
depth order
etc…
There is a need to balance simplicity with the ability to maintain groups of backgrounded windows – the stack you are actively working with and the stack you just want out of the way. The above list has evolved because they all fulfill slightly different workflows which are often all desired. The virtual desktop hides windows but keeps them in the same positions, bringing them up in a single click. Minimisation and iconification temporarily removes a single window from view. Tray hiding is for long term backgrounding where occasional interaction is required and is common on multiple virtual desktops.
I’d find it hard to work without the above list, I use all of these window hiding methods daily. If you dumb down the interface too much you’ll hemorrhage users through frustration.
I would be Ok with the decision if you would bring in the function “force quit” in the context menu of the relevant app in unity (like on the osx dock).
If a software crashes, I don t want to go all the way to the system monitor or console to close it, and if a software takes too much resources even when not in use (for example when I do video rendering or video games and I want every bit of available Ram), I want to have a simple option to kill it.
If you want to make things simpler and easier, that is totally OK but don t take away choice and control. You could as already suggested hide options of choice that are to confusing for newbs in the context menu of unity but dont take it completely away. You can never have too much ram!
I’ve got to say, the idea seems a little absurd to me, but I definitely like that you guys aren’t just keeping things around because they’ve always been around.(Like GNOME getting rid of the maximize/minimize buttons
[Sorry, just had to]) I think, if done right, this could really work out well.
The one thing I’d like to say though, is I quite often -want- all my tabs to close with my web browser, and for them to be saved for later use, but I -don’t- want the browser hanging around in memory. Therefore, I will -not- use a browser that does not include the firefox-like quit and save tabs functionality. Quite frankly, I find the idea that you have “ebay, gmail, etc.” open rather strange, as I think of it as “I have firefox open, which has open ebay, gmail, etc.” So instead of what you seemed to be implying (Desktop=>[Ebay,Gmail,Banshee, Libreoffice]) I see (Desktop=>[Banshee,Firefox=>[Ebay,Gmail],Libreoffice]. I’ll admit, “average” users might not think that way, but I do and therefore I will require at least the option of quit functionality, with some items.
Basically, just make sure you guys don’t go on a “REMOVE ALL QUIT!!!” spree. Look at each Application, determine if quit can make sense with that particular Application, then recommend removing quit if it -never- makes sense to have quit for that application. Oh, and make sure you think about how other people might use the apps too, not just the people deciding this
.