[Nautilus-list] Re: "Location" box

["John Sullivan" <sullivan eazel com>]

I'm cc:ing this response to nautilus-list because others may benefit from or
want to participate in the discussion of location bar UI.

on 6/6/00 5:35 PM, Seth Nickell at snickell stanford edu wrote:

> Its seems fairly clear that displaying: "file:///root/new%20folder/" is
> undesirable. I see two major issues in why that's a bad display.
> 
> 1) Escaping. While we want people to be able to specify every possible file
> (for example "Sullivan's % of profits.gnumeric" as a possible filename with a
> '%'). It seems obvious that we wish to allow at least some characters such as
> a
> space to be inputed without escaping. On the flip-side it seems like a bad
> idea
> to display "displayable" characters such as the space escaped in the location
> bar.

Definitely. Many users will have no idea that %20 means the space character,
and it would be evil to force them to learn that (unless absolutely
necessary).

> 
> One way to deal with this would be to check whether the filename is ambiguous
> -
> eg if the user inputs "blah%20blah.gif" and only one of "blah%20blah.gif" and
> "blah blah.gif" exists then we could contextually assume they were referring
> to
> the existant filename. We have to think about this though if the location bar
> can ever be used for specifying *new* filenames. Maybe at that point we just
> parse one particular direction, or pop up a dialogue box. It *might* also be
> safe to assume that something in the format %## is an escaped character, but
> I'm not sure.

It seems sensible to me to say that we always prefer an exact character
match between what the user typed and the file name, but if no exact
character match exists then we'll accept a match where the user-typed %xx's
have been converted to "normal" characters.

I don't think we should bother worrying about some potential future
name-file-from-location-bar feature. However, all of the same issues are
relevant for any other way that we name a file (either in-place, or in the
Properties dialog). I think the user's typed characters should always be
assumed to be exactly the characters in the file name, unless there's some
case where that's impossible (which I can't imagine right now).

> 2) The schema clutters things and is often/usually uncessary. For instance if
> I
> gave a *human* the string "/home/snickell/mydoc.abw" or
> "www.stanford.edu/~snickell/" one could contextually deduce that I was
> referring to "file:///home..." and "http://www...";, respectively. I notice
> that
> most people now "trust the computer" to figure out the schema these days,
> anyway (I'm masochistic and insist on typing the entire URI...but... :)
> 
> I have a general framework for an idea that in its strongest form seems to
> solve both problems, though it may introduce other problems and I'm not sure I
> like the strongest form.
> 
> http://null.stanford.edu/nautilus.png displays a basic mockup of one way the
> idea could look (or http://null.stanford.edu/nautilus2.png which was preferred
> by some but I think is bad for other reasons). Basically the idea is to create
> a "smart" location box that understands the parsing of URIs to some extent.
> The
> left-hand grey area is, of course, dynamically sized to fit the particular
> schema typed. The user may also choose to type only into the white area. If
> they do so then nautilus displays its current "guess" for a schema in the grey
> schema area (sorry my description isn't very clear). This also aids the
> readability problem inherent in displaying a full URI because it seperates the
> resource/path from the schema visually.

Andy and I have talked about this kind of thing before, though not exactly
as you describe. At minimum, we want Nautilus to assume or try to guess the
scheme if one isn't supplied (see bugzilla.eazel.com 434). But we've also
talked about having a fancier input/display widget that separated the scheme
from the rest of the uri. The specific design we talked about (but didn't
really work through) was to have essentially a small option menu of schemes
to the left of the text field. We didn't want to use the current option menu
appearance exactly, as it is too heavyweight in appearance. The menu would
list a set of schemes, and the user could choose from it explicitly if they
wanted. If the user didn't choose from it explicitly, the scheme would be
assumed to be the same as the one used in the current page (i.e., that's the
scheme that would be showing when the user started typing). If the user
typed a scheme, the typed scheme would replace the one in the menu
(literally, it would vanish from the text field part and appear in the menu,
perhaps after a brief delay so that typos in the scheme could be corrected
easily).

Your design seems very similar, the most notable difference being a second
text field instead of a menu. The two designs could be merged into one by
using a combo box instead of an option menu or text field for the scheme. I
think only experimentation is likely to reveal the nuances of the design
that make one of {menu/text field/combo box} be the best choice.

This design is not on our task list for the first release of Nautilus just
for time/priority reasons. But we definitely want to do something along
these lines sooner or later.

> Another addition that could be made (as displayed in my mockup) would be
> Nautilus would also display its current "guess" for the filename you are
> typing
> to the right of your cursor, also differentiated somehow (like with grey).
> Pressing tab would accept the currently displayed guess. This could either be
> a
> conservative guess like traditional Unix tab completion, or a more agressive
> guessed based on things like frequency of visit from the history file, etc.
> Dunno.

Andy implemented last week a feature along these lines. Currently it only
does anything for the "file://" schema. It does auto-completion based on the
set of existing files. We discussed some details that could be done
differently, so you should try it out and send feedback to Andy or to
nautilus-list.

John