Re: [Usability] Open Files - Search

[Matthew Fellows <matt fellows onegeek com au>]

The open file dialog has annoyed me for quite some time aside from 
lacking an integrated search function.

They can be summarised as follows:

a) The breadcrumb bar doesn't default to displaying the full path. It
only shows from the current user's folder onwards, before that it uses
an arrow to indicate there are previous folders. I think it would be
easier if the full path were there.

b) The breadcrumbs and the location bar essentially do the same thing -
why not join them? 

For 'basic' users, I would think that they for the most part will be
clicking on folders and icons to navigate and therefore could ignore the
location/breadcrumb bar. So the merge might not effect their usage so
much. 

For other users, they have the option (the power) to type in the address
and get all the auto-completions as well as click on breadcrumbs or
files/folders. 

c) For the "add" and "remove" buttons, the tooltip says "add the folder
[folder] to the list bookmarks" but the heading for the so-called
bookmarks is "places". A small gripe i know, but to be consistent either
the heading should be "bookmarks" or the tooltip should read something
like "Add the folder [folder] as a bookmark in places"

With that said, i think Thorsten's design is a great improvement on the
existing dialog as not only does it solve a) and b), it provides more -
i.e. search - and takes up less space.

I can however, see what Matthew Thomas is saying (in regards to being
more obvious). I think there are at least a couple things to it: 

1) Unless you type in the location bar you won't know that it can do
search. So many users will never even know of the feature.

2) Will it be desirable to have search results always appear when typing
in the location bar? I think in some cases it might just be overkill or
a waste or real estate.

The only way I see of overcoming these problems is to segregate the two,
or provide a remembered option (say a checkbox) in close proximity to
the location bar to enable/disable search.

Perhaps a more consistent way to integrate search into the dialog box
would be to provide a separate search field at the bottom of the window
which is activated by a button or shortcut key (unfortunately using "/"
as a shortcut in this case won't work), much like mozilla, vim and many
other linux apps. Perhaps this could be a merge of Thorsten's design
with the one from
http://log.emmanuelebassi.net/archives/2007/05/company-calls/.

What do you guys think?

On Fri, 2007-05-11 at 17:01 +0200, Thorsten Wilms wrote:
> On Sat, May 12, 2007 at 02:33:21AM +1200, Matthew Paul Thomas wrote:
> > >
> > > http://thorwil.wordpress.com/2007/05/09/gtk-open-files-search/
> > > ...
> > 
> > I agree with the idea of having a search field that is more obvious and 
> > less awkward than a Place. But even after reading the proposal twice, 
> > I'm still not sure where your search field *is*, so I'm not sure that 
> > this is an improvement. :-) 
> 
> Search field, location and path-bar are one. No toggling, no having 
> to focus.
> Want to search? just type.
> Want to go one level up? Just hit backspace or enter ../.
> Want to enter an aboslute path? Just start with /
> Want to use only the arrow keys for navigation? Just use them.
> Nothing of this gets in the way if you want to navigate by mouse 
> only.
> 
> > Would entering text in the location field 
> > perform a search? 
> 
> In the one existing entry yes.
> 
> > If so, would that prevent people from using the Up 
> > and Down keys in auto-completion? 
> 
> First down key would select the firts item of the list view, 
> then you could move up/down there.
> 
> > What would happen if there was a partial match in the current folder, 
> > but an exact match inside a subfolder?
> 
> I think all matches for the current folder should be listed before 
> any sub-folder hits. There could be an extra rule to list exact 
> matches first, though. Maybe with relative path in front, instead 
> of having headers.
> 
> 
> > I agree with Calum that search should be a separate field, because I 
> > think it wouldn't be obvious otherwise. But I disagree that this field 
> > should be hidden until a button is clicked, for much the same reason.
> 
> Obvious? Just type anything and you would see it in action.
> 
> 
> 
> > By the way, if that mockup is based on a real application's Open 
> > dialog, please report a bug that the dialog's title shouldn't end in 
> > "...". :-)
> 
> Gedit. So, you read it twice, eh ;)
> 
> Can somone with Gnome 2.18 please check if Gedit still uses 
> "Open Files ..." as window title?
> 
>