Re: [Usability] File Chooser Dialog

[Rodney Dawes <dobey free fr>]

Il sab, 2003-09-20 alle 14:56, Magnus Bergman ha scritto:
> 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.

It's not an argument that most people are used to crap. If we wanted to
give them crap, because they were used to crap, we could not change
anything, and let them continue using the current GTK+/Win3.1 file
selector that we have. There is nothing to discuss. Current habitual
practices must be taken into consideration. Why should I switch to this
new platform, when everything I already know how to use, and have spent
years learning how to use, is gone? Why should I switch to a new
platform, where I have to relearn everything over again? Migration
should be one of the foremost considerations when designing a UI.

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

Why should I use something that I don't like looking at?

> 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'm saying that the size difference between the size of the thumbnails
in the list, in my mockup, and the size of a thumbnail preview that is
stuff in the file selector by something like GIMP, is miniscule and does
not affect the amount of detail shown in the thumbnail by any amount
that matters to most people.

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

It is not useless. You keep saying useless when you probably mean more
of something like non-optimal. And if it's not optimal, the application
needs to be fixed, not the dialog.

There is a plug-in system for doing thumbnails with Nautilus, I believe.
I think it may even just be a bonobo interface. I'd have to look at the
different thumbnailers for it to be sure. However, Nautilus is not the
best place for something like this to be.

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

Uhm. Did you *read* what I typed. Because, I clearly stated this, and
you respond below.

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

Again. Did you *look* at the mockup? 

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

No. You just display less files so you either end up scrolling less, or
not at all. There is a lot of fine-tuning you can do there. You can also
have "large" icons or "normal" icons and make the "normal" be 24 pixels
high or something, while "large" is 48 pixels high.

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

I said optimal, I didn't say most speed-efficient. And if you are using
jpeg, and care at all about quality, you probably need a good kick in
the teeth. These days, most everyone uses png/swf/gif for all their
imaging needs.

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

GNOME has a mime system, and an API for using it, yes. Not everything
will use whatever key/data pairs you set for the mime type, but it's
certainly doable. Not that I was saying that GNOME already supports what
I was suggesting, because it doesn't.

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

Well, you get the $80 billion dollars, and I'll go get a ChemE/Biotech
degree, and we'll make everyone happy.

Seriously though. You can't sit around trying to make everyone happy,
because it's not going to happen. As a proof in point, this e-mail
"discussion" is still going on. The decisions about who needs to be
made happy, have already been made. And those are home/corporate
workstation users.

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

An IDE is such an application that needs what? I don't understand what
you mean there. It sounds like you are complaining about something that
should be done at project creation, rather than when you "save" a
project. There is probably going to be a "wizard" to create a new
project, in any good IDE, and it will ask you things about your project,
such as, what to name it, where to put it, and what language it's in,
etc... Saving individual source files or other such trivial things will
probably be done individually and separate from the overall project's
need to be saved.

I don't know much about MIDI sequencer applications to state any valid
arguments against whatever you are trying to say here. However, if it's
open source and using GTK+, it can probably be heavily simplified.

As for the large proprietary application argument, you didn't get it at
all. I was talking about currently existing applications, not what
someone might write 10 years from now. And 10 years from now, whatever
we do now is going to be obsolete, so there is no point trying to argue
for supporting it. And any new applications using GTK+/GNOME can be made
simple enough that they don't need a billion options for saving special
files, in the save as dialog.

-- dobey