Re: First UI component needing replacement.

[Dylan Griffiths <Dylan_G bigfoot com>]

Ken Fox wrote:
> 
> Dylan Griffiths wrote:
> > http://www.thock.com/Dylan/new_dialog.jpg
> 
> I haven't seen anybody comment on how the keyboard interface
> would work, but I'd like to propose it do something like emacs.
> 
> 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.

Maybe not.  This seems like something that probably would be very hard to
advertise to the user, and I'm not sure where in the dialog it would make
sense.  When in the text entry field, space should action like space.  On
buttons, it should act like a mouse click or enter.  In the tree or
listview, it should probably be the equivalent of page down if we want to
keep consistency with the rest of Unix :)

>   <?>          filter file display looking for files that begin
>                with what's currently in the filename field

Entry of regular expressions would very much be a feature I'd like to
incorporate, besides simple mime type filtering.  For a simple common file
dialog, filtering based on MIME type or regular expression (or some
combination) would proably be the most we'd want to implement.

For the system filemanager, though, we'd want to ensure that the user could
select a group of files with nothing whatsoever in common easily (through
shift+click perhaps).. but that's another discussion (
http://www.acm.org/cacm/AUG96/antimac.htm )
 
>   </>          interpret the filename field as a directory and
>                cd there; clear the filename field after

Better still, if the filename is NOT a dir that exists, do not clear it. 
There's no need to punish a user for a typo.
 
>   <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

Sounds like something totally unexpected.  I expect backspace to backspace
with no special cases.  I can't see why adding this would be good or obvious
for any users (except maybe Emacs users).
 
>   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
>   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 </>.

There you go, giving multiple meanings to different keys based on the
context.  Maybe it could be an enchanced Emacs-dialog-mode, but most users
will need a few years of computer usage before they become proficient enough
to consider having multiple actions based on context (note: "average"
computer user defined as someone who just uses it for web/email/etc).  For
reasons of consistency, I prefer to keep the dialog shortcuts functioning in
one way only.
 
> The filename text field should have the keyboard focus
> automatically too.

Very much agreed.
 
> This key binding seems natural to me -- if you just type a
> pathname, it automatically does the right thing (and can give
> you filename listings and autocompletion at every step of the
> way). The keystrokes "../" will backup a directory level which
> is pretty common finger memory for Unix users.

Yes.  Most users aren't familiar with the concept of directories or
hierachical organization, though.  But that's yet another UI discussion of
mine for a completly context-based interface that is navigated like Quake is
:)
 
> I'd also like the file type field to allow keyboard input. Any
> input to this field should be a file globbing pattern that's
> incrementally applied -- as soon as a character is typed the file
> list is filtered. If the user hasn't typed a wildcard, a trailing
> * should be assumed. Filters should be remembered between
> sessions and appear in the drop-down filter list. (There should
> also be hooks for advanced users to put in a hunk of extension
> language code (Guile, Perl, etc.) to make advanced filters.)

That would be the purpose of the File Name field accepting regular
expressions.  The MIME type field is to filter MIME types only, and allows
programs such as Netscape to say, "I just want to show HTML files right
now."  I'd prefer if there was a way to specify several MIME types to filter
in or out cleanly, but I'm not sure how to expand beyond a "All
Types/Specific MIME type" pulldown box.
 
> I'd also like to see a URL browsing option so that ftp and http
> servers can be browsed similar to local file systems. (This could
> be an "advanced" option on the dialog that appears when a "more"
> button is clicked.)

No No No No No No No No No :)

FTP is very different from a proper file system.  Integration of such code
is messy.  Have you ever tried to use anything beyond browsing into
compressed files in Midnight Commander?  HTTP itself is so stateless as to
be useless beyond simple browsing.

I can see supporting compressed files as slow directories, but not HTTP and
FTP.  If you want file sharing, enable Samba, NFS, Coda, or one of the other
*proper* filesystems which would not clutter the interface and code.

> 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.

I like the idea of having it so that users can tab to an advanced view of
the file dialog.  The advanced view could let users adjust local (specific
to this program, such as the MRU directory list) and global
(non-app-specific data) options.  Filtering based on owner, group, dates,
etc, would be very nice.  I don't think we should include an entire global
find dialog.  That would be best served by a separate program, IMO (I've
always liked the PowerDesk file finder application.. I'll post screenshots
if anyone is interested in the UI of it).

Remember: our focus is a simple dialog to be used often by the user just to
select a name or directory.  Nothing more.  We should include a few features
to let the advanced users use this operation faster, and include hints so
that starting users can pick up an understanding faster (the principle of
least surprise).  We do not want to replicate the functionality of a remote
file system browser, find applet, file manager, or any other myriad of
applications that most people want to glom onto the file dialog in some
way.  That Would Be Bad :)
 
> - Ken

-- 
    www.kuro5hin.org -- technology and culture, from the trenches.