GNOME Bugzilla – Bug 128226
Usability problem, menu item ordering should depend on panel position
Last modified: 2020-11-07 12:13:56 UTC
The items in the "Program" and "Action" menues should have the same ordering regardless if the panel is on the top, bottom, left or right side of the screen. E.g. if I place the panel on the top of the screen, the last menu item in the "Action" menu is "Log out" while it becomes the first if the panel is moved to the bottom of the screen. This means that menus can't be ordered with respect to their importance or estimated frequence of use, as we never know where the user prefers to have the panel, or for that matter where on the panel the menu applet is placed (important if the panel is on one of the sides)
Well, it might be a good idea. But it may be surprising to have a visually different order too. cc'ing usability for some wise input.
I have a vague recollection that Havoc tried something similar with the window list menus, reversing the order of Close/Minimize/Maximize etc. with respect to the order they appear on the window menu itself, to take advantage of the fact that the window list is almost always docked to the bottom of the screen. If this is true, the fact that they're now both in the same order again is probably the result of lots of people screaming about how bad it was :) Cc'ing Havoc to see if I'm just hallucinating about this.
[menu item ordering should depend on panel position...] -- "yes!" Well I don't know the fate of this bug, but... I really think that menu-item-ordering should depend on "where you click". My gut fealing tells me that "Log Out" should be the last menu entry no matter where the panel is positioned. There is a similar case for any menu item I get used to clicking from the panel-menu. What I mean is: users get used to a "default/mean cursor movement distance" for clicking their action of choice. There is a mnemonic enhancement in selecting "My Action" as the n'th element in the menu, whether it is in the top or bottom. This is because I (read: expect people) to have an intuitive feeling of the menu-size after a few minutes of using a new desktop, and I /they have a gut feeling to "scroll this far" for doing "this". Therefore I claim that the menu entries should be reversed in order - when moving them from top to bottom, to maximize the panel-menu functionality. I have been using the current menu layout for quite a while and have always found it rather distracting. This probably stems from the fact that I change distributions quite often (and thereby default desktop layout), but never the less, this could well reflect the feeling of new users. Conclusion: "Scroll this far to get this"-philosophy depends on having a mirror reversed menu-layout for top/bottom-menus. "Scroll this far to get this" is how people think after getting used to some gui-layout.
I disagree. Think of the desktop as a desktop; whether you put your shoppinglist on the top or bottom of your desk, it's still ordered the same way it was/would be ordered in any other place on your desktop. I can't think straight today (FF1.0 release party yesterday ;), so I'm reverting to the ol' causes-lots-of-discussion-about-MS-is-not-always-right: I'm not sure how MacOSX does this (or if it's even possible), but MSWin does not change the menu order.
Most people don't move their panels around that often. They usually decide to keep them at top, bottom,... Then they keep them in the chosen position. The situation whare the user gets bewildered because the order change would be very rare. If we don't reorder the menus, we can't make design descisions like: - Place the logout menu last as this will be the most seldom used choise - Put the logout menu last to prevent people from logging out by mistake. - Put the most frequently used first in the menu. By not reordering the menus on relocation, we basically say that the order of the menu items is of no significance. If that was the case, we could reverse the order any day without much protests from the users. I don't think this is true. Finally, just imaginge the support situation: - User: How do I logout??? - Support person: At one of the screen edges, probably the top, you have many menu called "Actions". Do you find it? - No,hmm,... Ah,there it is:-) - Support person: Good. Where did you find it? - User: Where?!??? - Support Person: Was it on the top, bottom or to one of the sides of the screen? - User: It's on the top of the screen. - Support person: Good. Now, select the last menu item in the action menu - User(by now forgotten what menu he looked for): Action menu? .... If the menus was reordered the conversation would be much shorter: - User: How do I logout??? - Support person: At one of the scrren edges, probably the top, you have many menu called "Actions". Do you find it? - No,hmm,... Ah,there it is:-) - Support person: Good. Now, select the last menu item in that menu ....
For me, the last item in a menu is always the item at the bottom, even if the panel is at the bottom...
Could it be that, there are cultural differences in what is percieved as the last menu item. Most people I ask considers the item requering the most mouse movement to hit to be the last item. Anyway, not reordering the menu, still makes impossible to order the menu with respect to frequency of use etc.
Ok, I've thought a bit more about this. Isn't this valid for all the menus, and not just the panel menus? For example, if I right click at the bottom of my desktop, the menu appears on the top of the pointer. Shouldn't the menu be reordered here too (in some locales, and not in fr_FR :-))?
*** Bug 322891 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > Ok, I've thought a bit more about this. Isn't this valid for all the menus, and > not just the panel menus? Yes, you are right. It's just that panel menus are more likely to be opened on the top or the bottom of the screen. So, yes, this should be applied to all menus.
bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old feature requests in Bugzilla which have not seen updates for many years. If you still use gnome-panel and if you are still requesting this feature in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/gnome-panel/-/issues/ Thank you for reporting this issue and we are sorry it could not be implemented.