Re: RFC: On-line Content Filtering of directories

[Maciej Katafiasz <ml mathrick org>]

Dnia 27-04-2005, śro o godzinie 13:33 +0200, Alexander Larsson napisał:
> Also, we likely need a "next match" keybinding for the typeahead system.
> Someone on irc suggested ctrl-g, which is what most apps use for "find
> next".

Errr. Let me remind you that C-g is emacs' universal "cancel" key,
particularly cancel incremental search. Binding it to "next match" is
like punch in the face for any emacser, and I repeatedly hate gecko for
doing that to me :>

> > *) As this feature has to be explicitly activated, i mean, to use it
> > you have to press a button or a combination of keys and as the view
> > looses the filtering when closing a window or hidding the filtering
> > bar, I don't think it is that confusing as there is an explicit visual
> > feedback (that is the filtering bar) telling the user that the
> > contents of the directory are beeing filtered.
> 
> Yeah, that is true. (Although I think it should be made even more
> obvious that the window/view is filtered, and how to get out of that if
> possible.)

We could also use background colours (as you suggest below), and for
colourblind users, also embed emblem in the background.

> My main concern is trying to limit the amount of overlapping features,
> so that each addition of a feature adds something important over the
> existing ones. Each overlapping feature increase complexity, make the UI
> harder to understand/more crowded and increase maintenance costs. 

The question is, is it worthy at all to keep glob selection in presence
of filtered view? I'd say we just make it automagically switch into glob
mode when any of * or ? is entered, and forget about today's glob
selection.

> What are the ways we can make this more obvious to the user?
> Here are some ideas:
> * Have a remove button in the filtering bar, similar to the one firefox
> has in its search bar.

Yes, that's definitely very good idea. I think FF has imposed kind of
standard behaviour upon all subsequent implementations of search bars of
all kinds :)

> * Perhaps make it more obvious that the filter is on the name, by having
> "name" somewhere on the filter bar. (Do we want to filter on other
> fields too btw? say type, or owner)
> * Sometimes you might not see the whole window, or just not look at the
> bottom. Maybe we could figure out some other (additional) way to say
> that this is a filtered view that is visible in the whole window, or at
> least in more places. Maybe we can use colors? background color? some
> sort of border around the view? different window title?
> * The status bar should perhaps say something like "3 items (of 28)" to
> make it obvious the count is of the filtered items

I'd make it something like "3 matching items (of 28)". Just "3 of 28"
isn't really all that clear.

> Also: 
> * Need a mnemonic on the filter label
> * I think ctrl-g might be more useful for "next typeahead match" than
> for filtering. We should pick a different accelerator.

Firefox uses C-k, and it is (IMHO) rather fine choice, and gets us bonus
points for being consistent with FF. (I guess C-k is it because it's
right next to C-l, mnemonic for location bar. Which would work according
to the same logic for browser windows, and shouldn't hurt for spatial
ones)

> Some behavioural questions:
> * What happens with your selection when you filter? Say you have
> something selected, and then you filter so that item is not visible,
> then you delete. Is the file deleted?

Definitely not.

> * Same with selection changes when filtering. Is select by
> pattern/select all limited by the filter?

Of course. Question is if that change is transient, ie. if user selects,
then filters, then unfilters without changing selection, do we revert to
original selection, or rather stay with filtered one? I'd weight more
towards transient interpretation, but then it may clash with previous
point, that is, it may be not obvious to the user what happens if she
selects, filters, and then hits Delete.

> * What happens if you create a new folder/templated file or copy a file
> into a filtered view. If we do nothing, the new (say "untitled folder")
> file won't be visible until you remove the filter (not letting you
> rename the folder), which is sort of strange. Another perhaps surprising
> behaviour (or perhaps not) is when you rename a file and it disappears
> (because it was filtered out).

If that happens, simply cancel the filter.

> * How does filtering work in manual arrangement mode. Do we keep the
> positions, leading to lots of empty space? I guess one could say you
> just shouldn't use this mode with filtering. But it leads to the
> question, do we allow filtering on the desktop?

No (for the desktop). If you need filtering on your desktop, something
is very wrong :). As for manual arrangement, simply make it switch to
automatic layout when filtering, I'd say. I don't think it's at all
possible to do anything else in reasonable way, and again, if you have
manually laid out folder *and* need filtering, then you should probably
reconsider the way you organise your stuff.

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>