Propose your solution
Attachments
No attachments.
Duplicates
Comments
|
cyphax
wrote on the 1 Dec 08 at 20:30
|
|
|
I agree. Gnome is hugely and absolutely unnecessarily limited in placed you don't want it to be. The open dialog is imo the best example. Can't do anything with it other than select a file. None of these are so much vital in that with a detour you can do everything with the whole, but that's not going to float the boat for long.
It would be great if the Gnome developers would look at these limitations. Now I am not a fan of an overkill of buttons everywhere but basic functionality, and smart shortcuts are important if you want to improve usability. Because in some area's (where even Microsoft's Explorer fares much better), Gnome's usability leaves a lot to be desired.
|
|
Emacs23
wrote on the 1 Dec 08 at 20:54
|
|
|
-1.
Right click sucks, I try to use it only there is no another way.
|
|
r0g
wrote on the 1 Dec 08 at 21:05
|
|
|
|
@Emacs23 - Yep, options are rubbish aren't they? That figures Mr Emacs! Emacs - an editor with an interface only marginally more user friendly than assembly language. Why don't we get rid of the mouse altogether eh? Maybe replace X with a more VIM style user interface?
|
|
Rabbid
wrote on the 1 Dec 08 at 22:06
|
|
|
Seriously; why does _everyone_ that get one single -1 get so pissed of and claim the rest of the community is against progress just because they didn't like THEIR idea? This seems to happen in every goddamn idea now; stop it, just stop it.
r0g: Options are great, but we can't add every single one of them, some things have to be static. Think of the configuration hell we would end up in if every single feature imaginable was added by option. I'm not giving this idea any votes (neither + nor -) because I simply don't care.
|
|
|
I still remember google'ing how on earth to edit menu on Gnome. Easy and intuitive right click does nothing there. Oh, I had to press it on panel. Simple? No. Intuitive? Well if you think that panel equals menu.. Never mind. I can live with that.
Right click does not help to configure your screensaver the way you want either. You simply can't do it on Gnome! Your desktop environment thinks you are too stupid to do so..
Totem won't let You choose a file for subtitles..
It's Gnome's approach to simplicity:
abandon all features and customizations.
If Linus Torvalds can not convince Gnome that their going far too far removing features I doubt that anyone else will.
|
|
foxmike
wrote on the 2 Dec 08 at 14:46
|
|
|
-1
GNOME is not Windows, nor should it behave the same (or absolutely differently either). I personnally feel very cumfortable with it's current behaviour about right clicks.
|
|
r0g
wrote on the 2 Dec 08 at 18:00
|
|
|
I think it's bad UI, bad OO and generally bad practice that I can see a file's icon in several different places yet get different menus when I right-click it. Surely to make the menus standard is to simplify things, not complicate them.
@Rabbid. I'm claiming nothing of the sort and it would seem the 'rest of the community' either agrees with me or doesn't care enough to vote this idea down. Anyway, arguing that you can't add every single option is at once pointless and disingenuous. Clearly you can't - that's why this website has a voting mechanism - I assume you're not _really_ suggesting that we all stop making suggestions because only a finite number of them can be implemented?
|
|
|
I agree with r0g: the same visual objects on the desktop should have the same functionality regardless of context. THIS is how usability is improved for newcomers. You have to forget about what you are used to but judge the user interface just by the mechanics and rules it follows. and here gnome lacks in a lot of areas where even xfce is far better.
|
|
cyphax
wrote on the 3 Dec 08 at 09:15
|
|
|
And you know what the funny thing is? Sometimes Gnome's right click menu is awesome. I give you 2 real life examples of situations I have encountered, one of which shows limitation that makes no sense:
- I downloaded an ISO (of Ubuntu 8.10!) a few weeks back. It landed on my desktop. I wanted to burn it. I right-clicked on it. I saw the option Burn to disc. Went ahead and clicked it, clicked Ok in the burn application an I was on my way.
- I wanted to send my friend a file through Pidgin. I clicked "Send file" in its menu. The open dialog appeared. I went to the right folder. It had a good 20 photos in it, all of which came from a digital camera and therefor had file names that were worthless in terms of recognizing the files. The dialog did nothing to help me find out which one I want to send. The right click menu has like one option: Show hidden files. Woohoo.
So while the first example shows clever thinking and a perfect solution to something that isn't even a problem in the first place (heck if I had to open Brasero and select burn ISO that would've worked as well), the second example is something that REALLY needs work. It is SO counter intuitive and unhelpful, it should embarrassing. An "Open file" option would've solved it right there. One option in an otherwise just about empty context menu. So simple, go through the dialogs in Gnome and put yourself into the position of somebody that is not a computer geek.
"I think it's bad UI, bad OO and generally bad practice that I can see a file's icon in several different places yet get different menus when I right-click it."
Well those menu's are called "context menu" for a reason, so I'm not quite worried about that. Maybe the context menu should in the first place adapt to the situation in which you open it, and then if possible without cluttering everything, maybe add some options for everybody's convenience.
|
|
r0g
wrote on the 4 Dec 08 at 21:09
|
|
|
I love the burn ISO menu item! :-)
I agree they're called context menus for a reason but would argue that a menu's default context should, first and foremost, be that of it's parent object rather than the application it is part of. All the possible options for an object should be available on it's menu by default and only those that will never _ever_ be needed by _anybody_ or those that could cause serious confusion or harm should be disabled by the programmer and such removals of functionality should be rare events with very special circumstances.
The decision of what actions are useful to a user is the users prerogative, not each random application programmers. For example, someone, at some point, decided that open and save boxes only need to display a name and a modified column for the current folders contents. It's a tough call in an additive paradigm as screen estate is limited and by your reading, in the context of opening a file this might seem to make sense, after all how relevant is the size of a file when you are opening it? Well I was writing a program for editing very large files the other day and when it came to finding some stuff to test it with it became relevant to me.
Designers can't be expected to see and cater to all these eventualities and asking them make immutable choices is asking them to make arbitrary decisions on everyone elses behalf. This being the case it only makes sense to use a subtractive paradigm and leave options open unless there's a _very_ good reason to close them. For example...
In this case all the columns that could pertain to a folder listing should be made available in the default toolkit object with default visibility settings and the programmer should be able to modify a) which ones are shown by default, b) which ones are mandatory and c) which ones should not available at all. The user may then merrily add or remove columns to suit and the world is a happier and more productive place :-D
|
|
cyphax
wrote on the 5 Dec 08 at 13:12
|
|
|
"after all how relevant is the size of a file when you are opening it?"
It might be relevant. That's the problem: what isn't relevant isn't as important as the question "should we limit people to recognize certain content, represented by a file, only by its filename?". While this might work in most cases for us geeks, this doesn't for the average home user. They don't recognize that specific photo they made while on vacation as "DSC12298.JPG", rather they want to look at the photo and recognize it.
To be fair: I would _hate_ for the dialogs to lose their lack of clutter, this is why I like Gnome better than KDE. But all that would be needed in this instance is an "open" and maybe "open with" option to at least give me the option of identifying the file by other means than just its name. :)
In some cases it's important (like in the open dialog, this IS a problem for people that aren't geeks, I've heard complaints) while in others it's more of a luxury problem.
|
|
|
Linux/Ubuntu newbie here and I agree with the OP in many ways. Context menus enhance usability in a lot of ways and not having them around and do useful stuff is really not a design decision but bad practice.
Naturally this is a bit of a disappointment to me because the way you can customize the Ubuntu desktop is absolutely awesome while the way you can customize the context menus is absolutely *not* awesome.
The first thing I usually do after installing Windows is installing LiteStep (a shell replacement) right away. That is because LiteStep provides a very powerful context/popup that you can cutomize to such a degree that it allows you to literally get rid of both taskbar and system tray, giving you that much more space. In conjunction with with Windows Explorer's context menus you can essentially reduce most of the user interfacing down to one right click. Its very intuitive and so easy to learn that I did the same thing on my mother's machine because that way she has no problems whatsoever using stuff and she can't break stuff either because the context won't let her do it.
Long story short: Context-/Popup menus are pure and utter win. Ubuntu needs them. There is no excuse for *not* having them.
|
Post your comment
|
