feat: clearly distinguish select and hover states

[nikku]

This proposes a rework of our hover and select outline, as well as interaction (resize, drag, ...) handles:

• No hover state (no blinking as you move the mouse)
• Clear, solid outline for selected elements
• Clear, no opacity, unified size handles to interact with diagram elements (resize, bendpoints, ...)

Role model for this change is Google Slides, but similar approaches can be found in many different apps.

---

---

Try it out locally:

npx @bpmn-io/sr bpmn-io/bpmn-js#develop -l bpmn-io/diagram-js#select-hover-states

---

TODO

• Settle down on variation
• Make this work with multi selection (Multi-element context pad #278)

---

Related to bpmn-io/bpmn-js#1616

[philippfromme]

In my opinion, we should not only increase the line width but also the size of the handles (resize, segment move), which are smaller than bend point move handles. I proposed this years ago.

[andreasgeier]

I'd go with 2px. Consider, that single select is the default case and it should help to better see/find the selected element. Particularly in case of clicking on an error message references.

Please avoid a hover state on selected elements. It's not common and I believe it is confusing.

edit: no hover on selected elements seems already work as expected

[nikku]

@philippfromme You have your adjustments on a branch?

[philippfromme]

@nikku https://github.com/bpmn-io/diagram-js/tree/philipp-styles 😉

[christian-konrad]

2px looks better. 1px makes sense for high-precision drawing tools (adobe, affinity, sketch...), but for a rapid modeling tool, quick distinguishability and clickability is more important.

[nikku]

I'll provide another version that incorporates @philippfromme styles. If we go for #640 (comment), more general clarity on our UI controls helps.

[nikku]

2px looks better. 1px makes sense for high-precision drawing tools (adobe, affinity, sketch...), but for a rapid modeling tool, quick distinguishability and clickability is more important.

Visual sizing has no impact for clickability. This is really about what we want to be, a happy looking sketching tool, or a slight less in your face app. Miro for example goes for 1px, no problem and looks clean because of that.

[nikku]

Accounting for @philippfromme feedback but also taking into consideration other drawing apps I've reworked this PR:

• Outline is solid, if it is shown
• Hover outline is gone (no-one has it)
• Handles are not transparent, and sized appropriately
• No two pixel border, as this looks toyish (and other tools don't have it, too)

---

---

I've considered the following tools for comparison:

• Google Slides
• Excalidraw
• Miro

[currandwyer]

I think this is looking great! Cool that we're working on it. One question for you @nikku - why don't we ease the corners of the selection boxes? I think this looks much more refined, given that almost everything being selected also has rounded corners. All we would need to do is decide on a different behavior for pools, which seems doable to me.

[philippfromme]

why don't we ease the corners of the selection boxes?

@currandwyer Do you mean border radius?

We could use the same border radius as we do for forms.

[nikku]

@currandwyer Thanks for your feedback!

As mentioned here I'd love to take easing (rounding) borders out of this topic, as "doing exceptions based on element types" is not a direction I'd like to go right now. It is not only about pools, but about gateways, groups, DMN decisions, ...

Selection outline shall be a general concern and not depend on the shape of the element; at least this is something that I'd not expect as a user. If you consider Miro for example, they agree with me:

[nikku]

@philippfromme That is a minimal one, right? I'll give it a shot and report back how that looks like.

[currandwyer]

Yeah @philippfromme I think even just having 1-2 px corner radius is nice - it's subtle, but it softens the look a bit, and shows that you thought about it. By the way, in Operate we already have a relatively large corner radius:

[nikku]

Playing around with radiuses:

As close to Task as possible (10px)

Minimal (3px)

What do you think?

[nikku]

@currandwyer Thanks for the operate screen. Does the user interact with Participants there? How does operate handle selection on DMN DRD diagrams (with decisions and text annotations)?

[christian-konrad]

@nikku is it possible (and to what cost) to have the outline thickness be fixed, so not to scale with the canvas when you zoom?

[christian-konrad]

@nikku interesting thought to get rid of the hover outline at all, this solves many problems with multi-select.
But, would it be possible then to turn the cursor into a drag cursor (like in Google Slides / Excalidraw)
(Just a thought, I am not even sure if I like it)

[nikku]

@nikku is it possible (and to what cost) to have the outline thickness be fixed, so not to scale with the canvas when you zoom?

Not easily possible.

But, would it be possible then to turn the cursor into a drag cursor.

When exactly? We could do it. But I don't miss it (and no-one ever did).
It would also cause conflicts, i.e. in places where you could both start dragging, but also direct editing via double click. TLDR: Let's not optimize it in this PR 😉

[nikku]

I was wondering, shouldn't the outline always be on top? thinking Like, not covered by the boundary event.

Let us follow up with this in a new issue @philippfromme.

I've checked other tools and that is exactly how they do it. Our multi-select outline also works like this:

[philippfromme]

Let us follow up with this in a new issue @philippfromme.

👍🏻

[christian-konrad]

Just found this bug while testing, which could be caused by this bpmn-io/bpmn-js#1657

[christian-konrad]

I am not 100% happy with having no hover state anymore, but as this solution solves current problems, please move forward with it.
Reconsider hovering if a designer comes up with it and good reasoning.
(There isn't even a real best practice there, there are vector, drawing, model etc tools with and without hover states)

[nikku]

Potential follow up once we got this merged (#643), incorporating @christian-konrad earlier comment (#640 (comment)).

I did check other tools and a majority do it as suggested.

[nikku]

@philippfromme As discussed, please leave this leave your review.

[philippfromme]

As discussed, please leave this.

I was about to approve. What do you mean?

[nikku]

Hahaha. leave you review :).

[philippfromme]

This is such a neat package of improvements! 🏅 I love it!