[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 12:08:00
Message-ID: 201008221408.00876.colomar () autistici ! org
[Download RAW message or body]

> On Saturday 21. August 2010 20.08.32 Thomas Pfeiffer wrote:
> > Hi all,
> > now that I was welcomed again warmly, I am eager to start working with
> > you.
> 
> Belayed welcome from me too :)
> 
Thank you.

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

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.
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. 
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. Thus, I think this problem can be solved in the 
following way: 
- Remove both background setting tools
- 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.

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.

If you think this generally makes sense, I can do a mockup. If UI Files exist 
for the current dockers, I could use Qt Designer. Otherwise I'd use a generic 
mockup tool.

As you can see, the underlying problem of spreading related tasks over 
unrelated UI elements isn't just something that exists in my mind but actually 
hurts. So possibly by going into this and inspecting the task/widget relations 
in other cases we can solve other problems as well.

> Next to this is the problem that KPresenter and KWord can have a background
> for a slide or page. Technically this is also a shape, but the user can't
> select that shape so I am not sure how to make the association of the user
> settings to be for the slide/page background.
> 
So why can't the user select the page/slide? Is it for technical reasons or 
was it designed to not be possible? I'd expect that when clicking an empty 
space on the page/slide with the selection tool, it would be selected. Of 
course you couldn't move or resize it, but any properties that can be set for 
the page/slide should be set using the same means as with any other shape.
If we came up with other ways to set page/slide properties, we would break 
consistency again.
If it can't be selected by clicking on an empty space for technical reasons or 
because that would raise other usability problems, we should find an 
alternative way to select it but still set the background in the same way as 
for other shapes.

> 
> Maybe you can make a design proposal that we can find a volunteer to
> implement, this project would be much easier to do in a plugin and as such
> its something that can be experimented with easier by anyone that may or
> may not be an existing KOffice contributor.

That would be great!

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