Re: [Usability]Re: Nautilus toolbar simplification



On Tue, 2003-03-11 at 00:32, Michael Toomim wrote:
> 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.

The purpose of the stop button isn't to stop while drawing... it's to
stop while LOADING. Once reading a directory (either remote or local) is
complete, sure, go ahead and draw it. But if loading is taking a long
time, processor time, or bandwidth, there are many situations where
doing nothing would be advantageous.


> 
> 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
> > 
> 
> 
> _______________________________________________
> Usability mailing list
> Usability gnome org
> http://mail.gnome.org/mailman/listinfo/usability
-- 
Wesley Leggette <wleggette gate net>




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]