User interface issues

[Inge Wallin]

At the latest Calligra sprint in Berlin, we had a session about user interface 
design and issues that we have in our user interface. I am not talking bout 
the investigations that Anna's group did, but fundamental problems with tool 
and docker interaction.

It is now getting close to the first freeze before the release in November and 
absolutely nothing has happened. It is time to start thinking about this if we 
want to have anything ready at all. I am writing this mail to kickstart the 
discussion. I will enumerate a number of problems that I think we have, and in 
the thread we can add more issues and also proose possible solutions.

I would prefer if we could have this discussion independently of 
implementation details. If our infrastructure doesn't currently allow 
something that we want to do, the right way to handle it is to change the 
infrastructure, not to say "cannot be done".

So, here are the issues that I think we have to solve.

Selection of shapes vs content
-----------------------------------------

We have now a very general concept of shapes and tools. If the user clicks on 
a shape, it gets selected, and (most of the time) the default tool is 
activated. Using this tool, the user can change the shape of the tool, rotate 
it, skew it, etc. If the user double clicks the shape, he can start changing 
the contents using the shape specific tools. An example of this is the chart 
shape that allows the user to change colors, chart type, grid, etc.

There are two problems with what we currently have:

1. Sometimes it's obvious that the user wants to start changing the contents 
rather than the shape itself when he clicks.  The most glaring example is the 
a standard text shape on a page in Words.  When the user clicks in the text he 
expects the cursor to be placed in that position so that he can start writing 
text. If he clicks and drags he expects to start selecting a block of text. 
What is not wanted is that the text shape is selected or (worse) that it is 
moved around by the dragging operation. It can be argued that the user can 
always double click and thereby place the cursor, but Calligra is the only 
suite where this behaviour is happening.

Personally I would say that this is *the* biggest interaction problem right 
now.

2. Sometimes one tool is active, but another tool is what the user wants to 
use, without choosing it from the toolbox. One example is in Tables where, if 
the cell tool is activated and the user clicks on a chart, instead of the 
chart the cell under the cursor is selected. 


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.


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.


Secondary problems
--------------------------

We also have a number of problems with the individual dockers, but I think 
they are secondary and easier to solve, and should be discussed separately.

I think we also need a way to handle resources like color sets, gradients, 
etc, but that is also something we can handle in later releases.