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.
That’s it, we’re quitting
11–20 of 137 posts
Re: That’s it, we’re quitting
#12I 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.
Re: That’s it, we’re quitting
#13I'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.
Re: That’s it, we’re quitting
#14Getting 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.
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.
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.)
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.
Re: That’s it, we’re quitting
#15I 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.
Depends what you mean by "where". With respect to finding it amongst other files, making it available on portable devices, sharing it (or NOT sharing it) with others, "where" is very important to the user.
What we really want is the user's concept of a file decoupled from the system's concept, and then cleansed of various baggage from the prior coupling. That's very different than making it a system concept exclusively.
Re: That’s it, we’re quitting
#16I 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 m…
Now I know what I'll be doing at 3am tonight.
Re: That’s it, we’re quitting
#17Awesome. Next, get rid of "Save", which is an even bigger problem.
Makes a lot of sense, if you kept a transparent source control of every change made to something and constantly updated it on each change. The issue though is how everyone is used to save.
I guess a regular save can be the same idea as a tag in version control with the automated stuff to, I think the next OSX was doing something like this?
Re: That’s it, we’re quitting
#18Awesome. Next, get rid of "Save", which is an even bigger problem.
Makes a lot of sense, if you kept a transparent source control of every change made to something and constantly updated it on each change. The issue though is how everyone is used to save. I guess a regular save can be the same idea as a tag in version control with the automated stuff to, I think the next OSX was doing something like this?
> Makes a lot of sense, if you kept a transparent source control of every change made to something and constantly updated it on each change. The issue though is how everyone is used to save.
True enough, but they're also getting used to transparent saving. You don't 'save' your state in Gmail; if Firefox or your computer crashes, you didn't 'save' the current tab state. And so on. The state is just there and always up-to-date.
If you look, you can see how they are saving in the background every X seconds (such as Gmail's composition warning), but I imagine most people simply gloss over that.
Re: That’s it, we’re quitting
#19I'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…
Many applications have both a "close" and a "quit" option. The "close" option does what you describe - they want to get rid of the "quit" option, which is used to quit an application.
(Try opening two Firefox windows and you can easily see the difference.)
Re: That’s it, we’re quitting
#20"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."
"all other applications have become fast enough that they don’t need it any more". I'm glad this person has decided what I should consider 'fast enough'. So kind of him.
As much as I didn't really like the Mac 'quit' model (as distinct from closing the last document window), most apps still 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.
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'.