User interface issues

[Thomas Pfeiffer]

On Thu, 11 Aug 2011 18:52:13 +0200, todd rme wrote:
> On Wed, Aug 10, 2011 at 10:33 PM, Inge Wallin <inge at lysator.liu.se> 
> wrote:

>> Different types of tools aren't distinguishable
>> ------------------------------------------------------------
>>
>> Some of our tools in the toolbox are primarily used to create new 
>> data, e.g.
>> the Calligraphic pen tool. These tools can often also be used to 
>> edit the
>> contents of data, such as the path of a line. Other tools are only 
>> used to
>> change properties of already existing data, e.g. the stroke/fill 
>> docker or the
>> shadow properties docker.
>>
>> This means that we have a discoverability problem. It's totally 
>> unobvious to
>> the user that sees the stroke/fill docker that there are other 
>> dockers that
>> can be used to insert interesting data into the document. The user 
>> shouldn't
>> have to check all dockers to find out what is there.  It should be 
>> easier to
>> find, such as the 'Insert' menu which is present in OOo or LibO. I'm 
>> not
>> saying the 'Insert' menu is the route that we should go, but we 
>> should at
>> least increase the discoverability for the users.
>>
>> At the same time, it's difficult for the user to find the dockers 
>> that can
>> change a particular property of an object, since they are not 
>> automatically
>> made present when the object is selected.
>>
>> A related problem is that our system to activate and deactivate 
>> dockers
>> (Settings -> dockers-> the-docker-in-question) is very cumbersoms. 
>> We have no
>> way of mvoing quickly between, say, graphics editing mode where 
>> graphics
>> properties dockers are active and text editing mode where text 
>> editing dockers
>> like the text statistics are active.
>
> Could this be solved by letting objects or parts of objects either
> show relevant dockers or, at least, somehow "suggest" dockers?  I
> don't know how the latter would work specifically.
>
> There might also be something about dockers having specific 
> categories
> they belong to, and all members of a category can be told to hide or
> show themselves at once.
>
> Another possibility might be sub-dockers, so basically dockers that
> can hold other dockers.
>

At the sprint in April, we have come up with a general idea for this:
We need to separate tools, tool-options, dockers and menu items and
choose the best method for each element.
I have written a wiki article about that which I'd like to call to 
mind:
http://community.kde.org/Calligra/Usability_and_UX/Common/Dockers_vs_ToolOptions

This does not offer a quickfix general solution, but instead calls for 
work on
- Putting everything in the right category
- Designing the widgets according to it's category's requirements

I's still suggest following this route, because we won't get around 
doing a lot
of thinking anyway.

Apart from that, I agree that the "workspaces" function from Krita 
would be
very useful for the whole suite. We should not be tempted to think that 
this is
the solution to our problem, though.
It is a great tool for power users that have identified their common 
usage scenarios
including the necessary tools for them and now want to be able to 
switch between
those scenarios easily. It is a customization tool.
As such, it won't help novice or casual users. So we should have both: 
A well designed
default interface plus the ability to fine-tune it to one's needs.

>> Default values
>> -------------------
>>
>> We have no way to set default values for shapes. If I want to create 
>> a simple
>> diagram with boxes and connectors, I may be interested in having all 
>> boxes the
>> same color (or even gradient) and with the same font for the text, 
>> with the
>> same line thickness, etc. If these values are not the same as the 
>> existing
>> default values, we have no way of changing them so that when I 
>> insert a new
>> rectangle it automatically gets the properties that I want.
>>
>> My suggestion here is that if the user sets, say, a stroke or fill 
>> without
>> anything selected, the new values become the default values until 
>> they are
>> changed the next time.
>
> Could this be a discoverability issue?  How likely are users to do
> this?  What if the properties are simply inhereted from the last
> object you worked with?  This is how inkscape works.
>
> -Todd

I'd vote for inheriting from the last object here, because one often 
needs to
add several similar things in a row.

Regards,
Thomas