GNOME Bugzilla – Bug 87330
[ui-review] Nautilus context menu ordering
Last modified: 2004-12-22 21:47:04 UTC
This was raised in the UI review but originally scheduled for the 'second round' of UI changes, whenever that might be... but Dave reckons that since it's only a matter of hacking some XML files it should go in now. Obviously I'm biased so I agree, but up to Luis to triage I guess... Suggest following order for files (note addition of mnemonics): _Open Open _With > _Scripts > -- Cu_t _Copy _Paste (present for directories only) -- _Duplicate _Make Link Re_name -- Move to _Trash -- Remo_ve Custom Icon Stretch _Icon Rest_ore Icon's Original Size -- P_roperties See http://kaunas.alna.lt/~menesis/images/nautilus-context-menu-proposal.png Suggested desktop menu - New _Window _New Folder New _Launcher New _Terminal -- _Scripts > -- _Arrange Icons > -- Cu_t _Copy _Paste -- _Disks > -- _Use Default Background C_hange Desktop Background Where 'Arrange Icons >' is the same as View->Arrange Items in main Nautilus window. See http://kaunas.alna.lt/~menesis/images/nautilus-desktop-background-menu.png Also suggest possible inclusion of View->Refresh' on desktop background menu. Context menu for desktop background and file manager window background should be similar.
I'm putting in these changes with the main window string changes, but I'm going to leave Clean Up By Name instead of Arrange Items, because none of the ordering options apply to the destkop (it is always in manual mode).
Adding jfleck since this needs to be documented.
adding the ubiquitous Eugene to the cc list.
*** Bug 81217 has been marked as a duplicate of this bug. ***
By retaining the "Clean Up" we use two verbs (Clean Up and Arrange) to mean essentially the same thing. I think this is unnecessary and may confuse users. Also, I think arrange describes the action more accurately. On the desktop background you can arrange icons manually or arrange icons by name. Even though none of the other sort options available in Nautilus windows are available, it is still valid to use Arrange in the context of the desktop background. I suggest: s/Clean Up By Name/Arrange Icons by Name -or- s/Clean Up By Name/Arrange Items by Name I slightly prefer 'Items'.
eugene the issue you present is an issue of implementation. arrange by name, size etc. only affect fixed layout while clean up by name affects manual layout. I have proposed bug 74927 to merge these into just one set of menu items (arrange by ....), but to really do this correctly we would have to either ditch fixed layout alltogether or perhaps implement something akin to windows automatic layout, i have talked to dave c about this in the past, i have an open bug too, bug 84511. but with the current design i dont think there is a good ui fix personally.
I think your proposal in bug #74927 is basically the way to go here... have one set of "arrange by" options that changes the order of the icons (whether on the desktop, icon view or list view), and a single "tidy up" command to snap them to a grid.
couple of comments in response to calum: 1. I think we can exclude the list view in this discussion because its ordering is determined by clicking on the column headers. This is probably easier and faster, and helps avoid unneeded complexity. 2. The problem with implementing my suggestion in bug 74927 is that currently the arrange options use check boxes, since automatic layout is hard layout. This is different from windows auto-arrange as is suggested in bug 84511, which is simply a gridded type of manual layout. so i see a problem here if we integrate the two while keeping the current style of automatic layout, in automatic layout mode, these ui elements will require check boxes, while in manual mode these option should just be menu choices like clean up by name is. I think the best solution here is to implement windows style auto-arrange for the icon views and ditch the hard sorts. This is one of the best features of explorer. I'm sorry im using this issue as a sound board for this feature, but i can't really think of any better way. Calum do you have any other ideas?
Why is "cut" and "copy" needed in directory views when they really apply to the selected files. (You do get a Fitts' Law advantage by putting them in the directory context menu, but that's a small advantage compared with cleaning up the desktop context menu.) Also, are "Duplicate" and "Make Link" really needed? "Duplicate" should be possible with copy and paste. "Make Link" probably (I think) isn't used by beginners and both actions can be done easily by right-draging.
ben: 1. Agree cut and copy are useless for the folder view. As far as fitts goes i think that context menus should be consistent according to an object type. (ie. all folder view context menus are always the same, all music file context menus are always the same etc.) 2. Duplicate and make link are needed because right now we do not have accessible drag and drop. 3. Right click drag is one of the most terrible ui decisions ever made. It is completely hidden (i didn't even know it existed in windows or nautilus until i spent months churning through nautilus bug reports and somehow discovered its existance and I've been using windows since version 3.1) and it only serves as patchy fix to inconsistent drag and drop behavior from the interface hall of shame see: http://www.iarchitect.com/explore.htm#EXP5
As for (2), I can agree with that although I still see it as kludgy. Also, there is always copy/paste for duplicate, and everywhere but the desktop there is the edit menu. For (3), I have read about the issues with right-drag, but I find it too useful to not like.
in regards to 2) see the current nautilus list (or maybe it was desktop devel...not sure) discussion of pickup and drop, i won't rehash that discussion here. as for right click drag, i think its only useful because of the lack of accessible drag and drop. That said there are some other problems with it, but this bug is not the forum for that discussion. My main point is that we can not depend on this behavior as it just too hidden and inaccessible.
Bug #82768 holds a related issue about adding a 'Create new panel' to the desktop context menu.
Bug #82463 discussed a related issue about 'new window'
Ben: FWIW, Copy and Paste are as much at home in a file manager as 'Move to Trash' and 'Run' are at home in a word processor. It's confusing the terminology (why doesn't the computer ask me where I want to copy the file to when I click Copy?) and raising expectations that can't be fulfilled (why don't I get a new file with the text I just copied to the clipboard in OpenOffice when I select Paste?). So, having Copy and Paste instead of Duplicate is not a long-term solution IMHO.
Is there a bug open for the feature Reinout mentioned? (i.e. creating a new Untitled file where possible when the thing on the clipboard isn't another file?) Sounds like it would be quite a nice idea...
With the growing Nautilus context menu in GNOME 2.2, today I found myself very annoyed that the Properties item was at the bottom of the menu. I had to strain my wrist to get there (and I have mouse acceleration/speed set at maximum!). For a menu item that's used much more often than, say, 'Scripts', I strongly feel it should be promoted to somewhere on the top of the context menu.
Muscle strain issues apart (that just means the menu is too long to start with, it needs to lose at least 5 items IMHO!), I guess the question is whether you'd get to the Properties any quicker when you had to look for it every time, which you would if it was buried in the middle of the menu somewhere. The top and bottom items of any menu are generally the easiest ones to remember, so in fact there are advantages to putting the most-frequently-accessed items at the top and bottom, and less-frequently-accessed ones towards the middle.
Calum: there doesn't seem to be a bug open for the Paste thing but I guess it depends on whether Cut/Copy/Paste is going to be replaced or not. (bug 77293) W.r.t. the Properties item, I say put it at the top then, I really don't see any reason to keep "Open". I can open the item by (double)clicking it or by pressing enter already, and otherwise there's still 'Open with'.
hig says the first item is always the same as double clicking on an object (open)
Removing keynav keyword to get this off the a11y buglist, don't think there are any outstanding keynav issues here.
Since the issues of cut/copy/paste have taken root in bug 77293 I don't see any relevant items left in this bug that haven't been addressed. The problems Reinout mentioned in Comment #15 could be addressed if there actually were a new paradigm being implemented for this. Perhaps a discussion should be opened up again. Of course this kind of discussion should really take place on the mailing lists and then recommendations be added to bugs so they don't get too out of hand. :-)