User interface issues

[Cyrille Berger Skott]

On Wednesday 10 August 2011, Inge Wallin wrote:
> 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.
That is hardly an argument against Calligra, if the behaviour works.

On that one, you would need to discuss how it should work with an usuability 
expert. Because it does raises some question, does it apply only to the 
"background" text, where anyway the default tool is useless ? Or also to 
"floating" text ? And if it applies to "floating" text, what happen when you 
click on path ? Does it show the default tool or the path editing tool ? Asif 
it is the default tool, then it does introduce an inconsitency in the 
application, but maybe that inconsistency is acceptable for users of a word 
processor.

Also does it concern only words, or stage as well ? The current behavior is 
totally acceptable for karbon and for braindump.

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

That is a bug in Table, it works in other application/shape, for instance if 
you are editing a text with the text tool, and click on a vector, you get the 
vector tool.
 
> 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.

Which tool can be used to create and edit ? Because as far as I know the 
calligraphic pen tool can only create... if you want to edit, you need to use 
the path editing tool.

I think that most of the confusion about the tools comes from that they are 
not correctly categorized, our toolbox support multiple category, currently we 
have (except in Krita) three categories "canvas tools" (zoom+pan), "specific 
tools for a shape", "everything else".

The problem is the "everything else" category, where you have a mix of shape 
creation tools and shape manipulation tools. They need to be put in different 
categories.

My suggestion would be to have from the top:
* the "so-called default" tool in its own category
* the "creation tools", in order "freehand", "path", "connection" (and 
calligraphy should probably be only visible in karbon)
* the "shape editing tools"  the specific shape tools + the shape manipulation 
(when relevant, no point in showing the gradient tool if the shape does not 
allow to set a gradient)
* the "canvas tools" (ie zoom and pan)

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

If it is only a discoverability problem, I can suggest to create a "first time" 
document for each application, like we have in krita:

http://cyrille.diwi.org/tmp/krita/screenshot46.png

And that can be used to point out the important part of the UI.

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

I must have misunderstood something... Because those two paragraphs seem to 
contradict themselves. The way I read then, paragraph #1 -> more dockers 
should be visible, paragraph #2 -> less dockers should be visible.

On a side note, we already had a discussion on the subject:
http://lists.kde.org/?t=128241419800004&r=1&w=2

In any case, the way to move quickly between graphics edition mode and text 
editing mode is to switch tool. And that thread suggested the creation of a 
"coloring tool" for the purpose of editing graphical aspect of a shape.


-- 
Cyrille Berger Skott