Re: First UI component needing replacement.

[Ken Fox <kfox vulpes com>]

"Guillermo S. Romero / Familia Romero" wrote:
> kfox@vulpes.com (2000-08-13 at 1016.11 -0400):
> > In the filename text field, use these key bindings:
> >   <space>      auto-complete as much as possible using what's
> >                currently in the filename field as the prefix.
> >                letter case isn't used to auto-complete unless
> >                an option with both upper and lower case exist.
> 
> Space? And how do you insert a space? I would vote for ctrl-tab or
> ctrl-right_arrow. Shell users can live with "\ " for spaces, but I
> doubt GUI-only users will.

The file dialog is accepting two different kinds of files: files
that must exist for reading, and files that may/may not exist for
writing. IMHO, the majority of dialog use is for reading existing
files (would love to have hard data on the subject...) Using
<space> and <?> doesn't cause any major problem when selecting
existing files.

> >   <?>          filter file display looking for files that begin
> >                with what's currently in the filename field
> 
> The same as above, I can type "\?" but will GUI users?

How many file names have you seen with "?" in the name? Or space
for that matter?

Perhaps this is a matter of choice, but I'd prefer to not use
either of those characters in my file names if they made entering
file names easier.

> >   </>          interpret the filename field as a directory and
> >                cd there; clear the filename field after
> 
> Clear? Not, if the guy types "foo/" before "bar.txt" (getting
> "foo/bar.txt"). Right way IMO would be change to foo, but keep the
> file name bar.txt. Data that can be kept, must be kept, not deleted.

I stand by my original behavior. If I type "foo/" into the file
name field, the system should "cd foo" and then add "foo" to the
current directory location display. This could either be shown in
a directory tree or a text field. If I have both a directory in
the text field *and* an active directory being displayed, that's
confusing. Which one will it use? (The Motif file dialog has
this weird behavior. You can "filter" one directory and then
type in a totally different one.)

Removing the directory name from the file field also means the
file field stays short and doesn't horizontally scroll.

> >   <backspace>  if the filename field is empty and there is a
> >                directory history (i.e. "/" was used to cd) then
> >                switch back to the previous directory and restore
> >                the old filename field contents
> >                otherwise, just delete the character left of mark
> 
> Do you mean foo.txt^H^H^H^H^H^H^H^H -> ../foo.txt ?
> Not pretty logic, IMO. I would vote for ctrl-left_arrow.

No. If I type "foo/bar/blah" then the file name field goes through
these states:

f
fo
foo
foo/
b
ba
bar
bar/
b
bl
bla
blah

Every time I hit </> the system takes the directory off, cd's there
and lets me enter more text.

Now, say after I enter "bar/" I decide that was a mistake. Either I
hit </> by mistake or the file I'm looking for isn't in that directory.
Pressing <backspace> should delete the effect of the previous </> I
hit. In other words, <backspace> should restore the state of the
buffer prior to the "cd bar" (i.e. cd back to foo) and then leave
"bar" sitting in the filename field. If I've backspaced all the way
back to my original state, then the system does nothing (except
beeping maybe).

The idea is to replicate the simple file name input commands, but
have the user interface react in such a way that the memory load is
transferred from the user to the computer. That's the whole point
right? Making the user's life easier? I want the computer to
anticipate what I need and give it to me before I ask. When I type
in a directory name I'm obviously going to start typing in the name
of a file in *that* directory. Why shouldn't the computer anticipate
this and automatically show the files in that directory? You want
me to *remember* what the computer already *knows*?

We have point-and-grunt for people who don't know how to type. The
keyboard interface can afford a little bit of a learning curve to
get the most out of it.

> >   <tab>        switch focus to the file type field
> 
> Logical with the rest of widgets. And shift-tab for back.

Doesn't it bother you that you can't create a file name with
tabs in it? ;)

> >   Anything else just inserts into the filename field at the mark.
> >   If the dialog is in "read file" mode, it doesn't allow you to
> >   type letters that don't match a file. (Note that the behavior
> 
> Users will think that keyboard is dirty or app broken.

