RE: Weighing in and other thoughts about recent discussions

["Gerry Chu" <gerrychu bigfoot com>]

> > > > BRRZT! :)  Wrong.  Seeing the list of existing files is useful if I
> > > > need to know the name of a file which I'm replacing, or one I'm
> > > > making a new version of.  (Did I call it "big_spaceship.png" or was
> > > > it "spaceship_big.png"?  I need to know to make sure that I call my
> > > > small spaceship image in a consistent way.)
> >
> > Well, I'm not saying the only way around the problem is removing it, you
> > could make it smaller or put it one level down, just like...
>
> Users often choose "Save as" when their intention was to "Save".
> Giving them the file is essential.
>
> With the load-save model that most operating system use, users often
> choose "save as" to OVERWRITE existing files.
> To do that, you must be able to select files from a list.

That's absolutely right.  "Save as" should have a file picker in the main
dialog, because it does imply a choice of which file to save to.  Glad you
brought that up.

> There is a point with seeing the contents of a directory when saving
> even if you not overwriting. A user must know if the directory
> she is saving
> in is the correct one. A user might not know much about the
> directory other than
> that it contains certain files, they may remember that it
> contains so many files
> of predominantly some type which has icons in some colors that
> are laid out
> in some manner. This image could help a lot.
> I am not writing about making the "open" and "save" dialogs
> identical - because
> that would hide information from the user. I mean the opposite.
> I am writing about the "knowledge in the world"-rule which you learn the
> first week of studying user interface design.

First:

Well, I'm not saying the only way around the problem is removing it, you
could make it smaller or put it one level down.

Like having a button that takes you the full file listing.  File dialogs are
useful, but it just shouldn't be presented like the user has to choose
between the files.  That's my point. I think you'll agree.

> > On a separate note, I think we should make a general rule not to discuss
> > implementation...this is a GUI list, after all.  Leave the code
> to the great
> > GNOME/Eazel programmers.
>
> <rant>
> Like they would even care about this list!
> I once commented on the nautilus list about how I though that they should
> discuss Nautilus-interface issues in this list because I think that the
> design of Nautilus' interface is something that is important for the
> whole GNOME UI community. I got an obnoxious reply.

Besides Mr. Arlo's infrequent participation of this list (not to offend him,
as he as other things to do also) I agree, at this point.  And I think it is
a pity that you got such a reply since discussing UI issues with users is
obviously important to the success of product.  The GNOME UI Improvment
project http://developer.gnome.org/gnome-ui/hitsquad/ is supposed to write
the glade projects based on feedback from this list that are supposed to be
used in future versions of GNOME, but I haven't seen much from it go into
the releases yet.

> The GNOME UI community created a design for a new file manager
> for GNOME 2.0
> and discussed this design endlessly, and still are discussing such issues.
> Is there anything in the GMF design that is in Nautilus?

No.  There isn't.  I've thought of that before, with grief.  The ironic
thing is, they came up with a better design IMO.

> People complain "Show me the code". That is what we should do if we want
> to have any influence over the design issues of GNOME in the future.
> We should have to write the code.

Write the code.  I know what you mean.  That is what open source is all
about, after all: have a problem? want a feature?  know how to code?  Write
it yourself!  I was just saying that discussing underneath implementation
(such as the code) _on this list_ is a bit counterproductive, given you can
find  a denser group of people with better programming skills some other
places.  This is a _UI_ list.

> The design of interfaces is not a light issue. It is definitely not an
> "artsy" thing.
> Good user interface design is art and science in perfect harmony.
> Good programming is also art and science together, and the best designs
> will be those that take both programming and users into account
> from the start.

I agree.  I have been worried recently on the absence of teachers teaching
UI principles in high school programming classes.  Programs high school
programmers create are hard to use beyond belief.  It's scary when you
wonder what those kids are going to grow up to do.

Cheers!

Gerry Chu
gerrychu@bigfoot.com