Overlaying vs Collapsing group height: what's best?

When making single page web app, what’s best between putting groups one above the other and one under the other? And why?

I’ve been using both techniques and found + and - for both of them.

I don’t like groups overlapping one another because it often prevents me from hiding either of those groups. As such, I structure it so that there are parent and children groups and none overlapping. Often times, I’ll have groups within groups within groups, etc.

You should be using reusable elements for large single page apps. They sit fine on top of each other. So have page for profile / settings separated as reusable elements.

You can add collapse group to shorten the space difference at the bottom.

This will help your editor run faster. We had to start things over and change development like this because editor was becoming slow.


@sridharan.s What you you mean, by “it prevents me from hiding ether of those groups”? When two groups have the same position, there is no need to use “Collapse height” so they shouldn’t interfere with each other.
Collapsing groups often give undesired results with other groups and the solution is often, to group elements in groups. I end up having lots of grouping level; like up to 7-8 levels. This makes the app harder to maintain. What do you think?

@danielowega Thanks for your advice. I think reusables are good practice, but the severe limitations when interacting with them (workflows & passing data) makes them less desirable. There are workarounds to overcome this issue, but workarounds are for when you don’t have other choices. Complex apps built on workarounds can quickly become an unmaintainable mess.

I would agree it can be difficult to pass values through states but if you make use of plugin from bdk, this becomes very simple and easy, it is well worth the money.

I actually prefer to have the elements “in place” (overlapping); but there’s usually only one visible at a time. I use the Elements tree to navigate and toggle visibility. (I also use the browser’s “zoom view” feature to enlarge the UI elements.) My only real beef is that the tree state is not persistent, so I have to drill back down to the element of interest after a page reload.

I prefer collapsing group height for a couple reasons.

  1. Seems obvious to say it, but you can actually collapse the groups. A couple of my first apps used the “overlaying” method and I always ended up with differing heights in the elements, wishing that I could collapse that extra space.
  2. Ease of editing. I do a lot of editing of multiple groups at a time. This is insanely annoying if you have to toggle their visibility in the editor every time you want to edit them. If they’re stacked/collapsing, you can easily see & edit everything on your page without an overlaying element getting in the way.

Looks like both methods have their advantages and disadvantages. I have developed apps using both of them. For this project I think I’ll do some overlaying and some collapsing.

@nnich19, I agree that overlaying can leave unwanted “holes” in the design and putting dozens of groups on top of each other isn’t an efficient way of designing. I believe that with some rather simple CSS I can fix the unwanted holes problem though.

On the other side, never overlaying but only collapsing leads to super long page (like easily 5000-8000px) and may end up with a broken design due to interferences between collapsed/uncollapsed groups. And @sudsy, like you said, having the elements “in place” helps not loosing the design of sight. Plus to have correct behaviour, collapsing require more nested groups within nested groups which make the app more complex and heavier.

I guess I’ll have to find the right blend of overlaying + collapsing and write myself a design guideline to preserve consistency.

Thanks a lot for sharing your experience!

I recently purchased my first plugin for this issue. It was the environmental variables…after purchase I felt I may have been able to accomplish most of the same things with just custom states on the reusable element itself to reference datatypes needed on page.

The environmental variables plugin always for data to be passed between the reusable element and page without custom states and seems to do a bit more than what custom states can.

If you haven’t looked into it, I’d suggest checking out the plugin page as it has a lot of reference and examples, which is part of why I actually bought it.


Just read the next post and @danielowega recommending the same plugin