Re: [Usability] File Chooser Dialog

[Rodney Dawes <dobey free fr>]

Il ven, 2003-09-19 alle 20:26, Magnus Bergman ha scritto:
> On Fri, 19 Sep 2003 16:52:57 -0400
> Rodney Dawes <dobey free fr> wrote:
> 
> > Il ven, 2003-09-19 alle 14:59, Magnus Bergman ha scritto:
> > > What is considered to be extra crap?
> > 
> > Lots of things.
> > 
> > > Is a preview extra crap?
> > 
> > You obviously didn't look at the mockup I sent, or you'd see that it
> > takes care of the issue where people shove previews in odd places in
> > the dialog that drastically affect the dialog's size and/or layout.
> 
> I most certainly looked at it (I've read each and every post related to
> to the file chooser both here and at gtk-devel). Actually I liked it
> more than most (since we both seem to be part of the "less is more"
> school). The only thing I really didn't like was the placement of the
> file type drop down (my opinion is that it must be placed above the file
> list). There were also a few that was against my personal taste, but I
> have no (or at least quite few) argument for them being wrong.

Why *must* it be at the top? Other than being an opinion by several
apparently misinformed people, I've seen no evidence or facts to back
up any such claims. As you state it is your opinion/personal taste,
but I don't see how that is what any *users* want or need.

> There are two places that I don't consider odd: to right (for LTR
> locals) of the file selector and below it. But due to the layout,
> placing it to the right of the file selector is the only sane one.

I don't understand this statement. Both suggestions conflict with your
previous statement that it must be at the top. And putting on the right
of the file list makes absolutely no sense. It just makes the dialog
much uglier and much less usable. You'll have either a very large option
menu, or a normally sized option menu with a gigantic area of
whitespace. Neither are desirable and both don't go with what the HIG
says, afaict.

> I guess your point is that thumbnails makes previews unneeded. I read a
> post in another thread with that opinion, but I don't remember if it was
> from you. Personally I prefer to have a preview in some cases. But in
> most cases it's useless and should be hidden. But if I make few examples
> of situations there I find it useful and you can suggest alternatives
> that are at least as good, then you have convinced me.

That was one point, yes. I mean, what is the difference between a
thumbnail and a preview? They (are) should be one and the same. In
most cases you are going to get the mime type icon anyway. And no,
in most cases it is not useless. In the cases you are speaking of,
you probably don't have thumbnails for those files, or a way to create
them with current tools. That is not to say that they are useless.
How can you claim something that you have no method of using, is
useless? That makes no sense.

> > Things like metadata,
> > compression level, etc... are very much so.
> 
> Metadata, yes. It is a part of the document and should and should be set
> in the editor for the document. Compression level on the other hand is
> something I consider to be a part of the saving process rather than to
> the document. Is your opinion that it should be set in the document
> properties?

My opinion is that the user shouldn't care what the compression level
is. Disk space is cheap, and most people have enough. The program should
be choosing the most optimal level of compression for the file, without
needing user intervention. Also, most options are per-type, not
per-file, so they would probably be better as extra options in the mime
types system, which any program that supported those mime types, would
read the settings for from there, and save with those options.

> > File type is not, and if
> > you would have looked at the mockup, you'd see that it provides a
> > place to choose that. I think you are very confused as to what belongs
> > where, and didn't even look at the mockup. I sent fair warning about
> > such.
> 
> Then I looked at your mockup it wasn't clear to me that there was no way
> to add extra options. My opinion is that there should be possible for
> applications to add extra widgets. But only widgets related to *how* to
> open/save particular files. And these widgets must always be placed
> below the file name entry. See my proposal for more information.

It's not clear in anything that there is no way to add extra options.
Opinion or not, applications should not be adding extra widgets to
standard dialogs. If there is any real need for it, there is probably
a much better way of doing it, such is the file type options suggestion
that I provide above.

-- dobey