Re: [Usability] [Yet Another] New File Chooser Design

[Sean Middleditch <elanthis awesomeplay com>]

On Wed, 2004-02-25 at 10:20, Luke Hutchison wrote:
> On Wed, 2004-02-25 at 02:48, Maurizio Colucci wrote:
> And maybe you could be interested in this: 
> > 
> > http://developer.kde.org/documentation/standards/kde/style/basics/badInterface.html
> 
> Thanks for that link -- it seems to state pretty unequivocally that
> adding a menu bar to a modal dialog is always the wrong thing to do. 
> While I understand what they're saying about separating use cases, I
> don't see strong enough reasoning there that "it will always be the
> wrong thing to do, even if you come up with a use case that makes adding
> a menu bar actually more intuitive and useful than not adding one", or
> that "there can never be exceptions to this rule".

Consistency.  It's confusing.  I've never, ever seen a dialog with a
menu bar.  If I see a window with a menu bar, I'm not going to think
it's a dialog.  Pop up a file selector with a menu bar, and it's going
to look like an odd file manager.  Which, of course, a file selector
isn't supposed to be (it selects files, not manages them).

> 
> So -- is it possible that usability guidelines can be violated, when
> actual user tests indicate that breaking some rule actually makes an
> application more usable and intuitive to the user?

Show us some tests, and then you'll have a real case.  ~,^

> 
> You could look at it two ways:
>  -- The File Chooser is modal.  It should never have a menu bar.
>  -- The File Chooser works with files.  It should work like Nautilus,
> and look like Nautilus, as much as possible, for consistency (but be
> modified to fit File Open / File Save use cases better)

No, it shouldn't, because the file selector isn't for managing files. 
You don't move, rename, delete, open (in other apps), or modify
meta-data of files in a file chooser.  You just pick a file/location. 
Nautilus has to work not only for finding files, but manipulating them. 
It is a far far more complicated beast which can't be "optimized" nearly
so well as a dialog designed for a single use case.

> .
> 
> We have right-click menus in modal dialogs when it is appropriate, why
> not a menu bar when it is appropriate?

Right-click menus are associated with objects in the UI.  Menu bars only
exist to provide an easy way to discover/find the context menus on
objects or keyboard shortcus for which no other widgets provide access
to.  Since all the file selector does is show and select files, and
offer the ability to add/remove bookmarks, there's not any good
reasoning to include a menu bar, since any context menus should do no
more than provide equivalents to 'select', 'add to bookmarks', and
'remove from bookmarks.'  Certainly, there's no reason to add a menu bar
that negates the problem of it being confusing and inconsistent.

> > 
> > I believe you should explain what do you think are the advantages of your 
> > redesign, what tasks it improves and how.
> 
> Basically:
> 
>  -- It simplifies the UI pretty dramatically, and hopefully simplifies
> the user experience.  You shouldn't really ever have to dig through the
> menus for anything if there are sensible defaults.

What is your actual reasoning for this?  Two or three clear and obvious
buttons are a *lot* simpler and cleaner than a menu bar, imo.  They are
all visible all the time, big and obvious.  Menus require digging.

> 
>  -- The UI is more consistent with Nautilus' UI where appropriate,
> without forcing Nautilus' use cases on File Chooser operation.  This
> gives the user less to learn.  (e.g. "Places" gives the same main places
> and the same bookmarks in the File Chooser and in Nautilus.)

This is fully possible using the bookmarks sidebar without using menus. 
And again a similar UI to Nautilus is pointless when they serve two
completely different purposes.

> 
>  -- The design is easily extensible.  With a honed (menu-less) UI
> design, when you decide to add one more critical feature or button that
> you didn't think about during the original design, where do you put it
> without upsetting everything in the current design?  With a menu-based
> system, just throw it in the appropriate menu.

Since the file selector only ever needs to do one thing, this shouldn't
be much of a problem.  If someone does decide to embed a file manager in
the file selector, they should be beaten with a wet noodle, repeatedly.

> 
> I understand that most modal dialogs should perform one action, and
> perform it well, and shouldn't need or have a menu bar.  But File
> Choosing is a different beast, with much greater levels of complexity
> and more involved use-case scenarios.  I suspect there may be some

How?  "Browse to location.  Select file."  If you make it more
complicated than that, then you have failed in your design.
-- 
Sean Middleditch <elanthis awesomeplay com>
AwesomePlay Productions, Inc.