On Wed, Jun 22, 2005 at 12:18:34AM +0200, Sven Neumann <[EMAIL PROTECTED]> 
wrote:
> all that bad compared to the former. Most of the complaints seem to
> come from people who got accustomed to the old dialog and haven't
> really tried to approach the new one yet w/o leaving the old habits
> behind. Of course that's an assumption but the discussions that
> evolved around these complaints seem to show that.

In the case of tab completion, you don't seriously want people to leave
the "old habits" behind?

That argument has a problem: old habits are not bad at all. Habits are bad
if they can be improved. But in this case, making tab completion slower
and/or more clumsy and difficult to use is not really a useful option.

Or, put in other words: just becasue it's new and difefrent doesn'T
automatically make it better.

> > Yes, this is subjective, but you need to accept that some people
> 
> Of course. That has never been questioned.

Well, many of the things you say certainly sound as if there would be only
one valid workflow, and whoever doesn't use it is mistaken (for a very
mild example see the "old habits" argument above. There is no logical
connection between "old habits" and "bad habits").

> But I am not concerned with that, at least not as much as with the
> usability of GIMP for new and infrequent users.

Well, if those features get in the way of more experienced people, I'd be
strictly against it. But we can easily disagree on this point...

> >> (3) Don't try to advertise the old GtkFileSelection dialog as being
> >>     the solution that we should revert too.
> >
> > I didn't. I did advertise the way the old file selection dialog used
> > it's text entry as the solution for me (and others with similar
> > complaints).
> 
> So far noone has made a proposal on how such an entry should be
> integrated with the current dialog.

Argh.

Lots of people have. If you look closely, many people just asked for a
text entry. Integrating that into the dialog would make tab completion the
old way very natural.

Given that there *are* proposals, a) why do you say no one proposed it and
b) what would the possible problems be?

I can easily understand that keyboard shortcuts get in the way, but right
now, typing creates a tetx entry, so entering characters is already reserved
for that. Is it a limitation inside gtk+?

It would be great if you could enlighten us why the proposals don't work.

> So I don't have much chance but to assume that what you have in mind is
> basically the behaviour of the old dialog.

The behaviour with regards to having an entry widget and how it
works. Yes, I guess you completely understood that then.

> Perhaps you aren't suggesting to revert to it code-wise,

Certainly not.
   
> but I haven't yet seen a detailed proposal on how an entry with Tab
> completion is supposed to work without bringing back the problems we
> had with the old dialog.

I am not aware of any problems with regards to tab completion in the old
dialog. Talking about that might be quite productive.

> I certainly wouldn't want to miss the current key-navigation
> behaviour. But perhaps you can offer a viable alternative?

What is the current key navigation behaviour? cursor keys? I don't really
need cursor keys when I do tab completion, and when I need them, I could
easily use my mouse to click.

> Such an alternative would have to be a concept for the whole
> dialog. Just adding an entry with Tab completion is going to ruin the
> whole thing.

Well, the simplest solution would be some (non-gimp) preferences to enable
a text entry for those people who prefer it.

(Remember that I don't ask for people to implement that. My primary
concern is that the existing problems and complaints are (or were) being
talked down).

> >>     It's main problem was that it was completely unusable for
> >>     newcomers.
> >
> > Probably. I admit am not concerned with that.
> 
> See. That is the main problem with your approach. You are only
> concerned with your needs.

That's obviously wrong. If I were the only one who'd like to have an
effective tab completion I would be very very silent. So no, I am not just
concerned with my needs, but with the needs of at least some more people.

> That is all valid but you should at least try to look at the bigger
> picture or else I don't see how we can get anywhere if we are discussing
> user interfaces.

Well, I am mostly concerned with my needs (and have said a lot of times
that you semed to have missed that I do understand that other needs need
to be satisfied, too) and you said you are mostly concerned with newbie
needs, so what's the big difference here?

Why is it bad when I say it but good when you say it? That makes no
sense...

> > Well, well... but the gtk+ people who designed the current dialog
> > vividly disagree with you on that. After all, the current dialog is
> > full of features that are not discoverable.
> 
> The question here is if the dialog works w/o discovering these
> features or if it leaves the average user frustrated. IMO the new
> dialog does a better job because it works somewhat better even before
> you discover that it can be used without the mouse.

