Konqueror 4

[Aaron J. Seigo]

On Monday 30 October 2006 17:05, Allan Sandfeld Jensen wrote:
> On Tuesday 31 October 2006 00:28, Aaron J. Seigo wrote:
> > this is not true in all use cases. it's only guarantee-ably true when:
> >
> >  - the user is descending (upwards and sideways navigation is often
> > slower) - the user knows where they are going
>
> No, descending is faster by typing, 

if the user knows where they are going, yes. isn't that what i said?

> sideways navigation is faster. 

going from /home/aseigo/pix/venezuela to /home/aseigo/music:

editable:
	click mouse in edit area or press F6+end
	press delete key or highlight pix/venezuela with keyboard or mouse
	type "music"

breadcrumb:
	click aseigo, hold momentarily
	select music
		or
	click aseigo button
	move mouse into view
	click music folder

and that's assuming the user has perfect knowledge of their system. this does 
not measure user confidence and awareness in any way.

> > "throwing it away we are not!" says yoda. "letting the user switch
> > between breadcrumb and editable are we, as well do we let them choose
> > their default. the force may be strong with you so you use an editable
> > bar, mmmh? but most weak are with the force. trees and URIs ergonomic
> > they are not. them we give the breadcrumb."
>
> That's a problem, not a solution. As you state above there are different
> cases where one is usefull. This makes it a poor replacement, and makes no
> improvements to the current users skilled in the current interface.

if you don't like it: don't use it. simple. flip to the editable text edit and 
be happy. but let others have something that works for them, too.

that said, you assume that most of our users are skilled in the current 
interface. similar to this statement:

> Sorry if I am reactionary, but I value real users higher than potential
> users.

the implicit assumption in this statement is that current kde users are served 
well by the editable bar. it is true that you and i may be skilled with it; 
other power users may be skilled with it; but you may have (or not?) noticed 
that most of our users today are not like you and i. we became the minority 
by a long shot some years ago. we need to continue serving us and those like 
us well because we're exceedingly valuable and important to the project, and 
as loyal users deserve nothing less. this needs to be balanced with the needs 
of our general user base. 

having been using this widget now for the last several days it strikes quite a 
nice balance here; not to mention i haven't missed the editable-only 
alternative one bit because, as a power users, i've discovered the keyboard 
shortcut (there's also a button you can click if you'd like) that, much like 
F6 does today, gives me an editable bar with keyboard focus. and unlike in 
GNOME's file dialog these modes of usage are well revealed in the interface.

now, how about support for the statement opposite to the one you note: that 
current kde users are not served well by the editable bar? evidence relating 
to the poor performance of raw URIs (leading to media:/, system:/ and others 
which caused other problems), evidence of breadcrumbs actually working very 
well for a broad class of users ... seems there's a good set of arguments 
here. not to mention dolphin's user base, which is rather larger than i 
expected to be honest.

of course we -could- find out by trying this that the breadcrumb completely 
sucks ass for most people. in which case we just switch to the editable thing 
by default. but we'll only know by trying. dare to try and we'll all learn a 
hell of a lot more than we do when we jerk our knees about and refuse to 
imagine and create new things where problems have arisen.

> > > we should have
> > > locationbar with active parts so you can click on any part of the path,
> > > and drag to any parts of it.
> >
> > then you end up dealing with appropriate click-drag distances for
> > editing. there lie dragons. and for the minor difference this presents
> > from a dual mode bar i don't see the point, though i do see the pitfalls.
>
> Yes pitfalls that's UI design, but as long as you cannot drag the path onto
> itself you should be pretty safe. So you can drag away from the path, or
> you can drag onto it.

i meant that if you want an editable bar with clickable bits you need to 
differentiate between click-and-drag-because-i-wish-to-highlight-and-edit and 
click-to-go-to-this-element. and yes, this does mean no dragging of path 
elements (though that's probably not much of a loss).

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20061030/c6a764e1/attachment.sig>