Re: [Usability] File Chooser Dialog

[Rodney Dawes <dobey free fr>]

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

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

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

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

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

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

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

-- dobey