Re: [Usability] Open Files - Search

[Jacob Beauregard <jake13jake comcast net>]

I love list filtering. I'm thinking that users would expect a list filtering 
tool to filter based on the column information as the default.

As opposed to Calum, I don't find this very complex. It may be a bit 
cluttered, though, and might slow users down a little bit. I think it would 
be good to separate the search subtrees from the rest of everything was a 
default. Like, instead of being in the. main part of the file list, perhaps 
next to that gap by the "All Files" combo box, and then choosing one of them 
could toggle what is set to view above. Perhaps with the proper descriptor 
across the top "Files," "Files containing -," "Other folders." 

Powerful tools aren't generally hard to use if they're well-presented.

I love using xor to toggle bits, it's my favorite operator! Still, don't know 
enough about GTK to really talk about how one would toggle stuff around a 
GUI.

On Wednesday 09 May 2007 02:01:58 pm Thorsten Wilms wrote:
> On Wed, May 09, 2007 at 05:56:12PM +0100, Calum Benson wrote:
> > On Wed, 2007-05-09 at 18:27 +0200, Thorsten Wilms wrote:
> > > Adding modality doesn't make things simpler.
> >
> > I agree (although it needn't make things harder either); I just
> > suggested it because our file dialog is too cluttered already to allow a
> > permanent, separate search box like OSX has.
>
> Cluttered ... I thought about removing the Places header, but it shows the
> P mnemonic. I wanted to (again) remove the Add and Delete buttons, but they
> too show mnemonis ... But now I wonder: How about not showing the
> Add/Delete buttons initially. Show Delete if a Places item is selected,
> show Add if a folder is selected?
>
> > Well, one concern I'd have with your approach would be how quickly the
> > results list could populate itself as you typed.  Most of the time I'm
> > not interested in the search results because I know where I'm going, so
> > unless the results update was so instantaneous as to not delay the
> > appearance of each letter I typed, I would find it annoying.  Having a
> > separate search 'mode' might turn out to be necessary for that reason
> > alone.
>
> Before something is typed, you'd see a file list like now. It would not
> go away until the first hit is found. With incremental search, results
> for the current folder should be practically instantaneous.
>
> Searching all the way down and system-wide takes time of course. The
> results should appear as they come in and some spinning symbol as the
> last item could indicate the search is still in progress.
>
> > Being a minimalistic sort of guy, I guess I also prefer the simplicity
> > of the results list in OSX-- it doesn't have explicit headers in the
> > results area, it just shows you a list of filenames.  For me, that's
> > enough to pick the file I was looking for first time, although I
> > certainly understand why you've included the headers in your mockup.
> > (And also that I'm not really a typical user any more than anyone on
> > this list probably is...)
>
> The results do belong to different categories and the user should not be
> left wondering why something is in the results. There could be files with
> the same name, but from different folders. What would you do in the last
> case, with OSX?