[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-22 13:28:02
Message-ID: 201008221528.03377.colomar () autistici ! org
[Download RAW message or body]

> On Sunday 22 August 2010 14:08:00 Thomas Pfeiffer wrote:
> > > > First of all, we need to identify the topics/issues we will work on.
> > > > If there  are some which you have already identified but not found a
> > > > solution for yet, please tell me about them and who will be the
> > > > ideal people to discuss them with.
> > > 
> > > One thing that has been bugging me (and from questions on IRC / mail
> > > and real life, not just me) is the topic of how to set a shape
> > > background. There currently is a tool to set a gradient and something
> > > else to set a patterned background. I'm not entirely clear how to set
> > > a solid background color myself...
> > > What would be very welcome is if you can take a look at the problem of
> > > how to set a background to one or more shapes.
> > > One thing often forgotten is that the user should also have the ability
> > > to set a transparant background (i.e. remove whats there).
> > 
> > The funny thing is: So far I have noticed neither the problem nor the
> > gradient and pattern tool, both for the same reason: I use the "Styles"
> > docker for these tasks and it does everything I need just fine. It can
> > set solid, gradient and pattern backgrounds and remove the background.
> > The only thing it can't do is setting custom gradients or patterns, but
> > it should learn to do that (see below).
> 
> Well don't get ahead of yourself here. The styles docker is not a tool so
> it can't manipulate custom gradients or interactively place patterns.
> 
Oh, yes, you are correct here, I'm sorry. They are being directly manipulated 
and thus should be a tool and I somehow missed that. Shame on me.

I still think that the Styles docker in its current implementation works 
pretty well for setting and removing background colors, gradients and 
patterns. But since the placing and direction of gradients/patterns is done 
visually, it has to be a tool, I agree.

> > Obviously if even developers don't use this well-working method but
> > instead use tools which seperate functions that should go together, this
> > looks like a discoverability / consistency problem to me.
> > 
> > And I think this is connected to the topic "Dockers vs. toolbars vs.
> > dialogs." I mentioned, where I've actually forgotten the fourth way to
> > change properties: Tools.
> 
> Yes, however please not that tools present dockers too
> 
Yes, but if the only thing a tool does is to present a docker, than I don't 
think it should be a tool. For gradient and pattern editing, this is not the 
case, of course, as you showed me.

> > It now becomes quite obvious to me that this is the underlying problem
> > here: It is not clear which method to use to do what, even to developers.
> > 
> > So what we need is a crystal clear separation of tasks between tools and
> > dockers. My approach would be to use tools only for things that change
> > the cursor to navigate/select, directly create or manipulate elements of
> > the documents.
> 
> Well since we like to manipulate manythings directly with the mouse, that
> would exclude most dockers that are only dockers. (fine with me)
> 
Any tool that does nothing but display a docker should not be a tool.

> > Setting background, on the other hand, isn't something you do by
> > manipulating a shape with the mouse. You select a shape and then change
> > its properties using dockers in the end.
> 
> Wrong. Custom gradients are vary much manipulate by mouse, and the same
> goes for patterns.
> 


> I'd propose to get rid of the styles docker and only have a styles-tool
> (with accompanying dockers) instead. I'd call this tool Background tool.
> 

Yes, this sounds like a good idea. Though setting the border style with the 
some tool does seem to make sense to me, so maybe we should use a different 
name.

So what about this:

There is a WhateverWeWillCallIt tool which opens the a docker with the same 
functionality as the current styles docker. If "Gradient" is selected, the 
gradient-related dockers appear directly below it (they currently don't 
necessarily do) and the cursor changes to the gradient editing mode. If 
"Pattern" is selected, the pattern dockers appear and the cursor changes to 
gradient editing mode. Since they are mutually exclusive, this should not be a 
problem.

> This would also have the clear benefit of not having the styles docker
> always around taking up precious space, for something that in reality is
> not that often done.

Yes, true, this totally makes sense.

I'm really sorry for somehow missing the direct manipulation aspect of the 
gradient/pattern editing. But your idea could work pretty well and still keep 
the clear distinction between tools and dockers, since the gradient and 
pattern editing meets the "manipulate by mouse" criterion.

Regards,
Thomas
> _______________________________________________
> 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]