That could well be. Now the question is wether a text entry with tab
completion would frustrate users. I don't think so, but if you think so,
speak on.

Or, put difefretly: in what ways would a tetx entry with completion
conflict with being able to use the file dialogs other features with the
mouse (and then: with the keyboard).

> > You should explain why you outright refuse to consider tab
> > completion (I interpret "not taken seriously" as an refusal to
> > seriously consider something), even though it's part of the current
> > design and despite the fact that people actualyl complain about
> > discoverability issues with the *new* file dialogs.
> 
> Your interpretation is nuts then. I have never said anything against
> Tab completion.

Well, you said more than once that I am not taken to be seriously if I want
tab completion, alway sin response to me saying that the old way of tab
completion was wrong.

Claiming my interpretation is "nuts" is IMHO completely unfounded. Do you
realize how insulting you are? No? Thoguth so...

> Actually I very much welcome the changes to the completion behaviour in
> the Save dialog that came with GTK+ 2.6.8. If you tried, you might have
> noticed that you can finally use the Tab key to expand to the common
> prefix of existing files.

Why do you imply I haven't? Sorry, but that's rather close to ad-hominem
again, by undermining my ability to judge.

Sorry, but I am well capable of installing gtk+-2.6.8 and trying it out,
even if you try to imply otherwise.

> That was one of the concerns that were taken from GIMP users to the
> people actually working on the file-chooser. It took a while but I think
> that it now works quite well.

Well, people other than me said it doesn't, so your subjective judgement
is far from general. I, too, think it does not at all work well, because
I have to wait for visual (and usually slow) feedback when entering
filenames.  Believe it or not, this makes it very awkward to use tab
completion, at leats for people who are accustomed to it and now their
paths well.

> > If discoverability of features is the goal of the new dialogs, they
> > clearly failed.
> 
> I agree that there are too many undiscoverable features, like Ctrl-L
> (which is probably just there to kill the trolls) and the more useful
> keybindings which are carefully hidden away.

That is an interesting comment. So you think the ctrl-l feature shouldn't
be there at all? I wouldn't call those people who asked for something like
that as "trolls"...

> >>     If you insist on being taken seriously with this approach,
> >>     please show me evidence to back up your claims.
> >
> > I, and others, did so.
> 
> Marc, I am sorry, but your own personal user experience is not
> evidence. Nor is mine or anyone else's. I admit that it isn't fair to
> ask for evidence here because you and me both don't have the resources
> to deliver facts about the usability of these dialogs. It would
> certainly be interesting, and probably helpful, to actually collect
> such data and compare different file dialogs in carefully designed
> tests with a variety of users.

If a number of users complain about usability issues, askign them to make
scientific studies before their complaints can be taken seriously is just
plain idiotic.

What counts is reality, and the current file dialogs, wether they worked
in studies or not, fail this for quite a number of people.

It doesn't matter wether the file dialogs work well for newbies if they
don't work well for everyday users.

You *are* ignoring the ample evidence people posted here.

> If you or someone else can come up with a detailed mockup of an
> alternative dialog 

I don't understand what the problem is there. Just include a text entry
*somewhere*. I'd guess somewhere at the bottom would be most useful, but
it's not as if we were talking about very complicated widget here. Nothing
else needs to be changed, so asking for a mockup is just making it
unneccssarily difficult.

If there are questions on ui logic (that cannot be solved by using
mockups), that should be discussed. The really annoying feature of the
completion right now is the popup of the location entry and the (slow)
popup of the completion entries. I am not sure wether a large delay would
be good, or wether not displaying it at all would be better. Right now,
it's simply too slow because it pops up and changes while you type.

> and if we could write a prototype that actually works, I am quite
> confident that we could persuade someone to do a usability test on it.

Much much more than I'd ever ask for.

-- 
                The choice of a
      -----==-     _GNU_
      ----==-- _       generation     Marc Lehmann
      ---==---(_)__  __ ____  __      [EMAIL PROTECTED]
      --==---/ / _ \/ // /\ \/ /      http://schmorp.de/
      -=====/_/_//_/\_,_/ /_/\_\      XX11-RIPE
_______________________________________________
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Reply via email to