Re: [Usability] File Dialog Add/Remove Places Mockup

[David Christian Berg <david sipsolutions net>]

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.