Re: [Nautilus-list] [long] Comments/reactions to PR2

["John Sullivan" <sullivan eazel com>]

Hi Adam,

Thanks for taking the time to write up your ideas so clearly. I like many of
your ideas, and think that Nautilus could be improved with them. However,
we're working hard to finish the first version of Nautilus, so we're not
likely to make substantial feature changes for the first release at this
point. The future, of course, is wide open. I've interspersed a few comments
below. 

on 11/9/00 6:28 PM, Adam Haile at adam haile duke edu wrote:

> I just got PR2 compiled and running on my RedHat 7 laptop, and have been
> keeping a log of thoughts and reactions.  Overall, I'm really
> impressed.  Many thanks to the Eazel team for their hard work!  I've
> been using Linux since 95.  You get so used to clumsy and ugly
> interfaces, that it's a real breath of fresh air to see one that's well
> designed.
> 
> I've arbitrarily divided my comments into "proposals" and "tweaks"
> depending on the scope of the suggestion.  Since I just joined the list,
> my apologies if some of these have been discussed or rejected in the
> past.  Of course, you can just completely ignore all this, if you so
> choose.  You asked for feedback, so here it is :).
> 
> Note: Some of these thoughts reflect the concerns of a laptop user:
> limited screen real estate, and a clumsy pointing device.  I'm probably
> a little more irked by wasted space than less pixelly challenged users.
> In my perfect world, Nautilus would work well in 1/4 of my 1024x768
> screen, since my usual work environment is a tall text editor in the
> right half of my screen, a file manager in the top left quarter, and a
> shell in the bottom left quarter.  GMC works moderately well for me
> right now at this size.
> 
> Here goes ...
> ---
> 
> Proposal: Replace the "Open with" buttons in the sidebar with
> application icons in an "Open with" frame
> 
> I think clicking a button to launch an application is counterintuitive
> for a user.  Generally, the metaphor is that you click an *icon* to
> launch an application, not a button.  Plus, I find the repeated "Open
> with" in the buttons to be visually cluttering.  What if we instead used
> an "Open with"  frame of application icons.  Here's a (bad) ASCII
> drawing of the proposed sidebar.  Imagine that the squares of #'s are
> icons, set your mail reader to a fixed-width font, and hallucinate just
> a little to see this:
> 
> ######
> ######
> ######        <-- Nautilus' current icon w/ description
> ######
> Foo.txt
> plain text, 4.9K
> 11/6/00
> 
> _Open with___    <-- the "Open with" frame
> | ####   #### |
> | ####   #### |   <-+ icons of application options
> | ####   #### |     |
> | gedit  pico |     |
> | ####   #### |     |
> | ####   #### |   <-'
> | ####   #### |
> | NEdit XEmacs|
> |_____[Other]_|   <-- button to select "Other" application
> 

I think using icons along with the application names here is a very good
idea. There are at least three issues that would have to be considered to
finalize the design:

(1) The icons would need to work on single-click, since selecting them
wouldn't be useful. But by default icons in Nautilus activate on
double-click, so this could lead to confusion. Maybe the icons & names need
to be made "button-like" with some sort of frame.

(2) Icons plus text might take more room than the current buttons. But
probably not much more, since they don't repeat "Open With...". So this
probably isn't much of an issue.

(3) There are a couple of places in Nautilus where we have buttons in the
sidebar that aren't just the "Open With" buttons. We'd need to make sure
those still fit in with this design.

