Re: [Usability] The eternal fileselector dilemma :)

[Kalle Vahlman <kalle vahlman gmail com>]

On Sun, 26 Sep 2004 21:13:56 +0300, Lemmit Kaplinski
<lemmit kaplinski com> wrote:
> Hi,
> 
> BTW - is it the custom here to CC the author every time?

I take that as a request not to, and act accordingly.
(the reason was already explained)
 
> Kalle Vahlman wrote:
> >Bookmarks are for the _most commonly_ used locations. It's only
> >natural that they don't "cover all possible situations".
> But that is exactly what I said. I also explained that when bookmarks
> don't cut it, one is left with a filebrowser that is hard to use. All my
> problems were with the browser and I like the bookmarks. I do.

I do realize that. I just wanted to counter the impression that there
was anything wrong with the bookmarks (which your text could give).
It's like saying that cars are never going to cook your dinner. Very
true, but makes cars look bad since they don't do something. This is
probably something that needs no further discussion, right? (please
?-)

> >You also strike air with your pixel calculations, though I do agree
> Those were partly added for effect, you are right. But I have proven, as
> best as I can, that the area devoted to the filechooser is ridiculously
> small.

Basicly, you should never have to scroll the list. With bookmarks and
type-to-search on the list you won't have to (too much at least).
Remember that in the save dialog, the filechooser interface is
secondary.

> Once you have clicked the triangle, you most probably want to use
> the browser. Have a look at this screenshot:
> http://bugs.gnome.org/attachment.cgi?id=28031&action=view No comments.

This is sad to look at. The filechooser portion should IMO reserve a
fixed minimum of space (defined like "the list shows x items" where x
is about 5). But also, I think that file-roller (assuming it is
file-roller) is at blame here. Lots of extra options (of which at
least two are stupid and unneccessary) and the same empty space
problem that the expander-embedded chooser has.

> >with two things. First is the fact that the chooser gets wider when
> >it's expanded. It shouldn't, as the whole point of it being wider than
> >neccessary in the first place is that it would change as little as
[snip to reveal context]
> >possible. The duplication of bookmarks is due to this very same
> >reason, and thus neccessary. Furthermore, any changes to the layout of
> You lost me here. Ae you saying that the dialog expands horizontally
> (bad) in order to facilitate the duplicate bookmarks list (worse).
> Sorry, I do not get it.

I'm saying that it shouldn't get wider when expanded. It should be
initially so wide that it can accommodate the chooser parts. The
duplication is not good, but it's far worse if you remove it
on-the-fly.

> >the common chooser elements should be done gobally, not just for the
> >save dialog. You can't have stuff moving around in only slightly
> >different situations and claim it intuitive.
> You are talking about the Open dialog? Well:
> * In case of gedit (and probably others as well) it is already out of
> sync. For the Save dialog, the "Character Coding" menu is at the top,
> but for the Open dialog, it is at the bottom.

A bug, that can be corrected.

> * I believe that my dreamchooser would work for both Save and Open: the
> pop-up menus with bookmarks, file types and such are at the top and the
> two panes or however the browsing component looks like is at the bottom..

Two panes are stupid and unintuiutive when opening (choosing) directories.

> I use the spatial stuff. I have used Mac OS (and before that Amiga) for
> a long-long time and for me, a Desktop is naturally spatial. I was
> delighted when Nautilus started supporting it. Nevertheless I like
> navigating down my folder structure.

Yes, and as I said, that's a no-no for the spatial model. A mixed-mode
of both is something I think shouldn't be encouraged (because it
pretty much degrades the idea and usage of spatialness). I wouldn't
mind if someone made a navigable chooser and a gconf key to control
the behaviour. Just don't break the model.

> (I won't talk about the metadata-powered search in this thread)

Well, IMO that's what the spatial stuff is for. And so I think it's
useless to try to convert the spatial stuff to work with navigational
style.

-- 
Kalle Vahlman, zuh iki fi