Camunda-modeler: Improve navigation inside large participants / sub processes

[benhoffmann]

__Description__

Many users adjust their zoom levels so that the currently edited pool fits the whole screen, so they accidently select and relocate the whole pool whenever they click somewhere on the canvas. Pools should only be selectable at headers and borders.

The situation is demonstrated in the following screen capture:

__Expected Behavior__

• [ ] As a user I'd like to not accidentally drag a large container element (sub process, participant, etc.)
• [ ] When dragging inside a large container (which I cannot distinguish from being on the canvas) I'd like to use the default canvas drag gesture (the hand tool)

[nikku]

I see your point but am not sure if the solution will be intuitive for people to use.

The behavior could be:

• If pool is bigger than the current viewbox do not allow to move it (simulate the hand tool behavior).

[benhoffmann]

The proposed solution changes the default behaviour depending on the size of the viewbox, in my opinion this is even more confusing.

@NPDeehan : any comments on that one?

[nikku]

Yes, that is the challenge. Coming up with something that is intuitive (just works (TM) and not surprising to the user) and working in all common scenarios.

We are open for alternatives.

[nikku]

We plan to improve the situation in the near future and once again ask for your feedback @benhoffmann.

After a number of internal discussions we came up with the following solution approach (sketch):

Applying to all container elements (pools, lanes and sub processes):

• container elements may only be moved after they have been selected
• container elements may only be selected on the border (or when clicking their labels)
• dragging inside a container element should move the canvas, if the container has not been selected

In my opinion this would be a decent way to prevent the described situation. What do you think?

__Edit:__ I update the issue description to reflect our current action plan.

[benhoffmann]

Hi @nikku ,

sounds OK to me, if click-and-drag is still left in place. Meaning that I don't want to click twice to select (first click) and move (second click) the container.

For smaller sub processes, the proposed behavior could be challenging as users might consider a smaller sub process more as a normal activity than a container element. They might not understand why there is a difference.

@volkergersabeck : maybe you'd like to add some UX-expertise here?

[philippfromme]

I've created a small demo to verify one of the options: _Only allow moving participants if they have been selected, otherwise move the canvas._ After evaluating this solution with @mschoe and @volkergersabeck it became clear that it has a couple of issues:

1. The feature is hard to discover, might look broken to the user
2. When zoomed in user can't see if the participant is selected

Another solution that was suggested by @volkergersabeck is to only allow moving participants using their header:

Unfortunately, this solution is much harder to implement. Therefore, I'd like to get your opinion first. @nikku @barmac @pinussilvestrus What do you guys think?

[nikku]

Assuming that users do only ever want to move a participant _or_ sub process if it is fully visible moving via header is a valid option. It is, however not as easy for the user to find the header for expanded sub-processes. Here, not only moving via a designated header area header but also by the border could be an option.

[philippfromme]

+1 for borders.

[nikku]

I guess we got to trial that option, too, to get a better feeling.

If this issue was easy to circumvent without trade-offs we would have done it in the last three years :wink:.

[barmac]

Borders + header sounds good, let's test it.

[philippfromme]

Update

I've built a second demo that implements the behavior mentioned in https://github.com/camunda/camunda-modeler/issues/238#issuecomment-501587615. After getting feedback from @mschoe and @volkergersabeck we've decided that this probably a good solution. However, Volker suggested a user test which he'd be happy to help to organize.

Both demos are available on branches:

Demo 1: https://github.com/bpmn-io/diagram-js/tree/238-participant-navigation-2 + https://github.com/bpmn-io/bpmn-js/tree/238-participant-navigation-2

Demo 2: https://github.com/bpmn-io/diagram-js/tree/238-participant-navigation + https://github.com/bpmn-io/bpmn-js/tree/238-participant-navigation

[nikku]

User Test Results (three participants)

• Consensus: Demo 2 is the preferred one (and intuitive, once you cannot move the participant anymore)
• Consensus: Additional potential improvement: Could give feedback on areas that would (if drag started) move the element
• Insight: Even without additional rounds of improvements, this is a substantial change that is worth adding.

[barmac]

Thanks for the user testing! I'll have a look at this.

[barmac]

• Consensus: Additional potential improvement: Could give feedback on areas that would (if drag started) move the element

We're leaving this for the future. Now, I'll clean the demo and build a merge-ready solution based on the demo behavior.

[nikku]

As discussed with @barmac we'll leave additional drag handle feedback aside for now and consider this as a future improvement.

[nikku]

:walking_man:

[nikku]

Unfortunately this did not make it into the released v4.0.0 version of bpmn-js.

Additional work needs to be done to properly integrate copy and paste with this feature (https://github.com/camunda/camunda-modeler/issues/1416)