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

List:       kde-usability
Subject:    Re: konqueror's kpart system usability
From:       Leo Savernik <l.savernik () aon ! at>
Date:       2006-08-02 18:05:06
Message-ID: 200608022005.06688.l.savernik () aon ! at
[Download RAW message or body]

Am Dienstag, 1. August 2006 19:18 schrieb Aaron J. Seigo:
> On Tuesday 01 August 2006 10:56, Leo Savernik wrote:
[...]
> > But how does the user in the current setup *not* know which kpart is
> > affected. As there is at most one kpart visible at a time (letting aside
> > the possibility to split views) it's clear that they affect this and only
> > this kpart.
>
> you give an example yourself: split views. besides that however it's not
> about "it is OR it is not" knowable, it is HOW knowable it is. please, try
> it out because it becomes really quite quickly obvious that having the
> controls closer to what they control increases the perceived affinity.

However, this means consequently to put *all* toolbars into the kpart's frame. 
Take, for example, split views: Only one kpart has the focus, hence all views 
have to have embedded all toolbar buttons including the history and the 
address bar (those actions only affect the focussed part). I don't think this 
is what you intended, but if you leave some actions in a remote place -- even 
though they affect only one part -- and attach some other actions to the 
part, this actually leads to inconsistency.
>
> > > Flickering?  Its not like there are buttons which are just added to the
> > > interface.. the entire interface gets rearranged.
> >
[...]
> interestingly, such flickering and moving layout has effects that are often
> subliminal in nature. people may not consciously note it, but given two
> systems, one that flickers and relayouts almost imperceptibly and one that
> doesn't, they will pick time again the one that doesn't. 

On the other hand, Internet Explorer (up to and including version 6) lays the 
precedent for mutating toolbars and menubars, and people aren't particularly 
flocking to applications that don't (Firefox), even though they easily could.

> a keynote example 
> of this is window tearing in window systems without a composition manager.

What are "tearing windows"???
>
[...]
> > The superficial problem is kpdf using the same icons for intra-page
> > navigation as konqueror for history navigation. This can (and hopefully
> > will) be fixed easily.
>
> the kpdf problem is one example. yes, we can go around and fix symptoms of
> things or we can ask ourselves "why do these problems arise in the first
> place?"

But spatially tearing asunder the toolbars isn't the answer to that question 
because that won't fix the problem that there are two different actions with 
the *same* icon. (And those actions stay different even if the toolbars are 
separated.)
>
> > > In the case of PDF documents it makes no sense.  Would the back button
> > > go to the previous page or the previous location stored in the history?
> >
> > The Real Fix(tm) for this special issue, disregarding contextual toolbars
> > whatsoever, is merging kpdfs intra-page navigation history with
> > konqueror's history. That way kpdfpart could save those buttons (and
> > simply provide them in the kpdf shell instead to be feature complete as a
> > stand alone app).
> >
> > However, the way kpdf's intra-page navigation is implemented it would
> > fill up the history with so many useless navigation points that it
> > virtually defeats konquerors history (i. e. for a many-pages-document
> > (thesis, whitepaper, etc.) you'd accumulate dozens of navigation points
> > which effectively keeps you from going back to the last document quickly.
> >
> > But this is a totally different usability issue probably worth to be
> > discussed separately. I digress again...
>
> this is not a digression at all IMHO. it's a very good analysis of why
> simply merging actions in this case is not what we want. and there are
> others, particularly when the meaning of the action changes slightly; with
> the kpdf nav buttons they still mean "back and forward" but this may not
> always be the case.
>
> moreover, it shows that to do these mergings right we'd have to then make
> applications/kparts aware of whether they are "stand alone" or "embedded".
> that really breaks the concept of "transparent component usage" and would
> have negative effects on usage and uptake of the concept as it would be
> harder to get right and would require more app developer effort

What you're mentioning here leads me directly to another use case I stumbled 
upon just yesterday: In kpdf (the shell) I naively tried to hide the sidebar 
by pressing F9. It didn't work. Technically it's obvious because the sidebar 
is part of the part (no pun intended :-) ), and having assigned F9 would 
clash with konqueror's sidebar shortcut (which is part of the container). But 
for the typical user, it's not. I remotely recall that it even used to be F9 
in kpdf and was changed exactly because of that issue.

For kde 3.5, a suggested fix would be to inject F9 as an alternate shortcut 
into kpdfpart's actioncollection from the kpdf-shell. But this is a hack. For 
kde 4, a "proper" solution is to be established. However, I don't know about 
a proper solution. I'm also not sure whether kde-usability is the right place 
to discuss issues like these.

mfg
	Leo
_______________________________________________
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]