> Proposal: Put the Find function in the sidebar, rather than the tool and
> location bars 
> 
> I was a little startled the first time I selected the Find button and
> saw the location bar grow into a Find interface.  Is the location bar
> really the right place for this function?  Instead of a Find button in
> the toolbar, I would prefer a Find tab in the sidebar; instead of the
> interface replacing the location bar, it would be the contents of the
> tab's panel.
> 
> Another bad ASCII drawing:
> 
> ______
> | Find \____________________
> |                           |
> | [ Name v ] [ Contains v ] |  <- criteria fields, split
> |     [foo______________]   |     across two lines
> | [ Type v ] [ is v]        |
> |     [ text file     v ]   |
> |                           |
> |                           |
> | [ More ] [ Less ]         |  <- More/less/find buttons, split
> |           [ Find Them ! ] |     into different lines to distinguish
> | _______ ______ _________  |     their functionality
> || Notes \ Tree \ History \_|
> 
> 
> In my mind, putting Find in the sidebar is conceptually cleaner for
> several reasons:
> 
> - The other buttons in the toolbar are *action* buttons:
> click them to do something.  Find, however, is a *modal*
> button: click it to display or hide the Find interface.
> This is exactly the function of the tabs in the sidebar:
> click them to display or hide an interface.
> 
> - The sidebar seems to me to be the right place for
> special-purpose interfaces, like Find, Help, and Tree,
> not the location bar.
> 
> - Find is more of a navigational *aid*, like Tree and Help,
> than a navigational *action*, like Back or Home.

I think I agree that the sidebar is more conceptually correct than the
location bar. However, it's very tough to squeeze the UI into the narrow
horizontal dimensions that the sidebar typically has. Your ASCII drawing
hints at the trouble, but doesn't show the full extent of it. In fact, I
think at one point early in this feature's evolution we worked on a design
using the sidebar but couldn't fit it in gracefully.

