That’s it, we’re quitting

I get so frustrated reading blog posts by user interface designers. They almost invariably consist of reasoning I disagree and conclusions I disagree with in support of user interface decisions that make my experience as a user worse. Ubuntu Unity is pretty much an anthology of user interface decisions that are exactly wrong by my perception, and "lets get rid of quit" is just another one. Of all the actions in any menu ever, "quit" is one of the few that I thought confused no one. Then I read something like: "in Ubuntu, we have some elements waiting to help out: the messaging menu, the me menu, and the sound menu" and discover the concept is stuffing functionality into a maze of predetermined slots based on a set of usage assumptions. I don't think any of this is responding to the needs of users, I think its the equivalent of rearranging the furniture in the middle of the night so people trip over the couch when they are walking to the bathroom.

Getting rid of quit/close requires the user to learn entirely new metaphors every time they use a program in order to know how to get a program to stop taking up resources. In a system with effectively limitless resources this is fine, but in lower specced systems, not so much.<p>Also "effectively limitless" means equivalent to the specs of the worst system the designers use, which will likely skew things. Where I'm sitting we share 384K down / 128K up between about 40 people. Updaters that refuse to stop downloading when you close them really bog down the network. Now, you could try and put in some custom menu to control that sort of thing, but that's going to be a mess of configuration and hard choices, and developers will have to do that for every single app.<p>Quit/Close are two well-defined commands that give the user a well defined way to say when they want something to go away vs. when they want something to go away and quit doing anything. Re-implementing "go away and quit working" on a case-by-case basis is going to end up with every app either having a nonstandard interface for doing so, or no way to do so at all (like most update managers.)<p>Personally, I think "some apps don't quit properly" is a description of a problem with the apps, not with the "quit" command. Comparing to mobile is a red herring, because you can in fact quit background services on most mobile platforms, and it's a necessary thing to do. It's only programs that by design, always gracefully suspend, full stop, and resume later that make sense to not have a quit command.

I'm certainly impressed that the Canonical team are thinking about UI issues in this much depth. It is admittedly FAR more thought than I've ever given to the 'Quit' command, ever.<p>And while my initial thought is that there are much more important UI/UX issues to be solved in Ubuntu before this, I think that thinking of things like this are key in fixing the global UI altogether.<p>I'm not entirely certain of whether or not this is the best suggestion though. I LIKE to quit applications. I like knowing that they aren't running in the background, that they aren't consuming resources, that they aren't going to pop up a notification, that they aren't cluttering up my taskbar. I'm the same way with browser tabs -- I don't like having any more open than I need.<p>If I'm in the middle of something, and need to have a lot of tabs open, I'll generally open a new browser for my casual browsing that I can close when I'm finished. Conversely, I almost always keep Photoshop open, even if it's idle, because launching it takes more than a couple of seconds. I don't know if getting rid of quit is exactly what I'm looking for.

As an Ubuntu user, these articles scare the hell out of me. The quit or exit command is not confusing at all. And if you want to get rid of it, you'd better make sure that none of your programs have any memory leaks ever (good luck with that).<p>You know what is much more confusing than the quit command? Having to go into the CLI or the task manager and kill stuff manually because it is eating half of your memory and processor time doing nothing. Or having to restart your PC every day because it just gets slow after a while.<p>Here is the most important thing about GUI design - you should confirm people's expectations. People expect to be able to quit stuff.<p>It is extremely annoying that this starry eyed experimentation is going on in the most popular Linux distro. They are basically risking the one foothold Linux has been able to make in the desktop world. If you want to experiment, you should start an experimental distro and not risk your's and Linux's one single solid success.

A document you 'close', an application you 'exit' or 'quit'. The document-centric people have been trying to do away with applications since the the beginning of GUIs.<p>It reality, the document metaphor works great for a few things that resemble documents. But documents are as much an artifact of the paper-handling wold as processess login sessions are to the electronic world. Are they really more fundamental than, say, a stapler? Is a stapler worthy of being a fundamental pervasive metaphor for interaction?<p>Games? Videos? Terminal windows? Phone calls? Desktop sharing? Text and IM? Many of the things we do with computers have little to do with documents.

"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."<p><i>"all other applications have become fast enough that they don’t need it any more".</i> I'm glad this person has decided what I should consider 'fast enough'. So kind of him.<p>As much as I didn't really like the Mac 'quit' model (as distinct from closing the last document window), most apps <i>still</i> take a long time - meaning I can notice it - when opening from a cold start. Perhaps when everyone has SSDs this will be less noticeable, but it's still noticeable/measurable to me.<p>I remember working with a guy in 1997 who was fawning over how fast the next Windows was going to be. "It'll boot up in, like, 4 seconds!". Right... however fast our hardware becomes, our apps fill up the hardware with more 'stuff'.

