Distinguish selected element vs. hover

[davegoldin]

Is your feature request related to a problem? Please describe.

When you create an element or select an existing element, a blue dashed border appears around the element. If you click the element again (which unselects the element), the blue dashed border remains if your cursor is hovered over the element. And if an element is selected, but you hover your cursor over another element, they will both have blue dashed borders. For a new user, this could be slightly confusing. Thanks!

Describe the solution you'd like

One solution would be to distinguish selected vs. hover. Hover would remain the blue dashed border, selected could be a more prominent blue solid border:

.djs-element.selected .djs-outline {
     stroke-width: 5px;
     stroke-dasharray: none;
     }

Describe alternatives you've considered

Another option could be to slightly darken the opacity of the canvas and everything in it – except for the selected item and its sidebar – when an item is selected. That would effectively highlight the element.

[nikku]

Could you show a screen capture of the fix you propose? Maybe it is something that is worth adopting.

CC @andreasgeier

[davegoldin]

The css I posted above produces this styling. My cursor (while it did not render in the snapshot) is hovered over "hovered action." Thanks for considering.

[andreasgeier]

Distinguishing hover state vs selection is definitely a topic for improvement. There would be more things to consider here, but switching to a solid line is a good first step.

I disagree with the stroke-width of 5px and would suggest 2px instead. That results in:

This is a super easy fix and I support this request.

@christian-konrad FYI

[currandwyer]

@christian-konrad @andreasgeier @nikku I fully agree. As discussed with each of you, here is my initial exploration of these possibilities. I would be more than happy to double down on this and create a design specification for us to discuss.

The hover states in our BPMN diagrams are the same as selected states. We should consider making the selected state a step more vibrant than the hover state. Providing visual feedback for different states and in response to user interaction improves UX and clarifies the functionality of the interface.

[christian-konrad]

@andreasgeier and @currandwyer please talk to each other on this subject. It seems like you are thinking in a similar direction.

@currandwyer's proposals in particular will have a great impact on the "finished" look of the models and reduce the cognitive and visual load during modeling.

I put this on the roadmap to considered as a later step, but keeping this open for discussion.
@currandwyer What would help is a small estimate on this (on all your proposals, not just the hover one): Will this be CSS only and therefore cheap, or is svg rendering affected? Are there any dependencies in embedding clients (e.g., the cockpit or optimize which render stuff on top off the canvas)

In case of doing this, I would like to iterate fast, but also deliver a full package of improved modeling experience.

[currandwyer]

@christian-konrad I have had some discussions with @nikku on the topic, months ago. I think it is definitely doable within a reasonable scope, but @nikku is the absolute expert on this topic. I suggest considering potentially including hover and selected states for connecting lines in the scope. I will discuss with @andreasgeier next week

.

[rpkoller]

i got aware of this issue over in the eca channel on the drupal slack. first a +1 for the initial suggestion to provide a way to distinguish visually in between the selected and hover state. and i also like the suggestion in the last comment by @currandwyer to increase the size of the handles. in the current version they are really hard to notice.
in case the dotted line style will be kept for the hover state wcag success criterion 2.4.7 has to be kept in mind. for solid lines of 1 or 2px the used color hsl(205, 100%, 50%) works out with a contrast of 3,1:1 against the white background (for non-text contrasts a ration of 3:1 is enough according to SC 1.4.11). but with dotted lines the gaps in the line decrease the focus indication area - the outline therefor is hard to see. if the dotted style will be kept for the hover state then maybe increasing the width to perhaps at least 3px might be an option (that is something that got suggested in the following wcag21 discussion on github: w3c/wcag21#424

A dotted or dashed line can be used if at least 3px in thickness.

[nikku]

Moving to backlog for the time being. Thanks everyone for the input.

[christian-konrad]

Not distinguishing both states makes multi-select somehow weird.
We should address this before we build the multi-select context pad.
Linking it to the epic.
https://user-images.githubusercontent.com/56470362/166655292-7742ccb8-1c37-4d85-a734-c7912cb7f629.mov

[nikku]

@currandwyer Could you extract your suggestion on improved hover / select states for connections into a separate issue.

We'll tackle this in a simple, straight forward manner as suggested by you and @andreasgeier. Everything beyond that I'll treat as out of scope for the moment.

[christian-konrad]

@nikku please tell me what's the scope in your opinion for now.

I agree to put the connections into a seperate issue.

But what are you now aiming to do on the node hover + select state?

[nikku]

@currandwyer Also consider adding your proposal on "improved selection box" (with round corners for the select / hover) as an additional feature request. It will be quite some work to get that incorporated I think and if we want it we'd need to tackle it appropriately (i.e. answer how it would work as a generic arbitrary diagram element concern.

[nikku]

bpmn-io/diagram-js#640 proposes a straight forward improvement (solid selection outline).

[nikku]

Closed via b158add.