[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-29 9:50:21
Message-ID: 201008291150.21888.colomar () autistici ! org
[Download RAW message or body]

> On Thursday 26 August 2010 20:52:03 Thomas Pfeiffer wrote:
> > > 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.
> 
> Both the gradient tool and the pattern too have a specialized tool option
> docker for their handling.
> 
True, but this would still separate selection of predefined gradients/patterns 
and editing of them. But for users, the whole thing is just "define what the 
background/border looks like", only in different degrees of detail.

> > > > 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.
> 
> How about a styles tool as working title.
> 
> > - 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.
> 
> I like the idea as it enables both types of working.
> 
> I thing it would be good to combine the two tools. There are some points
> which I think should be discussed before starting to work on the topic:
> 
> - Would the tool either work on a gradient or pattern depending on what is
> used on a shape?

Exactly. That's what I meant by the description above: If the user chooses a 
gradient, the gradient editing mode is activated, if she chooses a pattern, 
the pattern mode is activated.

> - What whould happen if there is a gradient forground and a pattern
> background would it be possible to edit both at the same time?

Not at the same time but depending on what is selected to be edited.

> - How would you handle the different tool options that are shown when the
> gradient tool/pattern tool is selected?
> 
I'd suggest to show/hide the corresponding docker when the "mode" is switched.

> > 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".
> 
> That is already implemented like that.
> 
Oh yes, I just saw. There is still some inconsistency in KOffice in general 
since Esc does not always return to selection mode. But here it does so that's 
fine.

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