Default settings for new groups: 💩

[georgecollier]

@adamhholmes

The issue is when you Group existing elements into a group (especially a row).

Yep… and now you point it out, I can’t stop noticing it every time I do it.

Really Bubble? In what world is this great UX?

[brenton.strine]

@boston85719

It is so that a user can see that the element was actually placed onto the canvas, because with a height of 0px, well, the height is 0px and not visible, so will lead to confusion by a user as to whether or not the element is now actually on the canvas.

I’m not sure how big of an issue that is. Here’s a 0px tall group with no contents:

And if you somehow lost it in the design canvas, you can always see it in the tree view:

Why do you need to see groups anyway, if not to drop something into it? Once you’ve put content into a group, you want to see the content, not the group itself. And of course it will usually fit to height, so he min height is irrelevant.

I think the best workflow is:

1. Drop the Group directly into elements tree (unless it’s broken ATM, then drop it into the canvas on the bottom of the page and use the element tree to drag it into the right place)
2. Maybe visually check in the design editor that it’s in the right place (which works fine even if the height is 0px, see screenshot above)
3. Put the contents into the group directly into the Group via the elements tree

No need for the height to be 10px anywhere in this workflow

[brenton.strine]

@heythere

@brenton2

I was just thinking because if the contents end up collapsing that the container can size down to 0.

No bueno. Especially if you have gap spacing. Then you have this invisible group that creates a bunch of extra space b/c you have two gaps in a row. You gotta have show/hide conditional for stuff like this, or your spacing ends up all wonky.

Definitely, but that’s not helped at all by the default height being 10px. And it’s not even always a problem, e.g. if you are in a situation where gap spacing doesn’t apply because it’s the only sibling. My point: 10px doesn’t help at all, and it sometimes hurts.

I just don’t see any reason to have the default set to 10px. It encourages/teaches thinking about Groups in the wrong way, I think. Philosophically, we should think of a group as a container that fits content and the content determines the height of the container (100% agree “fit height to content” needs to be checked by default).

Q: What’s the height of a group?
A: The height of the content!

^^ That should be the baseline assumption. If there’s ever any answer different, then it shows that something is going on for a specific reason. If I’m a developer and I see a min height value, I’m immediately thinking

Why this value? What does this do? If I change it will I break something? Does this need to be this exact min height?

In tradcode we had this term “magic numbers” for when you have a number value hardcoded in but no explanation as to where that number came from. So if a padding needs to be 2x the gap plus 4px, and the gap is 8px, it’s better to write padding-top: (gap * 2) + 4px than to write padding-top: 20px because a developer seeing the “magic number” of 20 has no idea why it’s 20. I think a similar principle applies here. There shouldn’t be completely arbitrary values (especially by default!) in elements which aren’t there for a purpose. This is why when you create a DIV in HTML it is height 0px. It would make no sense to give a container a min height.

[boston85719]

@brenton.strine

Why do you need to see groups anyway

To know it was added. I understand your point that an experienced developer can have methods that make it unnecessary to see it was added. But, Bubbles biggest challenge is new user retention or rather new users becoming subscribers. The challenge is due to the learning curve which bubble has focused on trying to flatten for several years now.

[giedraitis.mantas.21]

I also would like to chime in.

First of all, thank you @heythere for starting this discussion again. I hope with your help we can not only get this sorted, but maybe, just maybe, change the symptomatic problem of Bubble not listening to their users.

I was actually the one who started this min pixel and min width discussion about 4-6 weeks ago, and got Bubble down from 60x60 to 40x40, all the while saying this change doesn’t help at all, and we need 10x10 and NO fit width (but for sure YES to fit height).

So I hope we’re going to get this right this time.

The reason for 10px height and NO fit width (but YES to fit height) is very straightforward, there’s no questions about it:

1. Height needs to be more than 0px, for the users to see it was placed. Even if we, as experienced users, can traverse the elements tree easily and see containers clearly, it will be no bueno for newer users. And Bubble has to be as accessible as possible. So some amount is needed, that is understood.
2. Why 10px? Needs to be small enough to just leave it there for all of the containers. Again, why 10px then? Because it needs to be no higher than anything you put in it, without container height influencing gaps or heights on it’s own. Therefore, it needs to be as small as the smallest thing you can put into a container. @heythere mentions text elements, I can name icons too, there’s more. We’re not putting 8px text or icons.
3. Fit width should be OFF, fit height should be ON. Container widths are set on the most parent of containers, everything else floats freely. Almost always, as there are rare exceptions for, like, a container around an icon. For those we can make custom adjustments. And container heights are very rarely not fit height.
4. Both the sizes of 10px, and Fit width OFF and Fit height ON is because these settings HAVE to be such that we would not need to go to adjust the layout settings, until and unless we need to. Now we have to go undo all of it with every single group placed.
5. These settings are used I would say 998/1000 times. In one or two in a thousand moments, we can make custom adjustments.

Talking about the symptomatic problem of Bubble not listening… I heard there were a lot of discussions in the team about this. That is cool, and don’t get me wrong, I see Bubble improving in hearing the users.

But let’s talk about this specific annoyance. Again, 4-6 weeks ago, I reached out through X, Bubble folks responded, the message was sent to the Bubble team. And I am grateful for this. Them being responsive at the beginning on the flow is what improved the most I believe.

But then, the decision was made inside Bubble, where neither I, nor anybody else (for all I know) from the community got any say.

The decision of changing those numbers from 60px to 40px, and not changing fit width to OFF was just sent back to me, as a given. I said this doesn’t help at all, but the decision was made, the change was made and got life the next day if I remember correctly.

No “what do you think, would this fix the issue? Should we ask somebody else out of community too, if they agree?” or anything.

That is what’s lacking in the process. I see Fede, I see Sam, I see Andrew, I see @bubble, I sometimes get to go to feedback sessions.

But I believe there needs to be constant communications with the community, with egos set aside. Whatever the channel the feedback came in (I know there’s Slack community).

We don’t bite, at least I don’t And I am always ready to jump on a call to talk through stuff.

Again, thank you @heythere for organising the discussion, and I hope my feedback helps a bit.

[georgecollier]

You know what’s an even more incomprehensible offender? Pages are still not responsive by default!

[eric7]

Ideally would allow these to be set in the styles menu so we can all choose what works best for our needs. If not possible, I agree with your suggested dimensions.