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

List:       koffice-devel
Subject:    Re: Usability Topics
From:       Thorsten Zachmann <t.zachmann () zagge ! de>
Date:       2010-08-26 14:45:04
Message-ID: 201008261645.04506.t.zachmann () zagge ! de
[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. 

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

> Consistency is a very important aspect of usability, but "suitability of
> task" is even more important.
> So if users are far more likely to find the widget they are looking for in
> a place where it doesn't belong according to consistency than in a
> consistent one, it is worth the sacrifice in consistency.
> 
> So unless we find a more elegant way to allow users to easily switch
> between setting background colors, gradients or patterns than having them
> all in a tool, I clearly prefer that over the current situation.

The docker very easily lets you set a color, pattern or a gradient without the 
need of a tool. I have had a look at some apps and for most it is possible to 
modify the color/gradient as it is in the styles docker. So that is something 
people are used to do so.
One thing which cam into my mind would to have a docker from which you could 
select the tools to manipulate the gradients/dockers. 

Also I think we should also talk to artists about that as the styles docker is 
a tool they quite often use.

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