[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-26 12:46:23
Message-ID: 201008261446.24038.cbo () boemann ! dk
[Download RAW message or body]

On Thursday 26 August 2010 14:11:21 zander@kde.org wrote:
> On Thursday 26. August 2010 10.55.13 Thorsten Zachmann wrote:
> > On Thursday 26 August 2010 10:01:14 zander@kde.org wrote:
> > > On Wednesday 25. August 2010 21.02.58 Thomas Pfeiffer wrote:
> > > > 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.
> > > 
> > > Cool, I think this can be called the consensus and that we can find
> > > some time or a volunteer to write such a tool soon :)
> > 
> > I can't see how we came to a consensus yet.
> 
> All the raised points have been addressed and various people agreed on one
> solution that our usability expert suggested.
> 
> > I think there is still a lot to
> > think about and as Boudewijn said all the dockers and tools need to be
> > taken into account there.
> 
> I read the mail from Thomas P. to address this quite adequately; was there
> anything unclear?
> Most of KOffice has been designed by developers, in this specific case
> several different ones that each solved their own problem in different
> applications. I think its quite important to value the fresh perspective
> from Thomas Pfeiffer and avoid discussions that most engineers love but a
> volunteer usability person might find a bit much.
> 
> > E.g. the line docker is also a docker and not a
> > tool so e.g. why should the styles docker not a docker as it is now.
> 
> This looks like a new topic and only partly related.
> 
> What about we get someone create a new docker by copying the code for the 3
> different tools and the docker and put them in one nice docker as Thomas P.
> outlined.  This means no current functionality is removed.
> When the tool is functional and usability reviewed we can choose to remove
> the old tools and replace it with the new and better one.
> If its not better, its not done yet.
> 
> Casper; are you still interested in working on this?
I am, but it's almost a junior job (large one though), so maybe someone else 
might want to take a crack at it. I'll mentor it if needed.

I'm pretty tied up with other jobs so I don't have much time for coding it 
myself right now, but will get back to it (we are talking probably months to 
years as I have the videoshape and tables ui and saving higher on my todo)

As an appetizer for anyone thinking about working on it. The two tools are 
very similar codewise so a lot of code can be reused. It's mostly about making 
a smart merger.

However I'm not quite sure we are there design wise yet, to begin coding.

There is this matter of defaults that we have not addressed yet. Right now 
afaik the color set in the docker is used when creating the next shape. Now we 
can still do the same: Use the last applied coloring (color, pattern, 
gradient). However it becomes a little bit more hidden what that will be, as 
the tool will not be active. 

The extra click that Thorsten says he'll make is imo worth it in relation to 
what it saves for nearly everyone else, by having a less cluttered interface, 
with easier to find options etc.

However I do concede that we have two apps where the cons might outweigh the 
pros: KPresenter, but even more so Kivio, where use of predefined geometric 
shapes are more prevalent. The work flow for Karbon is more like draw a lot and 
then color it (with custom gradient requiring a tool anyway), so here a tool 
makes a lot of sense. And for KWord geometric shapes are simply not used often 
enough to justify an always open docker (closing it would hurt 
discoverability, whereas a tool always has an icon)

On the other hand I can't help thinking that maybe Thorsten's usecase is that 
of a developer fast needing to create test documents, and so just have to 
color it some color. Whereas real users are more likely to want to choose a 
custom pattern or gradient. Not saying it is so, just likely.

best regards
Casper
_______________________________________________
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]