Roadmap for sub-processes

We have a need to model sub-processes, both as collapsed and expanded elements.
BPMN.IO has some support for sub-processes today, but you cannot switch between the two states.

Some BPMN editors does not allow expanding sub-processes at all, displaying all sub-processes in their collapsed state.
Some does not allow modeling the content of a sub-process directly, but via a “new window”.
Some displays a “thumbnail” of the sub-process when expanded, i.e. a read only rendering of the sub-process (by default scaled 1:1).
Some reposition surrounding elements when expanding a sub-process.
Some preserve the location of surrounding elements when expanding/collapsing, requiring the user to reposition elements.
Some “remembers” the location of surrounding elements for when the sub-process is expanded/collapsed.
… etc
The variations on how sub-processes are edited are quite many, and no single solution is given.

My primary question to you are

  1. What kind of further support for sub-processes have you planned on implementing on the short term (until Q1 2016)?

If support for sub-processes are not planned, we MAY choose to implement the support ourselves.
Obviously we would like to give back to the community what we would come up with, but it would require that our solution must integrate well with the bpmnjs/diagramjs framework and fit your roadmap as well as design goals.

To that end we have identified a couple of issues/dilemmas/questions that could help us understand your vision of how BPMN.IO would handle sub-processes.

Please think of the following points as brainstorming. An answer to these questions is not required nor expected as a response to this post, at this moment. But any feedback would be greatly appreciated.

  1. Would the user be able to collapse an expanded sub-process (or expand a collapsed one)?
    a. Given the answer Yes
    i. What would happen with surrounding elements when the sub-process is expanded/collapsed?
  2. Alternatives are
    a. Repositioning (not trivial due to possible collisions, especially when collapsing)?
    b. Elements are static (possibly placing the sub-process on top of others when expanding)?
    c. A combination of the above, repositioning when expanding and preserving locations when collapsing?
  3. Would the user still be able to edit/model a sub-process in the same diagram, or would this be done in a separate canvas (like a “lightbox”)?
  4. Would it be possible to include a “thumbnail” of a sub-process?
    a. Given the answer Yes
    i. Does this require a “new” editor for the sub-process, or how would we distinguish a “thumbnail” from a 1:1 model?

@adbre Expanding/collapsing sub-processes is not part of our current planning for Q1 2016.

I’d love to given you detailed feedback on this though. Maybe we can get a joint understanding that helps us to implement a good solution in the mid term.

What we want to have (mid-term)

  • Sub-processes should be expandable/collabsable and users should be able to add/remove elements from/to it in expanded state.
  • Expanding the sub-process restores the previously saved child element bounds. Moving a collapsed sub-process moves the child elements with it (i.e. preserve locations relative to collapsed sub-process).
  • No repositioning of surrounding elements. We may almost always do it wrong (we do not do any repositioning when adding lanes to pools either).
  • Collapse/Expand state has to be saved in BPMN 2.0 XML.
  • Thumbnail: Great feature, if we figure out a smart way to generate these thumbnails in a performant manner. Thumbnails have to be clearly distinguishable from diagrams. Otherwise: nice to have.
  • In-place versus lightbox editing: Depends mostly on whether collapsed is the default state. If not, lightbox editing does not make much sense (?).

The way to go?

You mentioned it already, there exists various approaches to this. Because approaches have drawbacks we would wait for user feedback (i.e. your feedback) which one to choose.

If you’d ask me personally, I would go for “Expanding sub-processes in-place”.

  • A sub-process can be collapsed and expanded from the context-pad.
  • When expanded, child elements can be added.
  • Child element position information is persisted when collapsed and updated during parent move. This makes sure sub-processes can be moved in a convenient manner.

At the current point in time I believe layouting of surrounding elements cannot be easily tackled. I’d leave that out for now and would require users to do some manual re-layouting. Another approach would be to use a local space tool during expanding. But how to deal with collapsing (which is the more interesting use case)?.

Hope that gives you some insights. I’d be interested in your feedback regarding that planing.

Sub-processes should be expandable/collabsable and users should be able to add/remove elements from/to it in expanded state.

Agree.

Expanding the sub-process restores the previously saved child element bounds. Moving a collapsed sub-process moves the child elements with it (i.e. preserve locations relative to collapsed sub-process).

