GNOME Bugzilla – Bug 680567
Nautilus 3.5 gear menu has way too many items
Last modified: 2012-08-01 14:33:43 UTC
The new gear menu introduced in Nautilus 3.5.3 is very difficult to navigate. There are just way too many items to try to navigate with either the keyboard or the mouse. * In the root menu, I count 7 items and 3 submenus. * In Edit, I count 13 items. * In View, I count 10 items and even worse, another submenu with 6 items. * And there's a bookmarks submenu which doesn't do what I expect (I'd expect a list of bookmarks like my web browser has. If the bookmarks list isn't there, maybe the add/edit bookmarks shouldn't be there either?). Also I think Location... is rather out of place in the Bookmarks menu. I hate navigating menus with submenus on the far right of the screen with the keyboard. Although the arrow points right, the submenu opens to the left. And although the menu is to the right of the now-selected submenu, you have to press the left arrow key to move right. I consider the current gear menu implementation to be an accessibility and usability regression compared to Nautilus 3.4 but I think it's definitely fixable for 3.6. Some possible improvements: 1. Do like Internet Explorer did and have a separate Edit icon-menu and View icon-menu next to the gear icon-menu. 2a. Move the View stuff to the Shell appmenu ( the 2b. Get rid of the Edit menu in favor of the right-click menu. (And maybe a long click should pull up the right-click menu for touchscreens)
Confirmed...we discussed Nautilus menus at the UX hackfest in Coruna yesterday and we came up with a new layout for menu actions. I don't have any pictures/mockups handy at this moment, will attach it here as soon as I do.
*** Bug 680763 has been marked as a duplicate of this bug. ***
<quote from Jeremy> I hate navigating menus with submenus on the far right of the screen with the keyboard. Although the arrow points right, the submenu opens to the left. And although the menu is to the right of the now-selected submenu, you have to press the left arrow key to move right. </quote> I completely agree that the heavy use of submenus is an accessibility and an usability issue. I am talking about "heavy" use here because the items of the Edit menu are probably among the most used items and these are located in a submenu. Concerning the solutions proposed by Jeremy: Solution 1: Moving submenus out of the gear menu and creating and creating separate menus for at least the View and Edit menus seems a good starting approach. Solution 2a: What about other distributions using Nautilus but not the GNOME Shell? Solution 2b: I am afraid that relying only on the right click will increase the accessibility issue In bug 680763, which has been marked as a duplicate of this bug, I proposed a third solution: https://bugzilla.gnome.org/show_bug.cgi?id=680763 Solution 3: Move the items that are in the toplevel menu of the gear menu into a File submenu to make room for a dynamic menu that shows copies of the items in the submenus. The items to place in the dynamic toplevel menu of the gear menu, nautilus could be chosen by the most recently used items or by the most frequently used items routines. <quote from Cosimo from the duplicate bug thread> I don't think having a menu changing possibly every time you click it is a sensible thing to do, so I don't think this is going to be implemented. <quote> I agree with you that a constantly changing menu will be annoying, but the point is that I expect the changes to settle down after a little period of usage: - in the case of a dynamic menu with frequently used items, I guess that by putting the items in the order of frequency, at some point, only the few last items will change - in the case of a dynamic menu showing the recently used items, I would put the items in alphabetical order and I guess that if the dynamic menu is big enough to contain the items regularly used by the user, it will not much change if the items are in alphabetical order In other words, I guess (I have no experimental data to confirm what I am thinking), that depending on how the dynamic menu is implemented, it should be possible to strongly reduce the changes. The dynamic menu has the advantage of adapting to the way the user works: - imagine a user that works most of the time with the right click; his dynamic menu would probably consist of items not available in the right click contextual menu. - another user only rarely using the right click will probably end with items like cut, copy and paste in the dynamic menu The number of items available in the dynamic menu is probably of big importance for the stabilisation of the menu. An intelligent routine might be able to determine how many items to put in the dynamic menu by following the frequency of the changes in the menu: as long as the user has to frequently go into a submenu compared to the frequency he uses items from the toplevel menu, the number of items in the dynamic menu should be increased. (If the frequency comparison is not sufficient to not end up with every items of the submenus in the dynamic menu, a maximum threshold might be required. ) In the case, where the number of items in the dynamic menu cannot be determined by observing the user, there should be an option in the preferences, where the user can adjust it to his needs.
Hi, Another approach that simplifies solution 3: Solution 4: A static menu, that the user can customize the way he wants by moving or copying items from submenus to the toplevel menu and by moving items from the toplevel menu into submenus. Cheers
*** This bug has been marked as a duplicate of bug 680985 ***