Re: First UI component needing replacement.

[colin z robertson <c z robertson ndirect co uk>]

On Mon, Aug 14, 2000 at 03:45:34PM -0600, Dylan Griffiths wrote:
> colin z robertson wrote:
> > I do it all the time. The last command I entered at the command line
> > was "xmms win/music/full_tunes/*.mp3 &". I do the same with The Gimp
> > and NEdit as well, even closing The Gimp and running it again just to
> > open another set of files. A file open dialog must support selecting
> > multiple files.
> 
> Yes, but I would not have the select single file dialog and the select
> multiple file dialog work in the same way.  The select single file dialog is
> very much oriented towards one file, as is.

No, I don't like this. Does it not imply having seperate "open one"
and "open multiple" commands? That's very ugly. Since opening multiple
files is such a common occurence and opening a single file should be
possible with a multiple file opener I say keep them together.

If the open dialog is oriented towards opening only one file then
that's a flaw in the dialog rather than an indication that there need
to be two dialogs. The Windows open dialog handles selecting multiple
files in the same directory fairly gracefully. The Mozilla-style view
expands that to work well with files from multiple directories.

Btw, the app should be able to say whether the dialog should be
multiply or singly selecting, and save dialogs will always be singly
selecting.


> XMMS has a very nicely modified dialog that seems perfect for this.  I use
> it when I add files to my playlist in XMMS.  It has a selection of buttons:
> 
> [Add Selected] [Add All] [Close]

Oh. So it has. I'd been messing around with the dialog you get from
the eject button until I gave up and used the command line. Now that's
bad UI.


> With only close closing the dialog.  Such a setup, plus modification to the
> layout of the single file dialog, could become an adequate multiple file
> dialo (IMO).

Possible, but I don't like the idea of them being seperate. How about
if the open dialog came with a button saying "Open Multiple >>" that
expanded the dialog with the extra features required? Too complex?


> > The Mozilla-style single tree view should be one of a set of possible
> > views. So the set would be something like: Mozilla style, dual pane
> > (Dylan style), single pane (Windows style). The latter two would also
> > have options for large icons, small icons, details, etc.
> 
> Why do we want Windows style at all?  The style I made was to address some
> of its shortfalls, as well as the shortfalls of the GTK+ common file dialog.

Uhm. User preference? Actually you're right. I wouldn't be too sad if
it wasn't there.

Ok, here's something I'd really like to see: Since these dialogs are
such a controversial issue, and since the chances of satisfying
everyone are precisely zero, it'd be nice if dialogs could be a
pluggable component. Implemented, from the user's point of view, in a
similar way to theme switching or WM selection. I suppose this is more
of a "pacify the hardened unix hacker" issue rather than a usability
issue, but I think it would be a Good Thing.


> I've played with it, as you suggested.  I don't see this.  All they have is
> a combined tree view of files and directories.  For saving, the user
> probably wants the non-ambiguity of only being able to select on directory.

Not so. All save dialogs I've seen include a file view. I often select
a file either to overwrite it or because the name I want is close to
that name.
 
> For loading, I think this is better addressed by having a dialog which lets
> you go around (via the MRU or normal browsing) and "Add" or "Add all files
> in directory" to the list returned.

Possibly, but it has to be part of the same dialog.


> What do you think of the somewhat less drastic modification to the file
> dialog for many file selection?  Does that meet with your approval?  Because
> I would prefer that the common * dialogs look at least vaguely similar to
> each other (at least until the user starts to customize the advanced
> behaviour :-)).

Well, as a default they would look like each other, Mozilla-style
being an option (probably not the default) on open and save dialogs.


> The funny thing about saying, "with all due respect," is that people often
> say things that make you wonder if they respect you at all.

The funny thing is that nobody takes words at their face value. I
apologise if I gave you that impression, because it's simply not the
case. You do have my respect. But, in this case, there was nothing in
your rapid dismissal of an interesting idea that showed that you
understood it. 


