On Sat, 2007-02-24 at 11:18 +0100, Thorsten Wilms wrote: > On Sat, Feb 24, 2007 at 12:44:28AM +0100, David Christian Berg wrote: > > > Frankly, if only the add button was _only_ active, when one can actually > > add bookmark (I think it should be disabled, when the places list is > > active) and had a bookmark icon, instead of a plus, I think this would > > really be enough. > > The Add/Remove buttons eat a lot of space and are likely the least > efficient method, as both context menus and drag-and-drop should be faster > to operate. Contex menus save you from moving your mouse all over the place, > drag-and-drop works on large target areas and at least adding is very > logical, going from source to target.
True, but since all the most easy ways are possible, we need a way for those who are not using drag and drop or context menus all the time. Personally I would be fine without _any_ button. I can drag folders to the places list and delete them with the delete key on my keyboard. But I guess we have a _huge_ problem with discoverabiltiy then. > The Add button is associated with both lists, bot sits there like it > belongs to Places only. Well, it adds things to that list, after all... I think the problem is more about when it is active... however, I agree it is not a perfect solution, the way it is. > > I don't like the idea of the icons changing. This doesn't seem to be > > more discoverable to me. > > If discoverability would be the only aspect, large static buttons are > hard to beat. The icon-buttons are meant to not eat extra space, provide > target area for tooltips, be right in place, making their use almost > as fast as context menus (rather small target areas, but close to the > pointer). Discoverabiltity is not about size only, but about expectations. And I just don't expect an icon to change in a way that it is a button to create a bookmark. > > The other idea with the buttons in between seems quite tempting. > > However, I don't think the image of _moving_ something is what we should > > promote (hence now arrow. We should use the bookmarks concept of > > browsers. So I definitely see the "Places" or "Bookmarks" header in that > > list. That explains. > > Hmm, yeah arrows are kinda overloaded. But it's important to express > the from-to thing here. The thing is, that it isn't a from-to. Your not moving anything, you're adding. Also this approach eats up more space than the current solution. At least I don't have that many places, that the add and remove buttons are a problem, while this would definitely use horizontal space. > > Hmm, I must getting this idea: I know it's not quite easy to do in GTK, > > but why not have to icons aligned right in the header: One bookmark icon > > and one trash icon. One is active, when one can add a bookmark, the > > other one, if one is selected and you can delete it. > > Icons in the headers? The headers are for labels and sorting. I don't > see much room there. Icons of low height with any distance to the cursor > after item selection would be slow to operate. Well, I'm talking about the non-existent header of the Places list here. I still favour it :D I think it's discoverable enough, doesn't use much space... if you don't like it in the header, don't make a header "Places" but put it on top of the list with two buttons aligned on the right. I just thought it looked better in the header. _______________________________________________ Usability mailing list [email protected] http://mail.gnome.org/mailman/listinfo/usability
