A bit similar to the lane size increase topic I just opened: When increasing the size of a pool, this often leads to the need to move other pools which now overlap with the now bigger pool. Even though this is a somehow understandable tool behavior, this turns out to be quite irritating and confusing for users in combination with “automagical” pool size increase. See:
Moving below pools is something we could build.
We need to trade of the disturbance that brings with it with the stuff users actually gain. I can think of two things right now that may be unexpected in such an implementation:
- Moving and possibly changing layouted message flows
- Producing gaps inside the layout / hard to figure out what pools to move (cf. Application Processing for a collaboration diagram that may be affected by that)
I would believe here that moving other pools is a necessary consequence of the decision to automatically increase pool sizes. So my current opinion would be: either a.) do both (automatically increase pool sizes AND try to move other pools including re-rendering of message flows and data associations) or b.) do nothing (leave it to the user to mess with the layout). My gut feeling is a. do both. I would believe that the re-rendering of the affected elements is doable and will be good enough for 98% of the cases. The rest can be reworked by the user anyway - but s/he will at least continue to “see” everything, hence be less confused and therefore know how to rework an affected layout.