> I did just use Mozilla to double check my impressions of its combined
> tree-view thing.  It didn't seem to allow highlighting of multiple files
> easily.  And if we did make a version that did that, covering ranges would
> be tricky.
> 
> Consider: shift+arrow expands the range of select.  Shift+mouse click also
> does this.  You can go all the way to the top & botton with shit+home and
> shift+end (in sane dialogs).  How do we do multiple select if the user has a
> few directories drill into, but not all?  Do we select all the files in all
> the directories?  Or do we make it harder to select ranges so the user
> doesn't accidently shoot themselves in the foot?

hmm. I believe that the only way to do it would be only to select
files, and only to select files which were visible. The open dialogs
that we've been discussing so far only don't allow the selection of
directories, and for the sake of our apps we have to continue this
behaviour. So if the tree were like this:

|-foo
|-v dir1
| |-> dir2
| |-v dir3
| | |-file
| | |-file
| | |-file
| |-file
| |-file
| |-file
|-bar

and the user selected from foo to bar, the selection includes foo, all
the files in dir1, all the files in dir3, and bar. It does not include
any of the files in dir2. This means that if the user wants all the
files in a directory it will have to be expanded, resulting in more
scrolling, but nothing worse than that.

Yes, I suppose if they expanded every directory and, starting at the
top, pressed "shift+end, enter" they'd have a very busy application
for some time to come, but I don't think that's likely to be too much
of a problem.


> As it stands, there are a lot of creeping issues to do with how we'd handle
> selection of files in  a non-arbitrary manor that is similar to how we work
> in other dialogs.  If you want to convince me, write down the definite
> behaviour this dialog will have, and show me how it will not be a complete
> 180 from every other dialog's behaviour with regards to file selection.  I
> don't mind different dialogs, even different looking, but also throwing out
> the basic notions of behaviour is the most evil thing ever.  Just go try to
> use a program which regards tab as [close dialog, save file] and enter as
> [advance to next field] to know what I mean.

Ok, here goes:

The filesystem is represented by means of a single tree showing both
directories and files. Directories are displayed with an icon
indicating whether they are expanded or unexpanded. Files are
displayed with an icon that should be sufficiently different from the
directory icon that they could not be confused.

The dialog also includes a text field and/or file type filter. File
filtering is performed only on files, not directories.

(For all single-clicking read single-clicking with left mouse button.)

Single-clicking on a directory name:
The directory becomes selected, all else unselected. Its name does not
appear in the text field. This is to allow for operations such as
renaming to be performed on the directory.

Single-clicking on a directory icon:
Toggles expansion of the directory's contents.

Single-clicking on a file name or icon:
The file becomes selected, all else unselected. Contents of the text
field is replaced with the file's name.

Shift + single-clicking on any file or directory name or icon:
In a multiple selection context the selection expands to include all
files and directories between the last clicked on item and the current
item. File names are added to the text field, directory names are not.

This would have to include paths in the text field as well. Yes, I
know this would get very long.

In a single selection context, equivalent to single-clicking.

Ctrl + single-clicking on any file or directory name or icon:
In a multiple selection context the selection expands to include the
current item. File names are added to the text field, directory names
are not.

In a single selection context, equivalent to single-clicking.

Enter:
If the text field contains a valid file name or, in a multiple
selection context, multiple valid files, the dialog exits and returns
the files in the text field. Otherwise produce an error message.

Double-clicking on a file name or icon:
Equivalent to single-clicking followed by enter.

Right-clicking:
Context menus?


Ok, have I missed anything? The thing that bothers me about this is
representation of selected directories. A selected directory is not
equivalent to a selected file, but it needs to be allowed so that
renaming, etc, actions can be performed on them (if they are to be
performed at all). If the user knows that the selected directory has
no effect on the files opened then that's not a problem, but if they
don't then they might be disappointed when selecting a range including
files and directories and opening them because they expect the
contents of the selected directory to also be opened. Perhaps
directories could be selected in a different colour, or the directory
name could be displayed in a different colour.

Apart from that, this all looks ok to me. It's not so very different
from other dialog designs. Am I misunderstanding the problem?

colin

  _____________________________                            ____
  rtnl  http://rational.cjb.net     c.z.robertson@ndirect.co.uk
  ak    http://kitching.cjb.net                    icq 13294163