Re: [Usability] File Chooser Dialog

[Magnus Bergman <magnusbe algonet se>]

On Sat, 20 Sep 2003 11:29:10 -0400
Rodney Dawes <dobey free fr> wrote:

> Il sab, 2003-09-20 alle 10:15, Magnus Bergman ha scritto:
> > 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?
> 
> The "File Type" option list should be nominally un-used by the user.
> The prime directive of the dialog is to navigate and select a file in
> the list of files, not to filter what is in the list. The option menu
> is only a convenience and informational utility. The application
> should be setting the default filter to only those types of files that
> it can handle (in the open case), or to the default file type that it
> is going to be saving to.

I agree completely with all of that. I was only referring to open case
anyway.

> It is also more aesthetically pleasing and
> seems more correct/functional to have the file type and file name
> widgets grouped together as they are in pretty much every file
> open/save dialog on the planet. It seems like something that is
> (should?) be very minimally used as opposed to something that should
> be one of the primary focuses of the dialog. It should not be a
> 12-step program.

Alright, I see your point. In my opinion "ascetically pleasing" should
not be taken into consideration, but can't say you are wrong thinking
so.

But referring to "pretty much every file open/save dialog on the planet"
is not a reasonable argument to me. It falls in the category of "most
people are used to crap so let's give all people crap" arguments (that
is my opinion). But this is a different discussion. If you like discuss
the value of taking users previous habits in consideration, please start
a new thread or something. I don't have any real experience with any
other desktop environment than GEM, so I couldn't contribute much to
such a discussion.

> > 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).
> 
> The selection of a file should be the result of the data inclusive to
> it, not the other way 'round, as it is now.

That is true, and I agree that thumbnail is a solution to this. The
preview is more of a confirmation to that the selection is the correct
one. If it is not, the user has to go *back* to the selection. You might
think I'm stretching it now, but it seams crystal clear to me.

> I would say that *the*
> correct place to put it, is in the list view itself. :) Since
> correctness of layout is nominally a personal preference selection,
> it is arguable that anywhere the user wants it, is correct. However,
> that's not to say that it's optimal, functionally or aesthetically.

My personal opinion is that functionality should always go before
aesthetics. I'm quite interested in discussing the placement of widgets
for optimal functionality. This is something I find very important and
it goes way beyond the FOSD. But perhaps it's best if that's done in a
new thread or privately between us?

> > Yes, there is one major difference: the preview is bigger.
> 
> Nominally, no, it's not. The "preview" area for images is typically
> the same size as the thumbnail that would be created. Granted that the
> thumbnail that would be shown in the tree view, would be somewhat
> smaller, it's not going to be to a degree to be that big of an issue,
> as you present that it would be.

Are you saying that your thumbnails are in the same size as previews are
today? Or are you just saying that none of them are bigger, but one of
them is smaller? =)

> > 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.
> 
> No. There should be a plug-in style system for thumbnails which could
> be used by any application to create thumbnails, and it should only be
> useful for the file selector or file manager. Because the application
> that you are using to open a file with, can not handle another type of
> file, does not mean that the thumbnail and metadata for that other
> type of file, are useless.

Seeing thumbnails of images in the FOSD of a source code editor is
useless, yes. But it does no harm either I guess. Plug-ins are totally
OK with me, I guess applications just have to provide a plug-in for
their own file types then. Is such a system already present or is it in
development?

> > 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.
> 
> The thumbnail should not be the end-all method of selecting something.

Alright. What should be used then when thumbnails are not enough?

> I never stated that it should be. If you think that thumbnails of text
> docs are useless, then the thumbnail is probably being created in a
> manner that makes it so.

Yes, perhaps.

> Given the ability to see the document's
> layout, it's title, and similar metadata, you should have plenty of
> information on what to choose. Music files are a bad example. How the
> hell do you create a visual representation of audio data, such that
> the user would know what it would sound like?

I had no idea of your intention to also display meta-data (below the
filename I guess?). Sorry for my ignorance.

> You can't. Three
> dimensional models are another issue, but I think it's another problem
> that needs to be solved, separate from what is being solved here.
> Themes are another thing that come to mind, that are very very hard to
> create thumbnails of. This is one major issue with the current theme
> selector. As a preview of the GTK+ theme for the metatheme, it shows
> you a button. Not really the best way to do something, since the
> GtkButton widget is often the least changed of the widgets.
> 
> > 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.
> 
> No. I don't think they are quite useless in a considerable amount of
> cases. I think they are much more useful than you give them credit
> for. It's also very much a fact that you are not 90% of the users that
> will be using the dialog. Most people don't name their files well.
> Most people (at least, what I've seen of Windows/MacOS users) also use
> the file manager to *open* files, rather than the dialog. The
> thumbnails also don't take up a lot of valuable space.

I it wasn't there (the way it is now) maybe two or three times more
files could be displayed. This is what I meant. You have to scroll more.

> I hardly
> consider a small square/rectangle that is 48 pixels high, valuable
> space. Given the standard aspect ratio, that means most thumbnails for
> things that are going to cover the full size of the screen, are going
> to be 64x48 pixels. And this also gives us a taller row in the list,
> in which we can shove more/better metadata, rather than having a bunch
> of columns and causing the user to scroll left and right all the time
> so that they can see the data in the leftmost column, and then see
> that the file is 40K in size.

Yes, having to scroll in two dimensions is crap.

> > 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.)
> 
> I would argue that. The compression level option is mostly an
> antiquated way to be cpu-efficient on older, slower machines.

Not then it comes to destructive compression. What is the optimal choice
of compression for a jpeg-image then, no compression? Whatever level
you answer to this I think most people working with web design for
example will want something else in some occasions at least.

> > 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.
> 
> The only places where this is really an issue are in apps that aren't
> GNOME apps anyway, and already handle their needs in a sufficient
> manner.

Gnome apps already can set global options for mime types? I didn't know
that, I must again apologise for my ignorance.

> > 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.
> 
> Even if what you say is true for 90% of the users, it may not be true
> for the other 10%. The goal here is not to make everyone happy.

This seems to the the heart of our disagreement. In my opinion the goal
must be to make each and every person happy, at least the long term
goal. But decisions about who should be made happy needs to be made by
the maintainers only, I believe.

> That
> is an improbable thing to do. And there is no reason that most if not
> all, of these scientific "power-user" apps, could not be simplified to
> a large extent. Also, they are probably mostly going to be large,
> proprietary applications that use motif or similar, and not GNOME/GTK+
> applications anyway. So, in that respect, I care very little for them,
> as they aren't going to be using whatever orgy of mockups gets posted
> to this list in the first place.

An integrated development environment is such an application, a full
fledged word processor too and a MIDI sequencer. You are probably right
that most such application are going to be large and proprietary. But
that is no reason for them to use motif over GTK, since GTK is simply
better in every way I can think of.