It seems to be down, google cached version:<p><a href="http://webcache.googleusercontent.com/search?q=cache:KY4Mjyl8z1cJ:design.canonical.com/2011/03/quit/+site:http://design.canonical.com/2011/03/quit/&#38;hl=en&#38;gl=ca&#38;strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:KY4Mjyl...</a>

So if I understand it correctly: First they threw away the rhythmbox tray icon and made it quit on "X" in order "not to clutter the tray". Then they reverted to their own meta-trayicon and made even more applications fold to tray on "X". Now they want to remove "quit" completely and make "X" a "maybe quit, maybe close, you don't need to know the answer"?<p>I'd really like it if they started publishing their research / references / discussions. Right now it seems like they just do what they want and wait to see if it works or not.

This argument is pointless. The argument makes no sense without putting in the context of content creation vs content consumption.<p>Content creation is very resource incentive. If you don't quit any apps ever, you run out of resources. Simple as that.<p>Content consumption, on the other hand is easy and very optimized. Always have your browser running with 10 pages loaded at the same time you have your music player running and have a movie paused. No problem. Never quit anything.<p>Then the argument starts to make some sense.

I'm happy that Canonical is thinking about usability, but has any of this actually been backed up by any kind of experiment? I see one link on Google to a study done on Thunderbird (sadly down, as it's the same blog), and a bunch of blogspam related to it, but very little evidence that the recent radical changes they are making have undergone any usability testing. If you're trying to help users, shouldn't you study their actual behavior?<p>I admit though that this is not my field, and I could be using poor search terms.

Awesome. Next, get rid of "Save", which is an even bigger problem.

Can anyone recommend a good novice-friendly Linux distro with a clean, consistent UI that isn't being progressively replaced with presumptuous avant-garde nonsense?

I guess the next one in line should be getting rid of file as a concept. Not much point knowing where exactly the song you want to listen or a movie you want to play is stored.

