279

+1 for this great idea.

Why this idea, that have 234 votes and the code already write, is not yet been implemented?

Well, the code that has been written demonstrates what this idea might feel like, but in order to truly implement it without everybody writing it on his/her own, it would have to be included somewhere in the KDE libs and be made a well-defined standard, so it's not just a matter of simply committing some code.

I don't know why nobody seems to have attended to that second task though…

VaterGarp wrote:Well, the code that has been written demonstrates what this idea might feel like, but in order to truly implement it without everybody writing it on his/her own, it would have to be included somewhere in the KDE libs and be made a well-defined standard, so it's not just a matter of simply committing some code.

I don't know why nobody seems to have attended to that second task though…

ok, let's say that there is a prototype code but, the number of votes is very high, and i don't think that the implementation is much difficult. The intention of my comment was mostly to stir things up.

Zell_89 wrote:ok, let's say that there is a prototype code but, the number of votes is very high, and i don't think that the implementation is much difficult. The intention of my comment was mostly to stir things up.

I know, and I appreciate that a lot
(I just wanted to demonstrate that I know there's quite some work to do. I believe that makes a good impression)

@kb_sc1
I like it.

Hi, very nice idea, +1 on me.
I dare link this to another idea of mine, about opening/modifying a file from contextual menu, since in my opinion these two entries (or at least "open") should be added in large icons to your prototype's "Cut/Copy/Paste". Link is: brainstorm.php#idea100990_page1

Nice idea anyways, I'm eager to see this implemented.

gerlos wrote:I was talking about icons on toolbars that trigger submenus. I don't like them. They look like buttons, that do what they should with just one click, but need one more click to do act as needed.
I always have to explain people how to use these things, that's bad, since you don't want to explain the interface (it should be straightforward), you want to explain how to get the work done.

I partially agree with your statement. The part about being confused because you click on button and it just open a menu. Indeed, clicking on the main "body" of a button should trigger an action.
With that said, having a submenu openable by clicking on corner arrow is a convenient mean to gain space and is already used in some applications. So there is a good chance everyone will get used to it in some time.

Hm, I like those buttons that offer a submenu when pressed longer. The arrow indicates there's more to the button and as mobile phones and their „Press a bit longer to invoke a second, hidden action“ buttons/menus spread, the acceptance/knowledge for this kind of button is rising.

I personally like to use Chromium's clean „Press long, see history“ back button a lot more than e.g. rekonq's „Don't miss this tiny area if you want to see the history“ button.

The idea is quite interesting, but besides the apparent improvement, I would also consider a few drawbacks.

1. It adds one dimension to the layout (from simple vertical layout, to vertical + horizontal layout), thus adding complexity and reducing the cognitive perception
2. It does not give more room, instead, it emphasizes 3 actions at the cost of the other ones (introducing an additional hierarchy)
3. It does not really match the purpose of a context menu (which is actually already an "advanced" element). Maybe you could consider to adapt it to a tool bar or find out another concept (such as dynamic/context panels).

Just my 2 cents regarding usability, I hope it can help to improve your proposal!

bwalter wrote:1. It adds one dimension to the layout (from simple vertical layout, to vertical + horizontal layout), thus adding complexity and reducing the cognitive perception
2. It does not give more room, instead, it emphasizes 3 actions at the cost of the other ones (introducing an additional hierarchy)
3. It does not really match the purpose of a context menu (which is actually already an "advanced" element). Maybe you could consider to adapt it to a tool bar or find out another concept (such as dynamic/context panels).

1. We've got a second dimension already: submenus. Even if we didn't have them, I don't see why introducing that would reduce cognitive perception.
2. Well, in my opinion, there IS a hierarchy. Not all items are equally important. Besides that, it just doesn't make sense to align items like ‘Previous‘ and ‘Next’ vertically when the corresponding icons show arrows pointing in horizontal directions. And yes, it does give more room as you can see in the screenshot (depending on the items in a context menu of course, this is not true for all).
3. I don't understand what you mean by ‘It does not match the purpose‘, could you explain further? It is planned or meant to be introduced to menubar items as well, but as these follow standards that are not set by KDE alone, this cannot be done as easy as it can be with context menus (see the KDE Usability mailing list thread on that matter; I could not find an archived version of that on the internet, sorry, but the thread has ‘Rethink context menu‘ in its title).
What do you mean by dynamic/context panels? A panel that changes its content depending on whether an item is selected? I think the constant changing icons and text will be quite annoying, but maybe I misunderstand your idea.

1. No. that's a second *layer* (or level) - not a dimension. Scanning a matrix is harder for the human brain than scannig a vector, grid is still better than chaos.
It's just like that - complain to your gods. It becomes worse because you also have to navigate the mouse 2-dimensionally now and to make things even worse beyond that, one item has a linebreak - leading even to unaligned text lines. Great candidate for GUI bloopers 3.0.

2. Points the major flaw of this approach. It assumes you can pick 2 or three items that are more important and pass them an exposed position.
The proposal suggests the standard copy and paste actions. Just: I for one *never* open the context menu to perform copy & paste. So to me, this just adds (eye catching) distraction from my actual intent.
Even if the "important" actions would be configurable, that does not mean they are important at the time when i open the context menu (if i do so to copy the file to a certain location only that is important and everything else - including what i might have configured as important - is irrelevant)
If some popup menu is cluttered, it's simply time to clean up. Regroup and eventually hide some less interesting features in a subgroup. Not stress random stuff.

3. What he means is that a contextmenu is already the last resort.
Eg. you'd naturally not use it to copy some file somewhere but simply drag the file over - eventually use a shortcut combo. Popups (attached to a menubar or not) in GUI typically serve as a kitchen sink, ie. the developer stuffs features there, which s/he does not know how to provide through a more direct interaction.
If you've important (core) functionality (predominantly) used through a context menu, there's something severly wrong with your application GUI in the first place.

Leaving all that aside: this is certainly not gonna happen in KDE4 because kdelibs is frozen (no new features) due to the far more important frameworks split work for a while.

If Qt5 still supports widget actions in menus, the implementation is trivially done by adding a toolbar to a menu.
Every developer can do that in 5 minutes - or s/he spends 10 minutes on how to actually improve the workflow of the application.
If you start optimizing context menus, you missed the actual bug.

I'm VaterGarp, I don't have access to my old account.

Just wanted to say it's 2014 now and Firefox has introduced this exact kind of context menu:
http://cdn.ghacks.net/wp-content/upload ... t-menu.jpg

Please tell me again how this is harder to scan than a context menu with 12 lines of text.