Re: [Usability] The eternal fileselector dilemma :)

[Lemmit Kaplinski <lemmit kaplinski com>]

Hi,

Kalle Vahlman wrote:

> I take that as a request not to, and act accordingly.
> (the reason was already explained)
>  
Actually it was just a question. But I usually don't CC anyone who has 
not asked it. If one send an email to a list, he or she is clearly 
interested in getting answers. Considering this is a list which attracts 
people with (way) above-average knowledge of computers, I'd say they are 
proficient enough to subscribe or check the archives. But this is 
actually irrelevant to Gnome, although a usability issue in itself.

> 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
> ?-)
>  
I re-read the part where I speak of bookmarks. I tried thinking of ways 
to state my approval of bookmakrs more strongly, but short of "I love 
bookmarks man, I really do ;)", I couldn't come up with anything better. 
But again - bookmarks are cool. From my dead cold hands...

> Basicly, you should never have to scroll the list. With bookmarks and
>  
Ahh - where does this come from? HIG? Usability studies?

> 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.
>  
No. Once you have expanded the dialog, it becomes primary. There are two 
states of the dialog:
1. The default (I'll file another bugreoprt because the dialog does not 
remember it's state) state where the primary function is taken care of 
by the "Volumes and Bookmarks" menu (can we call it "Save to Folder" as 
Alan did?). There is no filechooser in this state, although when it 
comes to it, the filename entry can be used as one from the keyboard.
2. The expanded view. The reason you are switching to this state is only 
to use the filebrowser (forget about adding/deletingbookmarks ATM - this 
can be handled by other means). Therefore _for the particular user at 
the particular time_ the file browser interface becomes the primary 
interface.

So it is actually not a dialog with extra options hidden. It is two 
dialogs rolled into one.

And btw . another bug (153828) - it does not remember its state.

> 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.
>  
File-roller is to blame, as is the filechooser. As we and Alan 
understood, the fact is that applications modify the filechooser while I 
like it and others don't). Careless pollution with options is to be 
blamed on file-roller. The guilt of teh chooser is that it has not 
provided developers with a chooser that would lend itself to 
modifications. That is a fact and has to be faced whether it is liked or 
not.

> 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.
>  
*Filed two bug: 153785 (expanding horizontally) and * 153827 (the gedit 
inconsistency)*
I have aslo collected most bugs** relevant** to this discussion on my 
webpage (scroll down to the end).
*

> Two panes are stupid and unintuiutive when opening (choosing) directories.
>  
Hmm, you've got a point there. But ATM I do not wish to discuss the 
exact contents of the expanded area. I'd simply say that the current 
layout wastes room and I would vote for ripping out the duplicate list 
at the left and reserving the whole area for a filebrowser of some sort 
(buttons/no buttons, two-paned/three-paned - there are multitude of 
options.)

> 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.
>  
Is there a "Gnome definition of Spatial for Dummies" around somewhere - 
you and I have very different understanding of the term.

The best,

L.