[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-25 19:02:58
Message-ID: 201008252102.58604.colomar () autistici ! org
[Download RAW message or body]

> 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

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.

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.


> Now, the confusion between tool option widgets and inspector widgets is the
> source of the usability problem. What we need first, before moving even
> more functionality to tools is to define a good taxonomy of all the
> dockers we have. Then determine what each type of docker is used for, and
> then figure out ways to present that in the clearest way possible to the
> user.
> 
Yes, definitely. That's why I put that on my list of suggested topics.

> And then we need to figure out a way to curb the excesses of the tool
> system, like having to select the text tool before being able to click on
> a url.

I agree that we have to ask the question "Does it do something directly on the 
canvas?" for all tools.
_______________________________________________
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]