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

List:       kde-usability
Subject:    Re: konqueror's kpart system usability
From:       "Aaron J. Seigo" <aseigo () kde ! org>
Date:       2006-08-01 17:18:23
Message-ID: 200608011118.24501.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Tuesday 01 August 2006 10:56, Leo Savernik wrote:
> Am Montag, 31. Juli 2006 22:51 schrieb Celeste Lyn Paul:
> > I'm not sure what you mean by exposing technical details, all that is
> > being suggested is so the controls are organized in a way the user knows
> > what they control.  If anything, it is abstracting the technology.
>
> 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.

> > Flickering?  Its not like there are buttons which are just added to the
> > interface.. the entire interface gets rearranged.
>
> Well, that's not a usability bug but a *real* bug or configuration problem.
> If properly configured, the part's toolbar is seamlessly merged into the
> existing space without causing relayouts. That's the way it works for me.

a) it's not how it works for everyone (meaning the system is fragile)
b) the relayouting is quite visible on many machines i've seen kde on.
c) having new items appear and disappear is something we say "don't do" 
everywhere -except- toolbars. our user interface guidelines have always said 
that dynamically changing interfaces are a bad thing to do and that's because 
they have an impact on learnability and perceived stability (-> trust -> 
happiness with system)

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. a keynote example of 
this is window tearing in window systems without a composition manager.

> > Perhaps you misunderstand the nature of the design, if so ask some
> > questions about its usage and behavior.  The problem is current layout
> > and implementation of context-sensitive tools a) are ambiguous and cause
> > confusion (eg: KPDF controls).
>
> 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?"

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

-- 
Aaron J. Seigo
Undulate Your Wantonness
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com)

[Attachment #5 (application/pgp-signature)]

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