[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-07-31 20:41:47
Message-ID: 200607311441.48083.aseigo () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 31 July 2006 13:19, Leo Savernik wrote:
> Am Montag, 31. Juli 2006 01:29 schrieb Celeste Lyn Paul:
> > The suggestion mockup is exactly how the interface should work.   Why?   
> > Context, consistency, and predictability of the interface.   The document
> > controls are visually grouped together with the document, and there is a
> > visual separation from the application controls to the document controls.
> >   
>
> This is interesting that usability now strives to expose technical details
> to the user. I wouldn't have expected that.

this is not a technical detail. note Celeste talked about context and 
predictability.

imagine if all the light switches in your house were on the same wall. not 
only would this be inconvenient (you'd have to travel to this one wall no 
matter where the light you wanted to turn on was actually placed; and just 
imagine changing a light bulb!) it would also be slow and confusing. in fact, 
you'd probably have to label them all and often spend time scanning through 
them. even if they were clustered by room and ordered by "distance from the 
front door" or some such it would be much, much worse a solution that the 
traditional "put the switch near the door of the room for which the light 
illuminates" solution.

putting the toolbar for a document nearer the document is much the same sort 
of mechanism: it puts the controls nearest that which it works upon.

and that's not even getting into the "multiple back buttons" type of issues.

> > An additional perk is that the application interface doesnt change from
> > document to document like it currently does.   I noticed a few comments
> > back that someone said "As long as the user sticks to the default all
> > additional toolbars will be appended to the line of the main toolbar. No
> > shifting takes place that way.".   What distribution is that, because I'm
> > running a fairly virgin Kubuntu (Dapper) configuration and my Konq
> > interface shifts for every special file type.
>
> So instead of relying on a properly configured system that inhibits
> flickering the flickering should now be made immanent when switching parts?

er ... the flickering is due to redoing the layout of the toolbar on every tab 
switch. nothing to do with "properly configured". this is a fundamental 
limitation of the current system and is -very- visible on many systems 
depending on the hardware, widget style and kpart loaded.

the flickering would not be "made immanent" it would actually go away. 
exposing a widget is very fast compared to re-merging the xmlgui entries and 
recreating all the buttons and then painting them.

> So be it, there will be an 
> unmerged interface for KDE 4. However, I still consider it a bad idea to
> burden the user with making explicit the component-oriented behaviour of
> konqueror.

it's not about saying "hey, these are different components!" it's about 
grouping controls with what they control and creating a more stable appearing 
interface.

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