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

List:       kde-usability
Subject:    Re: konqueror's kpart system usability
From:       Celeste Lyn Paul <celeste () kde ! org>
Date:       2006-07-31 20:51:12
Message-ID: 200607311651.21963.celeste () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 31 July 2006 15:19, Leo Savernik wrote:
> This is interesting that usability now strives to expose technical details
> to the user. I wouldn't have expected that.

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.

The current behavior *does* expose the technical details because it can't be 
implemented the way it is being suggested without KParts.  It is impossible 
to provide contextual controls in the document, it has to be facilitated by 
the browser's interface.

>
> > A better example is if you look at the previously linked images of the
> > IE7 screen and the Konq mockup at linuxdevel.net.  Application controls
> > are separated from the document controls.
> >
> > 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?

Flickering?  Its not like there are buttons which are just added to the 
interface.. the entire interface gets rearranged.  This movement is 
unacceptable, no static controls or major parts of the interface 
should "move" just because it is a different type than the previous.  Adding 
additional contextual controls is not flickering, the content gets painted  
at the same time as the controls.

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

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?

If this is a technical issue then perhaps Konqueror shouldn't have the 
capability of handling multiple file types with contextual controls because 
its too confusing for the user and causes errors.  Of course I'm being 
facetious here, but I'm trying to explain the issues.

\C

-- 
Celeste Lyn Paul
KDE Usability Project
usability.kde.org

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