Default settings for new groups: 💩

rjwilkinson10 · 2024-09-25T21:18:21.024Z

There’s no need to have a custom default for this, which would surely be a lot more effort. Just change it to what Kelly has suggested. The vast majority of groups are set that way and it’s a pain in the a$$ to change it every time.

heythere · 2024-09-25T21:33:18.400Z

Creating a fake user to agree with might be the nerdiest thing I’ve ever seen on the bubble forums. Respect.

But say why 0. I require a rationale.

georgecollier · 2024-09-25T21:47:45.572Z

heythere:

But say why 0. I require a rationale.

Oh no, here it goes @fede.bubble @brenton.strine

fede.bubble · 2024-09-25T21:50:25.877Z

I want to know what @brenton.strine thinks of @brenton.strine comments

nico.dicagno · 2024-09-25T22:20:52.843Z

The screenshot made me chuckle - it’s quite comical how the height change was supposedly a step in the right direction while effectively not changing much, and the fit to width was just insult to injury it often makes entire screens get squished to oblivion when grouped

The Bubble team has been doing some amazing work - for example on improving the reliability and stability of the platform over the last few months. Such a monumental technical effort, and so important for the future of the ecosystem as a whole. We really cant thank them enough for their work.

But then to miss the mark on something as silly as default widths and heights of groups…

We should focus on the positives - but we are reminded of this annoying little setting way too many times per day

I completely agree with you 10-12px default height, no fit to content- and way more boost days!

phan.personal · 2024-09-25T22:55:46.427Z

I wonder if bubble devs actually use their own product, surely they would know by now how painful this is for users.

brenton.strine · 2024-09-26T03:36:19.011Z

heythere:

But say why 0. I require a rationale.

I can’t speak for @brenton.strine , who is clearly a different, but bvery smart and handsome person from me, but IMHO, the real question is WHY 10??? What actual benefit does giving groups 10 pixels of height have?

I dare anyone to say the reason is drag and drop. Do you know what happens when you try to drop an element in the design canvas? It doesn’t matter if your group is 10 px or 40 or 500, it’s not going to land where you want. And if, nay, WHEN that happens, you better hope you’re not a beginner. You better be a seasoned pro, able to draw on all your powers of deduction and intuition to find that element before it ruins your app. Because that’s what it wants to do. Why do you think it didn’t stay where you dropped it? It’s because it wants to wreck everything by hiding in some undiscoverable place, and stay there until after you push to prod and real users are trying to click on that button and then BAM that group rears it’s ugly 10px head and pushes something out of alignment and that click on that button? Isn’t happening.

brenton.strine · 2024-09-26T03:50:18.107Z

brenton.strine:

What actual benefit does giving groups 10 pixels of height have?

Bruh. Chill.

heythere:

But say why 0. I require a rationale.

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

boston85719 · 2024-09-26T04:17:52.458Z

@heythere welcome to the party

30 Boosts shipped! July 2024 Boost Days Recap

I noticed they mentioned the reduction in default width with no mention of the logical complement of default height. Both should be default of 20 and no max. I already can’t stand having to change default height of 60 everytime, 140 is absurd.

@brenton.strine reason for 10px min or 20px min in height with nothing greater than 20px is not for drag and drop. 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.

The reason for no more than 20px and likely 10px is a better maximum, is because of text elements. Sometimes a group is there just as a container of a text element, needed for design purposes, and it is not likely a text element font size is less than 10px, so the 10px group height will not negatively impact the spacing/design of the position of the text element.

30 Boosts shipped! July 2024 Boost Days Recap

Seems like consensus has been 20px or less…I’d say do not do less as for new users if they drag a group onto the canvas they still need to see the group as there and have a dropzone, but anything about 20px is likely still not getting to the root of the issue and the requests.

Needs to be big enough for somebody to see it was dropped onto the canvas, but small enough that it doesn’t interfere with most developers typical design needs, and no checked defaults like fit width, especially on groups.

Width 10px min, no max no fit width
Height 10px min no max no fit height to content

OR

Give us access via the styles tab to set the height and width so we can create our own styles

OR

Give us a universal settings area where we can set the defaults for each element type individually

gediminas.skebas · 2024-09-26T08:06:17.168Z

Couldn’t agree more on this!

heythere · 2024-09-26T12:29:39.854Z

boston85719:

Height 10px min no max no fit height to content

Noooooooo I actually like fit height to content for groups!

brenton.strine:

What actual benefit does giving groups 10 pixels of height have?

Everything @boston85719 said. I could not have said any of it better. Except the fit height to content thing. Hard disagree.

brenton.strine:

I dare anyone to say the reason is drag and drop.

I’m with you on drag/drop. A group needs to be huge for dragging anything into it successfully. And even then, it’s glitchy. My 10px rec doesn’t have anything to do with drag/drop.

brenton.strine:

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. I did a whole talk on wonky spacing, in case you didn’t know.

nico.dicagno:

The screenshot made me chuckle - it’s quite comical how the height change was supposedly a step in the right direction while effectively not changing much, and the fit to width was just insult to injury it often makes entire screens get squished to oblivion when grouped

Yup. Or as @alxgrepe said in one of the Bubble group chats yesterday…

CleanShot 2024-09-26 at 14.18.43@2x856×210 46.6 KB

phan.personal:

I wonder if bubble devs actually use their own product, surely they would know by now how painful this is for users.

It’s a little funny to imagine them all testing this out and being like “Nailed it, guys!”

adamhholmes · 2024-09-26T12:44:31.041Z

For me, the issue is not so much the height of a Group when you create it…

I think 10px or even 40px is fine then - (although fit height to content should DEFINITELY be the default).

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

In this case, it should be obvious that the desired behaviour should always be Fit Height to Content with 0 minimum height. Making the min height 40px here (or anything other than 0) makes no sense at all.

The menu item says ‘Group elements into a row’.

It doesn’t say ‘Group elements into a row and add a load of extra space at the bottom for no good reason’.

And all groups should always be created with no max width and fit width to content unchecked.

But really, as someone else pointed out already (and due to the clear disparity in opinions on this), a simple global setting in the editor to define the default settings for groups is all that’s need to resolve this.

georgecollier · 2024-09-26T14:15:49.263Z

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.
CleanShot 2024-09-26 at 15.13.46

Really Bubble? In what world is this great UX?

brenton.strine · 2024-09-26T16:07:18.514Z

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:

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)
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)
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 · 2024-09-26T16:20:21.315Z

heythere:

brenton.strine:

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 · 2024-09-27T03:38:10.198Z

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 · 2024-09-28T15:23:52.121Z

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:

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.
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.
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.
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.
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 · 2024-09-29T15:33:57.865Z

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

CleanShot 2024-09-29 at 16.33.02@2x1282×598 44.5 KB

eric7 · 2024-10-01T17:01:58.074Z

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.

khazeni.kourosh · 2024-10-06T11:01:48.976Z

OMG, even I as a novoice Bubble developer have had problem with this literally from the very first time I started building with Bubble I changes them and never have I ever kept the as default. Thankyou for mentioning it