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

List:       koffice-devel
Subject:    Re: Usability Topics
From:       Thomas Pfeiffer <colomar () autistici ! org>
Date:       2010-08-26 18:52:03
Message-ID: 201008262052.03576.colomar () autistici ! org
[Download RAW message or body]

> On Wednesday 25 August 2010 21:02:58 Thomas Pfeiffer wrote:
> > > On Monday 23 August 2010, Thomas Zander wrote:
> > > > On Monday 23. August 2010 20.32.30 Thorsten Zachmann wrote:
> > > > > I would like to avoid to need an extra click for activating a tool
> > > > > just for  changing the color of a shape. It is something I do quite
> > > > > often and I think also artists do quite often so having first to
> > > > > activate a tool should be avoided in my opinion.
> > > > 
> > > > This misses the basic premise the tool system was designed for.  Its
> > > > workflow based and by grouping the features in the tool we avoid
> > > > clicking, not add extra ones.
> > > 
> > > Actually, having next to tools, inspector widgets that can modify the
> > > properties of the currently selected shape(s) has been part of the
> > > flake design since the beginning. The original group of flake
> > > designers (me, Thorsten, Casper, Rob, Peter) never intended to have
> > > everything go through tools. These inspector widgets have quite an
> > > ancient pedigree, having appeared in NextStep and are still being
> > > heavily used in Apple's office suite.
> > > 
> > > Tools were never intended to be merely the way to conveniently open an
> > > inspector widget, they are for on-canvas manipulation.
> > 
> > The problem in this specific case is: You are both right. As already
> > stated earlier in this discussion, I generally fully agree with
> > Boudewijn that tools should be reserved to on-canvas manipulation (which
> > I - less precisely - referred to as "Doing something with your mouse").
> > The problem here is:
> > 1. Changing background/border color, gradient and pattern are clearly
> > related
> > 2. Changing color is done completely in the docker
> > 3. Changing/manipulating gradient and pattern is done both in a docker
> > and on- canvas
> 
> That is not really the case. The tool is used to manipulate a
> gradient/pattern. The docker is used to selected a predefined
> patterns/gradient/color. So It you just want to select a different
> predefined gradient this is something which can be done in the docker.
> 
This is why I originally favored the docker. But we should not separate 
choosing and manipulating a gradient/pattern.

> > The original decision to have tools for gradient and pattern but not for
> > color (as is the case now) actually precisely follows the mantra "Only
> > use tools for on-canvas manipulation"). However for the user, the
> > relation between color, gradient and pattern is obviously more prominent
> > than the distinction between doing and not doing on-canvas manipulation
> > and thus users are looking for a way to change colors in the same place
> > as they found tools to change gradient and background.
> 
> From my experience most people find first the docker to change the gradient
> or a color. It mostly takes them some time to find out how to manipulate a
> gradient or a pattern.
> 
So, new suggestion:
- If the user clicks the Whatever-Tool (we should at least find a working 
title soon), the "styles" docker is automatically displayed.
- The docker can also be displayed manually.
- We can decide application by application if we display the docker by default 
or not, depending on how often it is used in that application.
- When the user clicks "gradient" or "pattern" in the docker, the tool is 
automatically activated and the user can modify the gradient or pattern. When 
the user hits "Esc", selection mode is activated.

Would that be technically possible?
This would allow users to choose their preferred method. I normally would not 
recommend this as it doesn't help the separation of tools and dockers, but in 
this case since both typical docker actions (selecting a 
color/gradient/pattern and typical tool actions (manipulating the 
gradient/pattern) are involved, we might have to accept a compromise.

The only critical point usability-wise I see here is the third one, but I 
suppose changing the tool back to selection on Escape should ease it. This, by 
the way, is something I strongly recommend as general behavior: Hitting Escape 
should generally change back to the selection tool (or whatever the default 
tool for an application is) so that users who accidentally find themselves in 
the wrong "mode" can easily return to a "save haven".

> 
> Thorsten
> _______________________________________________
> koffice-devel mailing list
> koffice-devel@kde.org
> https://mail.kde.org/mailman/listinfo/koffice-devel
_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel
[prev in list] [next in list] [prev in thread] [next in thread]