User interface issues

[Boudewijn Rempt]

On Wednesday 10 August 2011 Aug, Inge Wallin wrote:
 
> I would prefer if we could have this discussion independently of 
> implementation details. 

Well, actually, many of your comments suggest an implementation "fix" to me -- more than a discussion on whether the issues are valid or not :-)


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

Let me summarize: the problem is that the expected user interaction differs from application to application, yet we use the same interaction model everywhere. This is different from all other application suites, and confuses the user.

For the text shape, in Stage and Words, no matter which tool is selected, clicking inside the shape should activate the text tool without any extra click (and show, for movable text shapes) a big border indicating where to click to move.

For Krita and Karbon, double-clicking on the text shape to active the text tool is fine.

For vector shapes, clicking should always select.

To me this suggests, that we should extend our concept of interaction strategies for the default tool by application-specific implementations.

I agree it's an issue and it impairs me a lot when I actually wants to use words or stage for real.


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

Have to agree with Cyrille: this is a bug in Tasbles. Do you know whether it's already in  
bugzilla? On the other hand, with proper app and shape specific interaction strategies for the default tool, we should be able to streamline shape selection and tool activation a lot.

> Different types of tools aren't distinguishable

I'm not sure I agree with Cyrille that this can be solved by better categorization. I think we need to sit down and make a long list of tools and shapes and figure out again which should be creatable from the toolbox, which from the shape selector and which from both.

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

Actually, in Krita we have -- we have a way to define workspaces that enable/disable different sets of dockers. We could consider moving this to other apps.

Also, moving generic dockers like the styles to become tool option widgets help a lot.

> Default values
> -------------------
> 
> We have no way to set default values for shapes. 

Easy to fix. There are actually several systems to set the defaults for shapes: we only need to add a way to make it possible for the user to set those. Either by extending the add shape docker with a config button that opens a dialog for which shapes can supply default settings pages, or, for instance, by adding a right-click menu to the default tool that saves a particular shape as a new default.

This sounds to me a bit like a post 2.4 problem, so it might be a good thing for the season-of-usability people to work an interaction design for. 

We haven't got any gui, and the engine is flexible enough to allow pretty much any kind of interaction design...

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

We actually have a current summer of code project that implements adding, deleting and tagging of resources like gradients and so on. This work should not just benefit Krita, but the rest of calligra as well.


-- 
Boudewijn Rempt
http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl