Re: [Usability] File Chooser Dialog

[Magnus Bergman <magnusbe algonet se>]

On Sat, 20 Sep 2003 16:47:50 -0400
Rodney Dawes <dobey free fr> wrote:

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

Yes, I understand your opinion.

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

Because you want your work done. I think theming is the right solution
to ugliness and that it should be added on top of the boring and ugly
but functional design. If you have a different opinion I respect that.

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

What I meant was that there is no use for the information it provide.
Unnecessary might be a better word then.

> 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 apologise a thousand times.

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

I'm sorry again. I didn't get that. Nothing to complain about then.

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

I find it useful to use jpeg for large pictures on web pages. Sometimes
the quality is not the matter, sometimes it's slightly more important.
Perhaps the optimal solution to this is to kick my teeth out. I wouldn't
like it, but again, there are different opinions.

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

As I see it we basically agree on most things. I haven't given up the
hope that you will also be happy. =)

We might have slightly different opinions about what "happy" means.
But thats far off topic.

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

To use an IDE in the first place you need to have a lot of knowledge
about that you are dealing with. That makes you an "advanced user" (of
that application at least). Having a bunch of advanced options in an
application only useful for advanced users is not bad. Advanced users
tend to care a lot about the details in their field of expertise. This
is generally speaking and not about really about IDEs in particular.

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

That was my whole point: we don't know. My idea is that the API should
be open to usages we don't yet know of. Within reasonable boundaries of
course. If I understood you right, this is against your philosophy. You
think only the needs of the applications we know exist today should be
taken into consideration, right?

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

I think I understand you now. I think future/possible applications
should also taken in consideration, not only the present ones. I call it
an "open design" while you might call it "solving problems that doesn't
exist".

Again, simple programs for normal or casual users should be simple, yes.
But programs for "advanced users" don't need to be. And I was thinking
more in the line of one or two options, probably some obscure ones that
only make sense in one single application (see my proposal for
examples).