Re: RFC: On-line Content Filtering of directories

[Maciej Katafiasz <ml mathrick org>]

Dnia 02-05-2005, pon o godzinie 14:13 +0200, Alexander Larsson napisał:
> > 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 :>
> 
> I refuse to let the bizzare interface of some ancient editor affect the
> design of a modern desktop (and I'm a emacs user). C-g is "find next
> match" in most modern UIs, end of story.

Eww, c'mon. I won't continue on that, however I fail to see how "C-g as
next match" is any more modern than "C-g is cancel". (This is similar to
WordStar clipboard (C-Insert, S-Insert, S-Delete) vs. CUA clipboard
(C-{x,c,v}). And we keep supporting old, bizzare interface of WordStar,
which I happen to be using, as it is simply more convenient). 
I sometimes miss global "back out" concept in GNOME, too, but that's
offtopic.

> > > 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.
> 
> The listview is a bit problematic here though.

Yes, a bit. Maybe coloured frame around the window? Still, that leaves
colourblind users out in the cold. I still want something more than
annotation in title.

> > 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.
> 
> I'm not sure what glob mode is? 

"Normal" filtering mode:

"foo" -> match all files with "foo" anywhere in name

Glob mode:

"*foo" -> match all files matching "*foo" glob

> Glob selection has none of the problems that filtering has, because glob
> select doesn't add any new persistent concepts. All it does is add a
> method for quickly selecting a set of files you could manually have
> selected. Any feature, like filtering, that introduces a new concept
> that is persistent in the interface however, interacts with *all* other
> features in the whole application. Witness for instance how the
> filtering concepts interact with the current folder selection concepts
> in sometimes confusing and complicated ways. It will also interact with
> and limite all future features additions. This is why I worry about
> things like this.

Of course, I understand that. I believe however that it is interesting
(and wanted) enough feature to warrant extra effort to get it right, and
get it in.

> > 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)
> 
> Ctrl-k goes to the google field for me, whereas the more filter-like
> find bar is triggered by Ctrl-F (which is used by the tree view
> typeahead).

Yes. I meant google field. Which is the find bar you mention, the one
that gets triggered by typeahead in gecko?

> > > 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.
> 
> So, the selection is changed by applying a filter then? This is
> certainly a complication of the user model of the "current selection". 

I don't think it really complicates the interaction. After all, it's
only an application of WYSIWYG philosophy, which is much more spatial
than bizzare YAFIYGI(*) from ancient editors :)

(*) You Asked For It, You Got It

> I agree that deleting a file that you didn't see is horribly bad, but this
> leads to a redefinition of what the current selection is and how it
> works. For instance is the file re-selected when you cancel the filter?
>
> > > * 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.
> 
> Exactly. Neither option is perfect...

We could take a stab at exploiting natural tendency to think in WYSIWYG
terms. Then we could make it transient, which has the best
user-experience properties, and just expect users to figure it out
naturally. Probably worth testing.

> > > * 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.
> 
> Cancelling the filter whenever something changes is certainly an option.
> I'm not sure its all that nice though. It means you can't really do much
> work in the filtered view. Cancelling only when a change affected an
> filtered file would make this more useful, but its suddenly no longer
> obvious when the filter is cancelled. 

Again, if we can make it work DWIM-enough, users shouldn't have much
problems figuring out when filtering gets cancelled, since it would
happen when they expect it to :). Another possibilty is to never cancel,
and just force newly created / renamed folder etc. to stay in the view.
This would also be in a way working as expected, and would accomodate
for the organising case where you filter, *then* create folder for
matches, and move them there (I frequently do that with images).

> I guess read-only use of filtering isn't affected, but it seems harder
> to make read-write use of a filtered view work well.

Yes, the idea is we can either see filtering as read-only and shape UI
accordingly, which is relatively easy, or we allow read-write, but then
it's lots of case-by-case determining what we want to support. I think
it is possible to get read-write case right.

Cheers,
Maciej

-- 
Maciej Katafiasz <ml mathrick org>