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

[Thorsten Wilms <t_w_ freenet de>]

On Sat, Feb 24, 2007 at 01:08:40PM +0100, David Christian Berg wrote:

> 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 icon-buttons are about exactly that. Offering discoverability  
without wasting space.

 
> 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.

Idealy it would be perceived as buttons appearing hovering over the 
icons. I don't like delays, but a little animation could help.


> > 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.

With from-to I mean adding the item selected in the folder/file list 
(from, source) _to_ the Places list (target). While I agree that the 
arrow button could be mistaken to mean 'move', it will surely cause 
an expectation that it will depend on the selection on the right side.

It takes less absolute pixels. My Places lists comes with scrollbars ...
If yours doesn't, you either don't use Places much or belong to what 
I suspect are the lucky few for whom the concept works out really well.
Yes, it's a trade-off, regarding horizontal space. I never felt tempted 
to make a file dialog screen-wide, but using full height would make 
sense, if only for my grown Places list.


> > > 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.

The Places list has a header. So I must conclude that I have no idea what 
you are talking about. Care to make a mockup? :)


-- 
Thorsten Wilms

Thorwil's Creature Illustrations:
http://www.printfection.com/thorwil