Re: [Usability] File Chooser Dialog

[Magnus Bergman <magnusbe algonet se>]

On Fri, 19 Sep 2003 23:23:38 -0400
Rodney Dawes <dobey free fr> wrote:

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

I have reasons for that. I believe widgets should be placed to the same
order as the user needs to pay attention to them. A file type filter is
only useful *before* selecting the file, the other way around does not
make sense. And also, the result of a selection should appear after the
selection. I think this is important reasons to take in consideration.
Do you have better reasons to place it somewhere else?

> > 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'm sorry I didn't make myself clear enough. This was meant to apply to
the preview. The display of the preview is a direct result of the
selection of a file. So the preview must be placed directly after the
file selection widget. This is of course not an argument to include it
at all, but an argument that there is *one* correct place to put it (not
just a bunch of equally wrong ones).

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

Yes, there is one major difference: the preview is bigger.

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

I very much agree with you, that makes no sense at all. It could be
solved by letting the application create the thumbnails. That will
mostly solve the problem since you probably have no use for thumbnails
for files that the application in question can't handle anyway.

In most cases, at least then it comes to pictures, thumbnails are
superior the previews. But in a few cases the thumbnails are just to
small to be useful. In such cases the user has no better alternative
than to open the file in order to check if it was the right one. Such
cases could be text documents, music files and large wire frame models.

But don't you thinks even thumbnails are quite useless in a considerable
amount of cases? It does take up a lot valuable space (and forces the
user to scroll a lot more). I for one, use the FOSD mostly to open well
named text files.

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

Most users shouldn't need to care of things such as compression level.
But some do, and some might even have a very good reason for it.
(Otherwise you could as well argue that the choice of compression level
should also be removed from the library doing the compression.)

Having those settings globally associated with the mime type was an
interesting idea (but I'm not totally convinced that it is enough).
Anyway, this solution isn't available yet, and something else is needed
until it eventually is.

And even if what you are saying is completely true for the standard set
gnome desktop applications, it might not be true for advanced scientific
applications or similar. People who are actually using their computers
to get some work done are likely to use at least one such application.
Also should the needs of "power users" be kept in mind if you ask me.