Re: File dialogs: an attempt at a summary

[Christian Rose <menthos menthos com>]

colin z robertson wrote:
> > As I understand it, the file list would reflect the currently selected
> > files, and also vice-versa (if you type in a valid file name or a set of
> > ; delimited names in the file field, those names would be higlighted in
> > the directory view if they are in that directory).
> >
> > If you SHIFT + click some range of files (or CTRL+click a set of files),
> > and then click another file, all files except the most recently clicked
> > one would become unselected, yes (this is the expected behavior).
> >
> > The file text field should immediately reflect that and only show the
> > name of that single file. This is fully consistent with the "files that
> > are selected are also listed in the file list" behavior.
> 
> Yes, the behaviour you describe is exactly the same as the windows
> behaviour, and that would be my preference. However, what Dylan is
> suggesting is the addition of an "add selected" button that would add
> the current selection to the list of opened files, but wouldn't open
> them until the "done" button was pressed. My point is that this "add
> selected" button requires a different behaviour in the file list view.
> It only makes sense if the changes in selection don't directly affect
> the contents of the text field.

I don't like the paradigm of adding files from the file view to the file
name field either. It breaks the "all files that are selected in the
file view are also selected in the file name field and vice-versa"
behavior, because in that scenario there could be more files selected in
the file name field than in the file view.

IMO, the file name field should just be an alternative representation of
the selected files in the file view. They should be tied together. Isn't
that why we have them both, that they are alternate views of the same
thing?

I think that only making the file name field the "decision-making"
widget has severe usability issues. One of those is that you don't get a
good overview of the selected files in the file name field without some
side-wards scrolling, especially if they have to contain the full path
names (as discussed below).


> > Another issue about the file box: is it absolutely necessary to show the
> > full path, even if "you are" in a particular directory, the directory
> > shown in the directory view?
> 
> I know it gets long and unwieldy, but I think it's a prerequisite for
> being able to select files from multiple directories, as can be done
> using an "add selected" button or a Mozilla-style view (my
> preference).

Couldn't just "../" be prepended if the file is located in the parent
directory, for example?

Example (florida-vacation directory beeing the current one):

florida01.jpg; waterskiing.jpg; ../norway-vacation/ship.jpg;
../../pictures/snowman.png

This would reduce clutter in the file name field, by reducing redundant
directory information.
I don't belive that users that are unfamiliar with the ".." naming would
use the file name field anyway for selecting files in different
directories. They would probably just use the file view for selecting
files.

As a side effect, they might actually _learn_ the concept of ".." by
watching it getting prepended in the file name field to the names of
their different-directory file selections in the file view...!

Comments?


Christian



#######################################################################
Christian Rose
http://www.menthos.com                    	    menthos@menthos.com
#######################################################################