31–40 of 137 posts
Looks like their server feels the same way. (Sorry, I had to say it)
Couldn't you have at least linked to the google cache? http://webcache.googleusercontent.com/search?q=cache:KY4Mjyl...
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. Also "effectively limitless" means equivalent to the specs of the worst system the designers use, which will likely skew things. Where I'm si…
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 m…
Exactly how I felt about the "new" Microsoft Office UI and the straw that broke the camels back on my continued use of that software.
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. Also "effectively limitless" means equivalent to the specs of the worst system the designers use, which will likely skew things. Where I'm si…
ahem, in mobile we do not have quit..nothing broke not even the mobile users :)
So, no, it may not have "broken" anything, but it has caused significantly wide, if not deep, cognitive dissonance.
"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…
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 m…
That's often the very point of UI, is in studying behaviors and responding to them in ways that aren't obvious, and that often sound wrong on their face. Apple, in particular, are considered a paragon of UI excellence, yet many of the decisions they make SOUND downright terrible.
Of course, using their products is generally easy and convenient.
For the record, I am not a UI/UX guru, so all I can offer are anecdotes on this, but I think that the important takeaway is that good UI/UX should not be obviously right. If it were, everybody would have already been doing it, and I think that we can all agree that most UI of yore is downright bad.
I admit though that this is not my field, and I could be using poor search terms.
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. 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. I'm not entirely certain of whether o…
I feel the same way as you do - I like to feel my system is clean and uncluttered. However, I still agree with their thoughts. We may like quitting applications, but realistically, memory/CPU management is something that can and should be handled by the OS. It's an overhead on the user's mind that can be dealt with perfectly well by clever automation. It should keep itself clean without needing our help. A kid growin…
The proof is in the putting, and with conceptual changes like this, I'm leery of judging before I see the actual results. For the most part, backgrounded running applications don't take up resources unless they're supposed to (like music playing, or an uptime monitor, etc.) so I don't have any qualms about leaving that to the OS (unless they screw it up,) but all the other visual aspects need to be dealt with at the same time for this to be effective.
Nice way to quit.
We did it. We HackerNewsed it. Uh. YCombinatored it. Hm. We hacked it. No. We slashd... NO. We Redd.. NO!
o.O
Earlier quoted context omitted.
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 exclusive…
I meant from a user's perspective. You shouldn't care if the song is stored in /foo/bar or in a remote database somewhere in the cloud. You access it through some obvious interface e.g. iTunes. Having 'file' as a central concept of accessing data doesn't have much connection to the actual way it is used. My vim config file doesn't have much in common with a song I've just downloaded. It is stored the same way, but th…
The aspects that the user can do without are related to sharing the file system with software that uses it as a backend store.