GNOME Bugzilla – Bug 319233
Make "Add bookmark" button more obvious
Last modified: 2014-12-22 18:28:35 UTC
From a mail I sent to Alex Graveley: Once users figure out that the buttons are for bookmarks, they do this: 1. File/Open 2. Go to their $dest folder. 3. "Oh, I'll be using this frequently; I'll add a bookmark" 4. Click on Add 5. The file chooser adds $dest/first-subdirectory, since that is what is selected in the file list... The "add bookmark" callback looks like if (something_is_selected_in_the_file_list) { if (is_folder (selected)) add_bookmark (selected); else that's_not_a_folder_you_idiot(); } else add_bookmark ($cwd) So I'm thinking of doing this: - Re-label "Add" to "Bookmark <current folder name>" - this would always bookmark $cwd and not pay attention to the selection. Make its icon be an "Add bookmark" icon, not the stupid Plus. - Shrink the Remove button by just making it a little trash-can icon. Does that make sense? Dragging folders to the bookmarks list would of course work as usual. Also, one thing that annoys me is that when you click Add, the bookmark gets put at the bottom of the list, and the bookmarks pane doesn't scroll down to show it. It should probably get inserted at the top of the list, and be made visible --- being at the top means you can see it immediately the next time you use a file chooser (and you can hit Alt-1 to select it).
Just kill the Add/Remove buttons altogether. They are always going to be ugly and confusing given the user model in the file selector. Focus is too hard to get right here for all the different cases, so you need to rely on direct manipulation of the favorites. By this I mean drag and drop of new items, or Shift-F10->Add Bookmark. Also, I wouldn't insert at the top. Nothing else I can think of inserts new items at the top of a list when the user has explicitly added something. The correct thing to do is scroll the list and select the new item, but stealing selection will be pretty annoying. If you remove the Add/Remove buttons all-together, the user places bookmarks exactly where she wants them in the DND case (which will be your 95+ percentile use case) and the problem goes away.
Nah, ever tried to do DND with the keyboard ? Shift-F10->Add Bookmark is not exactly easy to discover (And we've got beaten enough for C-L)
Btw, Apple doesn't allow manipulation of the favorites sidebar inside file chooser dialogs at all. They instead rely on direct manipluation from a Finder window. And I can't even find a way to add items without using DND in OSX's Finder.
we don't want to sink to that level of inaccessability...
I am fine with hard to discover in this case. SO many more users are going to get annoyed about these confusing buttons than will get annoyed because they need better accessibility support for a very rarely used operation. Combined with regular, accessible menu items for adding bookmarks in nautilus, Shift-F10->Add Bookmark in the file chooser is accessible enough. And I think people were upset about Ctrl-L for different reasons, because they missed having a location bar as in the old file selector.
I wanted to add C-d as a binding for "add bookmark for the current folder", just like in a web browser. So if we add that, we could take out the buttons altogether.
Ok, after looking at the dialog for a while, I think I retract my objections. Removing the buttons would probably be ok
*** Bug 139563 has been marked as a duplicate of this bug. ***
*** Bug 135910 has been marked as a duplicate of this bug. ***
Comment #5: Combined with regular, accessible menu items for adding bookmarks in nautilus, ... In my opinion this direction of reasoning is flawed. Gtk+ is not dependent on GNOME, therefore features of GNOME file manager are irrelevant for Gtk+ issues. People who use Gtk+ in other environments should not be denied reasonable and discoverable (Ctrl-D and DnD hardly qualify) bookmark management. I'm for making the Add button explicitely state current directory and bookmarking it current directory as the original report suggests, because this is explicit and would cause the least surprise (it's what I was about to suggest when I found the bug already reported).
Some ideas: - Let the user remove bookmarks by dragging them to the trash (needs the "application/x-delete-me" hack described in http://primates.ximian.com/~federico/news-2004-04.html#x-delete-me - Put an unselectable, grayed out "drag items to here" item at the bottom of the shortcuts pane. Users will see it and then know how to add items.
(In reply to comment #11) > - Let the user remove bookmarks by dragging them to the trash (needs the > "application/x-delete-me" hack described in > http://primates.ximian.com/~federico/news-2004-04.html#x-delete-me Leaving aside the merit of this idea, does this address the usability of the dialog outside GNOME? > - Put an unselectable, grayed out "drag items to here" item at the bottom of > the shortcuts pane. Users will see it and then know how to add items. Well, "drag items to here" label is a sort of acknowledgement that the user interface is confusing. Drag and drop is not easy, quite the contrary, drag and drop is a complex action requiring considerable coodrdination, it should be an alternative method, not the only one. Especially when an obvious accessible, discoverable and keyboard friendly method exists (the buttons -- just performing the expected action). (In reply to comment #1) > If you remove the Add/Remove buttons all-together, the user places bookmarks > exactly where she wants them in the DND case (which will be your 95+ > percentile use case) and the problem goes away. I thought the assumption was the directory the user wants to bookmark is often -- if not almost always -- the current directory. Therefore bookmarking of the current directory is what should be made simple. But the only way to use DnD to do this is to drag the button from the top row of the dialog. This works but it's so bizarre that I doubt 95%+ people will discover it...
We should remove the bookmarks and the add/remove buttons in favor of a recently used list with pinnable items. Office is using this, as described in Mark Jensen's blog here: http://blogs.msdn.com/jensenh/archive/2006/08/16/702214.aspx Pinning items accomplishes the same thing as add/remove, but requires minimal UI, and has lessened risk of an accident removal. Using a MRU list is more useful in the file save dialog context than bookmarks anyway, since I tend to save a bunch of stuff around the task at hand, which is unlikely to be an existing bookmark location. Tomboy is already using a similar scheme and user response has been overwhelmingly positive.
An MRU list of pinnable directories seems like a good idea. Especially if pinnables can be reordered manually.
I'm a fan of the design choices of Gnome over the years, and I'm not a dummy (well I suppose :p) but the single thing my brain does not understand is how the add/remove buttons work. I mean it! Each time I need to think how it works, just like the multiple rows of preferences in MS Word back in the days, that's funny. Actually I just checked that there are tooltips (and it is the case), but it is not normal have to think how the dialog it is supposed to work: it should work more "naturally". Clearly, I think pinnable items would be awesome for my workflow, and most of ppl's one. Maybe we could CC: the usability team?
Just to bring this bug back to life. It seems that you can now right click bookmarks to remove/rename them and right click in the file selection box to add them. It seems to me that this together with drop and drag should be enough to satisfy adding bookmarks. Also Nautilus used Ctrl-D. So it would seem that if we were to add Ctrl-D to filechooser we could remove the add/remove buttons. What do people think?
(In reply to comment #16) > Just to bring this bug back to life. It seems that you can now right click > bookmarks to remove/rename them and right click in the file selection box to > add them. It seems to me that this together with drop and drag should be enough > to satisfy adding bookmarks. > > Also Nautilus used Ctrl-D. > > So it would seem that if we were to add Ctrl-D to filechooser we could remove > the add/remove buttons. What do people think? Keyboard shortcuts? Context menus? Drag'n'drop? Why not just remove the feature completely if no one will realise it exists or figure out how to use it? A visible, reasonably-sized (unfortunately, this does not hold any more) button is 1. Discoverable. 2. Usable with all kinds of pointing devices. If the button has a visible accelerator (unfortunately, no longer true either) the interface is also keyboard-friendly for free. All these desirable properties are being eliminated. The original implementation was indeed confusing, as discussed above. But the reported issue is not addressed *at all* yet. After all the changes people will be still unable to perform the most basic operation: bookmark the current directory (unless they learn to use the shortcut).
(In reply to comment #17) > > Keyboard shortcuts? Context menus? Drag'n'drop? Why not just remove the > feature completely if no one will realise it exists or figure out how to use > it? > In GTK 3.10 bookmarks will have a bookmarks heading just like in Nautilus so users will have a clear idea that these are something they can add. > A visible, reasonably-sized (unfortunately, this does not hold any more) button > is > > 1. Discoverable. > > 2. Usable with all kinds of pointing devices. > > If the button has a visible accelerator (unfortunately, no longer true either) > the interface is also keyboard-friendly for free. All these desirable > properties are being eliminated. Being discoverable is not a good reason to have a button on an interface. The buttons in an aircraft's cockpit are easily discoverable too fortunately with software we can do things better. The issue is are these buttons something that you use most times you open the filechooser and the answer is no and so the functionality should be hidden away slightly. > > The original implementation was indeed confusing, as discussed above. But the > reported issue is not addressed *at all* yet. After all the changes people > will be still unable to perform the most basic operation: bookmark the current > directory (unless they learn to use the shortcut). Ctrl-d in Nautilus works like this and it should be implemented in the filechooser the same way.
I think this bug has been rendered obsolete by recent filechooser design changes.