[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-usability
Subject:    Re: Can we* prettyplease do something about the KUrlNavigator?
From:       Maciej Pilichowski <bluedzins () wp ! pl>
Date:       2009-06-23 11:23:31
Message-ID: 200906231323.32251.bluedzins () wp ! pl
[Download RAW message or body]

On Monday 22 June 2009 23:07:36 Matthew Woehlke wrote:

> > In GTK I click on a and then on e.
>
> ...but you have to wade through the folder list in the main pane to
> do so. I don't find that nearly as convenient as the KDE
> equivalent. I might as well just type it :-).

Could you explain this a bit? Because I don't see a difference in 
clicking in the menu list vs. clicking in the non-menu list. Both are 
lists. Menu is even worse actually because KDE cannot scroll it 
decently.

> > For me it is better, because I don't have "pause effect" with it
> > (where should I click?).
>
> Not sure what to say to that, other than your experience differs
> from mine. Which is more common? Do we know? (Honest question; I
> don't remember seeing any hard data on this thread. Did I miss it?
> Do we have any? If not, does someone here have the resources to get
> some?)

I think any psychology evaluation would say the similar thing about 
pause effect. Give a person loosely associations and it will require 
more time to "connect" them than when associations are direct.

After a training you could minimize that effect but you still cannot 
deal with ambiguity completely:
UI A: label is static element

UI B: label is static or active element, check it to figure out

A will get faster responses (at the mental level).

> > With edit box you cannot move up fast in easy way [...]
>
> If ctrl-arrows don't stop on /, 

:-)))) Matthew come on, you have to know about it. Besides, now we are 
discussing visual appearance and mouse navigation.

> YMMV

A lot of difficult acronyms flying around ;-) Your Mileage May Vary?

> (If you ask me, though, KDE is better here - a11y-wise - with
> ability to jump around folders w/o having to use the main pane.

Because of the menu? I differ in opinion, because menu in KDE are 
almost broken category.

> > with edit box you can edit path, but you can edit it incorrectly.
> > No such thing with breadcrumb.
>
> True, but you also can't type where you want to go ;-). 

Same with GTK. I was comparing breadcrumb (productivity, usability). 

> I dispute that generalization. I can assure you, I can get from
> /home/matthew/art/mypics/incoming to /usr/local/share/wallpaper
> faster by typing than I can by clicking. 

Me too. But is is hard to take as evidence of breadcrumb usability, 
because it almost looks like this "breadcrumb is great. Switch to 
lineedit and type..." :-)

> > b) explicit buttons (as we already said, it could be implemented
> > via flat buttons, which would be configured globally in KDE).
>
> Personally I love the current look. I vote for keeping that as the
> "flat" look. So long as I can keep that, I agree with making 'real
> buttons' possible.

Great :-)

> > c) no "smart" switching (by clicking in between, or in empty
> > space)
>
> I'd like to keep this, the empty space is a much bigger click
> target.

a) it is not for nothing -- the last part of the path because of it 
has less safety zone. 
b) it is wrong UI approach -- principle of the least surprise -- if 
you would like to have big area to switch, make the switch button 
big, no surprise there.

> What are your feelings about ctrl+click to switch to edit with
> pre-positioned caret?

Oh, sounds great! This would also solve the (c) issue with no penalty 
for you. You would get switcher on the left and on the right, big 
switch if your path is long, and no hidden elements.

Cheers,
_______________________________________________
kde-usability mailing list
kde-usability@kde.org
https://mail.kde.org/mailman/listinfo/kde-usability
[prev in list] [next in list] [prev in thread] [next in thread]