> 
> Proposal: Experiment with a combined location and tool bar
> 
> This is probably a bit controversial, but I'd like to put it out there
> for people to think about.  I'm quite taken by the way Mozilla's new
> Modern theme combines the location bar with the tool bar.  I'd like to
> see a combined location and tool bar available as an option in Nautilus,
> at least for intermediate and advanced users.  One of my general
> criticisms, not just with Nautilus but with a number of recent
> applications, is that the control interface has grown so extensive that
> there's barely any room left for the content area.  After you allocate
> space for the menu bar, the tool bar, the location bar, the status bar,
> and the sidebar, the actual contents of the directory are crowded into a
> small window.  Combining the location and tool bar would free up a
> substantial portion of screen space and works quite well, IMHO, for
> Mozilla.  
> 
> What makes a combined bar more difficult for Nautilus is the need to fit
> more stuff into the bar.  Nautilus needs 2 more buttons than Mozilla (up
> and home), plus the magnification widget and the "view as" dropdown.
> The text labels would probably have to be dropped, since they take up so
> much room. 
> 
> While ASCII does even worse on this drawing than the others, here's
> something to at least give you the idea.  I've provided descriptions
> below the bar:
> 
> < > ^ & X A | [/home/user/foo/bar/   ] ? | -[100]+ [Icons v]
> 
> ^             ^                        ^    ^      ^
> |             |                        |    |      |
> |             `- location              |    |      `- "View as" dropdown
> `- back, fwd, up, reload, stop, home   |    `- Magnification
> `- search button
> 
> Notice a couple things: I've taken the phrase "View as" out of the
> pulldown in order to save space (I'm assuming novice and intermediate
> users would understand without it).  Also, I've put the web search
> button after the location line.  This ties into one of the tweaks I've
> suggested below: letting users type web search keywords into the
> location field. 

My gut reaction here is that it's trying to squeeze stuff too small at the
expense of clarity.
 
> ---
> The remaining items are smaller in scope, so I've called them "tweaks".
> ---
> 
> Tweak: add drop-down lists to back, forward, and up arrows
> 
> I think this one has been suggested before.  I'd like to see these
> buttons have small arrows with drop-down lists attatched to them, like
> most current web browsers.  Personally, I prefer the behaviour of the
> old Netscape to the new Mozilla on this one.  In Netscape you clicked
> and held the button to display the list.  Mozilla now has very small and
> hard to hit down arrows that you have to click exactly to see the list.
> Note that this would basically make the current History tab obsolete.

We actually had drop-down lists on the back & forward buttons (accessible
via right-click, not quite as you describe it). These got lost when we
recently switched to the new Bonobo UI code, but will return before we ship.
We haven't tried one on the Up button, though it is certainly a reasonable
idea. You could help us out by entering bugs for tweaks and missing features
that you'd like to see into bugzilla.eazel.com.

Note that these lists are not the same as the History list. The History list
is a list of all locations visited by Nautilus, with the most
recently-visited one first. Each location appears at most one time in the
list. The Back list is different in that it is per-window, not per-Nautilus,
and it is one linear segment of the list of locations visited in this window
(hunks get dropped out when you use the Back button, as with all other web
browsers). But the list of locations in the Go menu is the same as the list
in the History sidebar panel, so you could argue that the History sidebar
panel is already obsolete.
 
> Tweak: let users type web search keywords into the location field
> 
> I'm not sure how this would play with novice users, but another of
> Mozilla's features that I've really come to appreciate is the ability to
> type search keywords into the location field and click a search button
> to the field's right.  If you have a slow net connection, it saves you
> the 10 seconds of waiting for the initial search page to load.
> 
> Tweak: lessen the nesting indent in the Tree panel
> 
> Right now, items in the tree view are nested pretty deeply from their
> parent.  As a result, you can't get more than three or four levels deep
> without having to scroll horizontally (ugh).  Given that you usually
> start two levels deep in your home directory, that's not very far at
> all.  The indent should be about half what it is now, which is still
> enough to make the heirarchy visually obvious.  I like the amount of
> indent that GMC uses, for example.

Seems reasonable. This would make a perfect bug candidate -- please enter it
in bugzilla.eazel.com!

> Tweak: text labels on toolbar icons should follow GNOME settings
> 
> In the User Interface/Applications panel of the GNOME control center,
> there is an option to globally turn on or off text labels in tool bars.
> Right now, Nautilus ignores this and always displays text labels (or at
> least I couldn't figure out how to turn them off).  I assume that, in
> the final version, Nautilus will follow the GNOME defaults.

The fact that it doesn't is a current bug in Bonobo. We'll make sure it gets
fixed before version 1.0.
 
> Tweak: if you're going to list files and directories in the Tree panel,
> at least list directories first
> 
> Personally, I'm on the side of those who prefer only directories in the
> Tree, but if you decide to include both, list the directories first.  I
> generally use the Tree to jump around the filesystem quickly.  Right
> now, I need to scroll vertically so much to get to the next directory I
> want that it's very slow.

There is now a preference for folders-only in the tree view (implemented in
the last few days).
 
> Tweak: make image thumbnails and file icons of equal size
> 
> On my system, image thumbnails are about 80% larger than the other icons
> when in the "view as icons" mode.  They're about the same when viewed as
> a list.  (I just noticed there's an old bug, #1017, that describes this
> issue.)

We've had various requests along these lines, though I don't think any of
them have made it into bugzilla (hint hint).

> Tweak: put less white space between icons, or make it adjustable
> 
> This is another of my small-screen concerns.  Right now, there's quite a
> bit of white space around icons.  Could this be either diminished or
> made adjustable?

There is currently a "Tighter Layout" choice in the "Lay out" submenu. If it
doesn't do a good job for you, please let us know (bugzilla, bugzilla,
bugzilla).

> Tweak: add a down arrow to lower the currently raised tab in the sidebar
> 
> When a tab at the bottom of the panel is clicked and raised, it would be
> nice if a small down arrow were displayed in the place the tab used to
> occupy.  This arrow would allow the user to raise and lower the tab by
> clicking in the same spot.  Right now, you need to click the tab on the
> bottom to raise it, move your pointer to the top, and then click the
> raised tab to lower it.  For laptop users like myself, with slow
> touch-pad pointing devices, the extra motion can be bothersome.

bugzilla.eazel.com bug 3538 is about this issue. If you feel like you can
add clarity to that bug report, please do so.

> Tweak: add an arrow to expand or contract the sidebar
> 
> It would be nice if there were a small arrow either on or near the
> sidebar divider which, when clicked, would close or open it back up.
> Right now, you have to grab the grip on the divider and drag it back and
> forth.  Mozilla's "Modern" theme has one example of how it could be
> done.

Clicking on the divider toggles the open/closed state. Also, there's a
Show/Hide Sidebar item in the View menu that removes all traces of the
sidebar (or reinstates it). If neither of these work well for your
situation, please write a bug report explaining why not, and proposing an
improvement.

Again, thanks for the great comments. I strongly encourage you to use
bugzilla.eazel.com to enter many of these thoughts into our work-to-do
system.

John