[Usability]Re: Nautilus toolbar simplification
- From: Michael Toomim <toomim ocf berkeley edu>
- To: Usability gnome org
- Cc: nautilus-list gnome org
- Subject: [Usability]Re: Nautilus toolbar simplification
- Date: Mon, 10 Mar 2003 22:32:25 -0800
Jens Knutson wrote:
On Mon, 2003-03-10 at 13:55, Michael Toomim wrote:
o As for "Stop" -- why would you ever want nautilus to freeze in the
middle of displaying a directory? Or any other type of file? I
think that this button is rarely useful.
I'm not sure this can go safely. What about remote file systems? SMB,
NFS, FTP, WebDAV - all of these could use a stop button about as much as
Even with remote file-systems -- why would you ever want nautilus to
freeze after drawing half a directory? I can't imagine any scenario
where I would want nautilus to stop-- and do nothing. If the user
hasn't clicked the back button (or given nautilus any other command to
execute) there generally can't be any harm done in drawing the rest of a
location.
In any case, I don't think that the stop button is used frequently
enough in day-to-day file-management tasks to warrant a toolbar button.
When you're browsing directories and files you generally don't want
to suddenly tell nautilus to "stop and do nothing". And the feature is
always available via the "escape" key and the menus if you do.
The user's home is available in many places, yes, but toolbar inclusion
is decided by how frequently a function is used by most users, according
to the HIG anyhow. While having it in those other places is nice, I'd
guess it's popular enough that it deserves a toolbar button, too.
I disagree here, too. Because the home folder is always within the
user's immediate reach (even if there aren't any other nautilus windows
open), I don't see the point of allocating toolbar space for it in each
opened nautilus window. It's true that toolbars should get
frequently-accessed features, but what's the point of using the toolbar
for a feature that's just as easily accessible from a slew of existing
locations?
o "Reload" shouldn't be needed if FAM et. al. is doing its job, right?
And if it IS needed, you have View->Reload and Ctrl-R.
See my argument about the stop button.
Even with remote filesystems, "reload" just isn't something that you
have to do often enough to warrant a toolbar button.
I'm not saying that reload, stop, and home aren't useful features under
some circumstances -- just that they're not used enough to be put on the
toolbar. I think that having a one-toolbar UI, with prominent placement
for the *really* frequently-used features (back/up, location, view type)
is a very important goal. If you include buttons for all of the
"can-be-used-in-some-situations" features, you can't achieve that goal.
So let's put the key, ubiquitous commands on the toolbar, and the rest
in the menus and on the keyboard.
In your mockup, you also ditch the spinner, which also must stay, for
slower machines, for huge directories, and again, remote filesystems.
Yeah, I was wondering if anyone would notice that. :) I've fixed the
mockup now at the same URL
(http://www.ocf.berkeley.edu/~toomim/redesigned_toolbar.png) and
improved the back button while I was at it.
BTW, one of the reasons that you have to rely on the throbber is that
there isn't any busy-interaction hourglass mouse cursor when nautilus is
active (see http://bugzilla.gnome.org/show_bug.cgi?id=108041).
That said, moving the zoom and "view as" controls up into the main
toolbar and ditching the location bar in the default view aren't too bad
an idea.
- jck
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]