Agree.

No repositioning of surrounding elements. We may almost always do it wrong (we do not do any repositioning when adding lanes to pools either).

Very difficult to handle collapsing. Much easier to handle expansion.
Using a space tool, as you mention on expanding is something we tought of, too.

The drawback of not repositioning surrounding elements on expand is that the the elements may overlap and a large sub-process may hide entire elements.

Collapse/Expand state has to be saved in BPMN 2.0 XML.

Agree.

Thumbnail: Great feature, if we figure out a smart way to generate these thumbnails in a performant manner. Thumbnails have to be clearly distinguishable from diagrams. Otherwise: nice to have.

I agree that thumbnails is a “nice to have” feature (not required), and a “thumbnailed” sub-process must be distinguishable from other sub-processes, as well as being rendered without a noticable performance hit.

Where I’ve seen thumbnails, it’s not possible to edit in-place.
A collapsed sub-process is shown without thumbnail (rectangle with + marker), while the expanded sub-process shows the thumbnail (with the - marker).
To edit the sub-process, a second action is required to start editing the sub-process (in a lightbox/separate window), like double-clicking or context menu option on right-click.

Since expanded sub-processes are always read-only, and always thumbnailed, there’s nothing to distinguish them from.

If sub-processes are edited in-place, thumbnails does not makes much sense.
If sub-processes are edited in a lightbox, expanded sub-processes without a thumbnail does not makes much sense.
In my humble opinion…

In-place versus lightbox editing: Depends mostly on whether collapsed is the default state. If not, lightbox editing does not make much sense (?).

Disclaimer, we’re more prone to lightbox editing.

A complex sub process may not fit inside the viewport. Editing a sub-process in-place has the drawback that you cannot pan (scroll) by clicking and dragging on the empty canvas, since the canvas in the sub-process is the sub-process shape itself, and would result in the user moving the entire sub-process (relative to the process).

It is, technically, possible to treat click and drag on empty space in a expanded subprocess as panning. (to drag the container you would be required to click and hold on the border). But that would not be so consistent UX, and especially confusing when the sub-process is not that large and more similar in size to other elements. And the same issue exists for pool/lanes.

For us, it’s very important to handle large sub-processes and being able to smoothly move around when modeling a sub-process. So I belive this is our strongest argument against in-place editing.

One would be to have a feature toggle for lightbox editing. Then we could simply try it out by opt-in.

Also
In the long term, expanding/collapsing a sub-process should also be acomplished by clicking on the +/- marker in a sub-process (not only from the context pad).
Obviously, this would require BPMN-JS to render the - marker when expanded (current version does not, which is fine by the BPMN-standard).

Please keep in mind that a sub-process may also contain other sub-processes.

I have used several tools and I would recommend to allow in-place editing for expanded sub-processes but also allow the sub-process to be opened in a new tab with a button “enter sub-process” and providing a “back to parent process” button to go one level up. This is much more flexible to use and one can make full use of the available viewport while the modeler can still decide if the sub-process should be displayed expanded or collapsed in the parent-process.

– Cheers, Nils

+1 for editing in a new tab
-1 for lightbox
+0 for inplace editing

I agree with nelei’s points. Any update on sub-process editing?
Thanks for a great tool!

Hi, what is the status of this request? Is this now supported in the community edition?

We are currently investigating in better support for sub processes (tracking issue: Handle collapsed sub-processes · Issue #1443 · bpmn-io/bpmn-js · GitHub). It’s still in the prototyping phase, though.

Hi, just wondering, is this already on the main/master branch? When I try it out on:
https://demo.bpmn.io/new
this feature doesn’t seem to be available. I’m just wondering about the actual status. When I dig into the issues, it seems it is implemented, but I just can’t seem to find it in the demo-UI.
Thanks.

Hi @Kurt_Sys,

you can check out this tracking issue for the current status of the feature in bpmn-js. I’d assume once all checkboxes are ticked, the chances are high that the feature is available via the demo :wink:

yeah, makes sense. It was somewhat confusing since at the bottom, it stated that the issue implementing collapse was merged already. Well, I guess they’re pretty close to finishing it. Thx!