UX: Interface indication for current tool state, quick tool access by default

[simonrepp]

Hi,

Thanks for the recent bugfixes, the most obvious and basic workflows now work without crashes. \o/

Over the coming weeks/months I would like to recreate the tool icons I made for omm, this time with omm. On the one hand so that the icon generation process and creation consistently uses omm 👍, on the other hand, as a very basic hands-on usecase for omm! As I mentioned I am intrigued by the potential that lies in omm, but as of yet, in practice, I see more deterrents than incentives for anyone to use omm (including me :)), but even so I'd like to help you to work these out. I will take the time to really engage with omm on this practical usecase (the icons) and provide you with the most important insights that come up from a user perspective. I will also use my best judgement as a developer to provide you with feedback that points towards things that are actually solvable (i.e. trying to stay as much with simple tweaks and small, economic proposals for additions as possible).

That said, one of the things I currently experience as most irritating and confusing when working on simple things in omm is a lack of intuitively accessible user feedback regarding the current tool state. I need to mostly rely on my memory to tell me what might happen when I click in the viewport (and that feels very irritating in practice). Primarily I see two aspects to this that will solve the issue:

• A stateful toolbar: I've found there is a way to create custom toolbars in omm already (really cool!), I would strongly propose to initialize one for the user by default (one that contains all available tools, e.g. the standard, familiar "left-side vertical tool strip"), with the important addition that the current tool is statefully indicated on the toolbar (e.g. forced pressed state, or whichever way this can be economically implemented in Qt)
• Dynamic cursor representation: E.g. having custom cursors for each tool while interacting with the viewport (they need not be fancy, just recognizable, I can also offer to design some to help with this if you would like that)

I believe having these two would be another important stepping stone that helps users to feel more in power and less lost when trying out omm.

[simonrepp]

I need to correct myself, I failed to mention that there is a direct tool indication on top of the properties window (sorry my bad!), consequentially I would say that the implication is that the feeling of being lost apparently stems vastly from the fact that there is just no cursor feedback, so this should probably be considered the aspect with the higher priority. My suggestion regarding the stateful toolbar still stands though - if I only realize that there is a tool state indication on top of the properties window after working with omm and only when I'm specifically looking for it, this indicates that although it is there, it is obviously not where I - and likely most people - will naturally expect/see it).

[pasbi]

Yeah, that tool indicator is only visible as long as you don't select anything (Style, Object, Tag) else.
So I'm afraid it's not really useful in your case.

Let me add the tool-icon to the cursor, maybe that improves UX.

[simonrepp]

Cool. I'm pretty positive it will improve tool state feedback a lot, thanks for looking into it!

[pasbi]

I've implemented a first propsal in #165 (please survey).
I'm not really happy with the result because

1. It's not possible to use the system cursor for composition. I had to create a new cursor pointer.
2. Currently the tool icons are used, but that feels weird. I'm afraid we need to design two icons for each tool: one for the cursor and one for the toolbar.

[simonrepp]

Hey thanks, that already works beautifully in terms of how it improves the "feeling" and visual feedback of the user interface! Some more polishing to get the clicking hotspot communicated and correctly aligned and this will be spot on. :)

Regarding:

1. Most applications with custom tool cursors retain the system cursor for only one tool that mostly resembles its behavior (practically always the default select tool), in omm that would be Select Objects - I'd say it'd be totally fine to use the system cursor for that tool, and custom ones for all the others.
2. Yep doesn't work any other way because the tool cursor needs to indicate the clicking hotspot clearly, so there's very different requirements for its design too. Shall I put it on my todo list to design some (as offered above) or do you want to add them?

Love the improvement. 👍