Direct editing box hides underlying element

[nikku]

Is your feature request related to a problem? Please describe

As I'm editing an element the actual element is hidden by the direct editing box. This is a source of confusion, especially as elements are being created with a particular item (i.e. a service task) and the icon not being visible.

As an improvement I suggest hiding the direct editing background. This improves the editing experience for internal labels, as far as I believe. Not sure if the impact on external labels is a positive one, though:

Describe the solution you'd like

• [ ] Direct editing box does not hide element it is editing (unless explicitly configured)

Describe alternatives you've considered

I can override the relevant styles via !important CSS.

Additional context

This came up in multiple occasions in the context of our element template / connectors work.

[philippfromme]

How would that affect editing text annotations?

[pinussilvestrus]

This is a source of confusion

How much do we already know about that? Did this pop up during user tests?

Personally, I couldn't make a decision, I'd need more feedback from our users. Especially because I didn't find any feedback regarding this in our backlog from the past.

[nikku]

How much do we already know about that? Did this pop up during user tests?

It popped up twice during two user tests (web-modeler QA + another one).

[christian-konrad]

I really found the editing box confusing (it is hard to distinguish from the task itself, therefore it looks like the task turned into a rectangle). If this is a low-hanging fruit to just make the box transparent or at least translucent, we should do it, especially as the box does not even resize when text is overflowing. But I think we should only apply this to tasks, as they are already wrapping the text, not to free-floating labels.

[currandwyer]

These overflows are generally something of an annoyance, as when you have 3+ lines in the title, the (eg. user task) icon can be overlapping. I think hiding the edit box removes a bit of context and feedback on what's happening, almost feeling like a bug - and definitely like a bug with external labels. However, the icon persisting and overlapping the editing box feels like an improvement. Would it be possible to add an opacity (say, 70%) to the editing box so that the icon still appears, but is muted?

[nikku]

Thanks for your feedback everyone. I played around with the background opacity, and also colors. My sentiment is: We shall not go down that road:

Which leaves us with the option to disable the background (if you want, i.e. for tasks) but have it enabled elsewhere (sub-process, external label, text annotation, ...).

[nikku]

Moving to backlog.

Unless we come up with something clever we'll not be able to immediately act on it. @currandwyer consider make up your mind on the desired interaction in BPMN land, considering all options (internal, external, text annotation, participant, (expanded) sub-process label editing.

[christian-konrad]

We should consider this again once we implement "Append anything". Reason: After appending a new dedicated task with the new append anything palette, the input is immediately focused, hiding the icon of the task - which may seem confusing and makes the user ask him/herself "has my selection been right?"

Also, after looking at other popular drawing tools like Miro, they apply exactly this: If a label is to be set in a item that already acts like a "container" (e.g, a rectangle, card, note...) there is no additional input box, even no visible focus state other than the blinking cursor - and if you edit free floating labels, only then a border is drawn around the bounding box.

It seems like we could do this, too, without regret.

[marstamm]

Proposal: The box offers no additional value to the user, unless it is resizable. The underlying element should be enough of a border and the blinking cursor is the indicator for editing.

We can keep the background for resizable elements, as we use it without a clear boundary.

Alternatively, we should evaluate if resizing is actually a feature we want and need to support, as it seems to be broken when I was testing it and we already have an (external) way to resize labels.

[marstamm]

Moving to ready as this was brought up multiple times in recently:

https://github.com/camunda/improved-canvas/pull/59#issuecomment-2061581429 https://github.com/camunda/web-modeler/issues/8477