Creating/expanding a subprocess overlaps previous content

[volkergersabeck]

Description

When creating an expanded sub-process inside a flow the sub-process by default overlaps with previous content, requiring additional user actions to properly layout things.

This is shown in the following screencapture:

Expected Behaviour

If the subprocess does not yet have following content, then expand the subprocess only to the right, such that it does not overlap the previous content

[nikku]

Nice little improvement.

[falko]

In other situations, an automatic application of the Space Tool might help.

[philippfromme]

We could even go as far as checking for available space in all directions and expanding based on that information.

[falko]

Any improvement in this area would be helpful.

[falko]

And let's be very clear here: This is how it always looks when one creates a Sub-Process because our users are conditioned to avoid the palette and use the context pad.

[gustavjf]

@philippfromme

Right, we have an issue for the scenario where there is content after the expanded subprocess. In the case of content above and below being overlapped, I think that would need further discussion on what the expected result should be. In this ticket, I'll focus on the scenario where there is only content before, and not above/below/after.

@falko

Just to make sure I understand what you mean by "one creates", do you mean the same as when "one expands", as shown in the screen capture? If not, could you explain how this issue is manifested when creating an expanded subprocess? I understand creating and expanding to be two different scenarios unless I'm mistaken.

[falko]

The default way to create any activity in the "normal flow" is to open the context pad on the current element, create an abstract task and use the wrench to morph it into the desired task type. Users do the same with an embedded sub-process, except that in this case the activity becomes bigger and currently breaks the layout. There is also a sub-process in the palette but that is mostly used for event sub-processes that are outside the "normal flow", i.e. not connected with sequence flows. For elements in the "normal flow", users are rewarded for using the context pad with the automatic positioning and connecting of the new element. In my opinion, "expanding" and "collapsing" of sub-processes is not relevant for practical use, because the contents of collapsed sub-process will be hidden in all visualizations rendered in any other Camunda tool, e.g. heatmaps in Cockpit and Optimize. Supporting this properly across all tools would be a much bigger discussion. However, creating an (expanded) embedded sub-process is an everyday operation and should be a smooth experience for users.

[gustavjf]

Got it, thanks for the clarification.

[nikku]

We moved this issue back to the backlog as the implementation and the behavioral implications turned out way more complicated than expected.

[nikku]

Work in progress on upstream feature branch: https://github.com/bpmn-io/bpmn-js/compare/1244-expand-subprocess-right.

[JacobiCamunda]

I stumbled across this today. Here is what it currently looks like.
screen-recorder-wed-jan-17-2024-13-57-48.webm

[falko]

The same happened to me in recent customer meetings and it's always pretty embarrassing. Would it be an option to have a subprocess directly in the context pad so that the layout assist can place it further to the right immediately? Alternatively, the morph would have to perform some layout assist, i.e. if the target shape is bigger that the current shape, move the shape to the right if there is space or make space for it.

[nikku]

CC @crobbins215. A good example where we're not done yet because we cause users in rather common refactoring activities (during refinement) harm.

A solution is, unfortunately, not an easy pick, as it would require a flow local space tool.

We could re-assess if there is easy picks to improve the situation.

[crobbins215]

We had this exact issue when we added "groups" to Flow, we didn't get around to the solution which would be something like #876.

[falko]

How about we just do a partial solution and assume that there is already space to the right, e.g. because we are at the end of a sequence or have already created space. With that assumption we could simply place the Sub-Process further right, i.e. aligned to the left of the morphed task and not centered on it. Maybe that is a quick win that solves 80%.

[nikku]

We tried the partial solution. It was not an easy pick at the time.

If we optimized for the partial solution, why not use append anything to append a sub-process right away using create/append anything?