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

List:       koffice-devel
Subject:    Re: Usability Topics
From:       "C. Boemann" <cbo () boemann ! dk>
Date:       2010-08-22 12:22:18
Message-ID: 201008221422.18928.cbo () boemann ! dk
[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.

 
> 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

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

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

> Thus, I think this problem can be
> solved in the following way:
> - Remove both background setting tools
From above obviously not what we shold do

> - Make the styles docker appear by default when selecting a shape to which
> styles can be applied.
> - Provide a button next to the select boxes for patterns and gradients in
> the styles docker which opens the corresponding dockers to edit the
> predefined ones.
> - Provide a button below the selectboxes in the styles docker to set custom
> gradients/patterns or fine-tune the the current background, which open the
> respective docker.
> 
Also not valid due to what i just said,

> Using the styles docker as the starting point makes sense, because we can
> assume that at least for KWord, KPresenter and KSpread probably most users
> will in many cases be using predefined gradients and patterns, so we don't
> even want to bother them with complex editing tools. And those who want to
> fine-tune them or create new ones can do that by just one more click.
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.

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