Re: File dialog (was: Re: First UI component needing replacement.)

[Dylan Griffiths <Dylan_G bigfoot com>]

Christian Rose wrote:
> I think that there have already been some good suggestions by the UI hit
> squad for a new file dialog:
> http://developer.gnome.org/gnome-ui/hitsquad/filedialog.html
> 
> Have a look at that. I think it's very similar to your idea... :)
> I think the "recent directories" is a great idea, and I think that's
> exactly what the "Directory" drop down box in the Hit Squad example is
> intended to do.

No.  That dialog is an abomination.  Before you get angry, read why:

The dialog is incredibly cluttered!  I see 12 buttons along the top alone. 
How is this supposed to make the task of the file dialog, browsing to a
specific file OR choosing a directory to save in, easier?  What do those
funny arrows mean?  I think they're mixing the browser/filemanager
metaphor.  Any button which requires a tooltip is fundamentally
misdesigned.  If I wanted that much control over my file system, I'd load a
file manager -- not a common file dialog.

None of those buttons have any obvious keyboard accelerators.  That is
wrong.  Maybe they (the dialog designers) are Mac-OS people who love to
mouse, but I'm not, and most other people aren't either.

The filename listview is the same size as the directory tree.  This is
wrong!  File names are larger than directory names most of the time.  A
properly descriptive filename is about 30 characters.  That will get cut off
on that dialog.  There is no obvious way to resize the listview to show more
of the filenames, either.  (Not to mention the rest of the dialog).

If you are doing to make a dialog designed to assist the user in quickly
find a directory, it must be explanitory for the beingining users, and
provide advanced userd with shortcuts to make it go faster.  My dialog has
that, the other dialog does not.

I'll also point out that "Directory:" is not as good as "Recent directories"
for users to be able to read and get useful meaning from.

(Yes, I've defended my dialog against the other dialog before..)


> > I've also tweaked the buttons.  I replaced the "cancel" button with the
> > "close" button, since "cancel" will not rollback any operations performed in
> > the dialog on any systems I have ever seen.
> 
> No no no, it should be "Cancel". It is and has always been "Cancel" in
> all file dialogs I have ever seen.

"You should always say right when turning left in those kinds of cars
because we've always done that."

I prefer to REMOVE the un-intuitiveness.  Sure, it's fine for those that
have learned the wrong behaviour, but to new users you are confusing them
because you are LIEING about the ability to cancel changes made.  PLUS the
extra code to support the cancelling of renaming and making directories
would only bloat the dialog.
 
> > Added are a rename and new
> > directory button.  This allows the user to rename old files when saving new
> > ones, as well as creating new directories to store new files in quickly.
> > This simple addition can a lot of time for the user.  The buttons included
> > underlined letters to indicate the keyboard accelerator to use (meta + the
> > underlined letter) to active them without tabbing to them/using a mouse.
> 
> Oh, good point. I don't see a "new folder" button in the UI hit squad
> example. It should definately be there. In fact, that was what I thought
> the button with the folder icon did, before I read the text above the
> picture.

Now you know why I think their design is wrong.  Having that many buttons
confuses even experienced users, and they provide no keyboard acceleration. 
That is Bad Design.
 
> The folder button appearantly opens the current folder in the file
> manager.

!!!

> I think that's wrong. The folder button should create a new folder. If
> there should be a button for opening the current folder in the file
> manager, it should be marked with the file manager's icon (does Nautilus
> have an icon yet?).

No, it should say "Load Filemanager" or something else.  Generic icons not
in any language mean precisely nothing to everybody.  They *will* be
misinterpreted, forcing the user to learn to work around a broken behaviour.
 
> > Besides just layout, there is a behaviour problem with some common file
> > dialogs that we need to stamp out.  The Motif dialog that Netscape 4.x ships
> > with is a great example of a badly behaved dialog.
> 
> Don't start it. The Netscape 4.x file dialog on Unix is the worst piece
> of s***t in the UI design history. It's unintuitative as hell,
> counter-productive and also very buggy. :-(

Much like this UI hitsquad dialog is for the reasons outlined above.

-- 
    www.kuro5hin.org -- technology and culture, from the trenches.