The “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.
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.
Thunderbird background mail check ++
The title of this post scared me horribly.
The content, however, was very exciting :D
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?
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.
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 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 ;)
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.
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.
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.)
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…
So the “x” in the window control will change then?
right now it does both “close” and “quit”
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.
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 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.
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.
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. ;-)
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.
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.
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
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.
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.
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…?
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
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 :)
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!
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/
hmmm, “quit” sounds so antiquated.
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.
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.
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.
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.
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?
“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…
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.
*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.
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”.
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.
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.
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.
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.