I'm sorry, I just don't see where the problem is. To take two applications that I run almost continuously, an editor and a browser, both have multiple instances of task--- both shown to me as windows as it happens. No problem in either opening or closing them. The mechanism is as old as windowed operating systems; find the menu item that says close or click in the corner (or it's analogue.) This action scales; do the same thing if I wish to close the app (although as was pointed out in passing in the article, this action is decreasing.) Is there anyone reading this that is confused over these actions? I really don't think so. Instead of the disparaging remark about cargo-cult interface design, maybe it was a case of the designers understanding that there are some wheels that need to be shared and not re-invented. Given the time these methods have been in place and in use, it doesn't seem like a good thing to change without a much more compelling argument.

This guy may be happy to know that the new Mac OS that's coming out doesn't have running lights on the dock by default. So you can't really tell if an application has quit or not. In fact, apps now resume when launched.<p>The trouble is, not all apps support resuming when launched. So it's like a big mishmash and you're quite sure which are running and which are not. The transition will not be pretty! I'm gonna turn my running lights back on as the first thing I do on the new Mac OS.<p>Look, I actually LIKED the Mac's paradigm of being application-centric, and not document-centric. The latter was Windows' way: MDI, SDI, and all that. When you closed the last window, the app closed. Or did it?<p>On the Mac, I had control over when I wanted the app to close. Even when I did not do development, I understood what was a program and what was a document. It ain't that hard to do. As a developer, I really love to know what app is running and be able to shut it down, without having to force-quit it.

We killed their server.<p>There's a cache here: <a href="http://webcache.googleusercontent.com/search?q=cache:KY4Mjyl8z1cJ:design.canonical.com/2011/03/quit/+http://design.canonical.com/2011/03/quit/&#38;hl=no&#38;gl=no&#38;strip=1" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:KY4Mjyl...</a><p>I'm not sure if any there was any images in the post.

Looks like their server feels the same way. (Sorry, I had to say it)

This looked like an interesting read. But then they mentioned Rhythmbox and I remembered the one thing I hate about that player: that stupid icon that stubbornly stays there in the notification area even if I don't want to listen to music any longer.<p>I think you could easily make the opposite point: With slower media (floppy disk, slower hard disks etc.) starting an app was costly. This is why people tried to avoid quitting an app just to select a file. Today hard disks (especially SSDs) are fast. Quitting and starting an app is rather cheap. (With the exception of those commercial apps that try hard to make you feel that they were worth the money.) I thus would like to propose to get rid of all those "Open file" dialogs. In the age of multitasking, they are an obvious case of cargo cult.

With all the acknowledgement of Apple's role on the history of this, I have to wonder whether they are aware that Apple has been laying the groundwork for doing the same thing since Snow Leopard, and that Lion can already automatically quit and even pre-start applications without the user's involvement.<p>That said, I suspect Apple will keep the "quit" menu item even if it's not necessary for at least one version so that people have a chance to learn that it isn't necessary without being freaked out by it's sudden disappearance.<p>Also, although app developers have been encouraged to adopt to the new conventions, there will be plenty of legacy apps that don't for some time to come.

The recent UI changes in Ubuntu (getting rid of X11, now this?) seem just crazy. I use Ubuntu on my machine, because I want a developer friendly OS. Recently, however, it just has not been the case: for example, OCaml 3.12 is still unavailable in apt repos (even on "unstable" branches), despite it being available in Fedora/CentOS yum repos or in macports. Same for Scala 2.8.x, Erlang R14, etc...<p>Has the Ubuntu team completely forgotten its original constituency in pursuit of "Linux that your grandparents can use on their netbook?"? Looks like back to debian-unstable (or Fedora rawhide?) for me.

I hope Canonical picks up GnuStep some day.<p>I remember the first days of GNOME, a Windows-clone in looks, with an ambitious acronym "GNU Network Object Model Environment". Are they anywhere near that acronym in vision today?

&#62;&#62; Phone and tablet operating systems, such as Android and iOS, have abolished the ideas of “quitting” or even “closing” applications altogether.<p>Try to Google "android task killer" to see what users need.

For me, as a power user, "quit" means "stop doing anything!!", for an IM app, it means: stop showing me as available, stop using my yahoo login because I want this other program to use it! Just stop everything! Don't assume "oh you just want to be offline!", NO! I want to stop you in your tracks and prevent you from doing anything what-so-ever.<p>I quit an application when I feel it's not doing what I want. I quit an application when I feel the application is being presumptuous and making false assumptions about what I want to do.<p>I hardly ever quit an application because I need the memory .. it's not about process/memory management. I often close application to reduce clutter on my desktop, and clutter can be reduced without actually quitting applications, so they have a point there, but I'd still hate it if applications assume that I don't really want to quit.<p>It really annoys me that closing Banshee doesn't stop it from playing music.<p>It's about setting rules and drawing lines; it's about having control over one's out computer.<p>I quit a movie/music player to stop from emitting sounds. No, the sound menu is not enough replacement. It might be a good alternative, but not good enough to warrant "never quitting the media application".<p>I open a browser in private mode then quit it, because .. well it's private mode; if you can't quit it it kinda defeats the point.<p>I quit a download application (e.g. a torrent client) to stop it from downloading/uploading (to free up bandwidth).<p>You could try to rethink every use case, and you can provide other ways to achieve the same goals. But, in the end, this is not a good reason to make applications non-quit-able.

This sounds like a solution to a non-existent problem.

This brings to mind the X session management protocol (<a href="http://en.wikipedia.org/wiki/X_session_manager" rel="nofollow">http://en.wikipedia.org/wiki/X_session_manager</a>) that never seemed to be used be in modern Linux applications. Issues that others brought up regarding memory consumption could be addressed with more consistent use of this or a similar protocol. While intended for saving state on logout, there's no reason the window manager/session manager/something else couldn't just direct an application in the background to save state and then kill it when memory gets low. That said, it's probably a bit too late in the game to establish such a policy. Users would be more likely to blame the desktop environment for killing the program and losing all of their work instead of blaming the application for not saving the state to begin with.

It seems like most of what he's complaining about stems from the illogic of the MDI interface (<a href="http://en.wikipedia.org/wiki/Multiple_document_interface" rel="nofollow">http://en.wikipedia.org/wiki/Multiple_document_interface</a>) and has nothing to do with the Quit command as such.<p>But really, what you want is for every <i>document-editing</i> app to open a single document, with maybe some tools on the side. The problems he mentions here go away and the "quit" menu option remains perfectly logical.<p>It's made a little tougher through Browser-tabs being the bastard-son of MDI. But seriously, multiple windows should be handled by the taskbar or some other thing.<p>Music is tougher question but considering every the Linux jukebox apps I know is a complete pig on resources, some way to quit pretty necessary.

I'm significantly confused. The article seems to be talking about the distinction that OS X has between closing a window and quitting an application, and talking about how this behavior exists on Windows and Ubuntu as well. I must be missing something somewhere.

I was really hoping this was exactly what the headline made it sound like.<p>It is interesting to see the history of the quit/close pair in programs though.

a) Does this mean ubuntu will be patching each and every application in synaptic to follow this new paradigm? b) Isnt an explicit action more favorable over an implicit action? ie a direct mapping between what the user is doing and what happens with system resources. c) How do you close emacs with 25 buffers or browsers with 20 tabs in this new world?

Anyone else thinking that this is pretty much imitating the way OSX works? Not that this is necessarily a bad thing...

File under "things that don't need fixing".

&#62; Error establishing a database connection<p>Nice way to quit.<p>We did it. We HackerNewsed it. Uh. YCombinatored it. Hm. We hacked it. No. We slashd... NO. We Redd.. NO!<p>o.O