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

[Luke Hutchison <lukeh email byu edu>]

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".

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?

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).

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

> It may simplify the looks of the UI, but I'm not sure about the usage...

If anyone else thinks this is a good idea, I would be interested to see
some tests (I'm not a usability engineer, so others would probably do a
better job running these tests).

> > and it seems to yield a design that is more in keeping with the 
> > spirit of the HIG, as well as making Open/Save dialogs more consistent
> > with Nautilus UI design.
> 
> 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.

 -- 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.)

 -- 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.

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
justification to break the blanket rule that says "modal dialogs can
never, under any circumstances, have a menu bar".  Is there conceptually
more to a modal dialog than it having modal state?  Is there more than
one type of modal dialog?

-Luke.