Why? The system beeps and displays a little popup-tip window over
the text field that says "no such file". You don't want people
typing in non-existant file names when the dialog is asking for
a file to read.

> >   of <space> works fine to select files with spaces in the name.)
> >   If the dialog is in "write file" mode then any character that
> >   doesn't match an existing file is just inserted at the mark.
> >   This includes <space> and <?> but not </>.
> 
> I see, but why give different meaning to keys based in mode?

In "read file" mode (these are not GUI modes by the way, this is
a constraint on the file dialog imposed by what the user is trying
to do) it's not possible to enter a non-existant file. The only
thing the user can do is provide hints on what file to select. As
such the user *never* enters a file name -- she only enters a
pattern that matches one file. The <space> becomes an "I'm tired
of typing can you figure anything out for me" key.

In "write file" mode most of what I type will be similar as in
read file mode. I'll often over-write files, choose from existing
directories to locate my file in, etc. Once I start typing a name
it rarely collides with another name, even in the first few
characters. If I hit <space> in the middle of entering a new name,
there's nothing in the system with that name yet and so nothing
to complete and the system just puts in the space. The worst case
scenario is that I *wanted* the system to auto-complete and I have
to <backspace> back to the point where I made the typo. (It was
probably a typo because if I'm expecting to auto-complete I'm
expecting that all my input to this point already existed as a
file name.)

> For example, how do you overwrite a file then? Normally I type or
> select, then hit any confirmations I am asked (Overwrite / Cancel).

If you have the following files in a directory:

   Makefile
   README
   hello world.c
   goodbye cruel world.c

and a dialog pops up asking you to save, then typing

   <m><space> expands to Makefile
   <h><space> expands to hello world.c

You choose the one you want, hit return to make the selection and
then return again to confirm the over-write.

If you want to save to a *new* file, you just type in the new
name and hit return.

A problem occurs if you want to save the file as "go fish.txt".
You start typing

   <g><o><space>

which expands to "goodbye cruel world.c". I agree that sucks. The
problem is solved by either (1) not using spaces in file names (not
that restrictive, but still annoying) or (2) turning off auto-completion
for output files (very annoying since the feature saves a lot of
typing) or (3) using a different key binding for auto-completion.

The default might be (3) with the key binding set to ctrl-tab like
you suggested. That's not friendly to advanced users who will
probably still use command shells and prefer not to put spaces in
file names. And the stupid space bar is about 7 times as large as
a regular key and it's almost totally unused!

> BTW, file completion should be requested not automatic, there is
> nothing worse than a computer trying to be stupidly obliging. How to
> explain it... I prefer a passive machine that a stupid active
> one.

IMHO <space> requests file completion -- the computer is not
doing anything automatic in the text field. Where the computer is
doing things automatically is in the file list view where switching
directories automatically updates the display and partially typing
a file name highlights the files that match. There isn't any
trouble here because if the computer guesses wrong it hasn't
wasted me any time.

> > Finally, the open file dialog *must* allow easy access to an
> > advanced find file dialog. This could either be a separate tab
> > in the dialog or on the "more" section. The find options must
> > allow filtering by creation/modification times, file types,
> > file names, owner and location. Treating the results of the
> > find as a virtual filesystem seems very natural to me -- once
> > the find finishes, just drop the user into the standard open
> > dialog with the list/tree hooked up to the find results instead
> > of the underlying filesystem.
> 
> Sounds like Windows search. Works fine when you find the files you
> really want, but not quite good other cases, cos locks you in the
> results. This a field that needs lot of work. What happens if you get
> files and directories as result?

Well, I was thinking the Unix find command, but if you like Windows
more, sure. ;)

The trouble with find is that it's hard to get the output into a
file open dialog where I can easily select a file name. If there were
a way to create a virtual filesystem view (complete with directory
trees and file lists) of find's output, then I can use all my
finger memory to select a file from find's output. If the file
isn't in find's output, then I try a different find criteria -- or
run a different find command (glimpse or something). The key is
to get the output of the find command formatted into the file dialog
as if it were "just another directory view".

- Ken