Question for the Experienced: If you had to do it all over again

Questions
1

To all the experienced Bubblers,

If you had to do it all over again, what would you do differently? What would you recommend? Where would you start?

I’ve spent the last two months coming up to speed on the product and I feel like this experience could have been done more efficiently. Just wondering what the journey would look like, from the perspective of experience.

Thanks!

1 Like
2

I’ve only been using Bubble since maybe December? So I am far from being an “experienced Bubbler”, but what I would have done would be:

  1. Set up my pages properly. Having groups built-in with proper resizing, security, all the alert banners I’d need, etc.
  2. Know how to build a database. Thankfully, I’ve been doing DBs since maybe 1987, so I have a decent idea of how to structure a database. But for those out there who are new to such beasts, knowledge of decent db structure would be helpful.
  3. See how other Bubblers do it. You may have a vision of what you want your product to look like and it may be possible to make it in Bubble, but there may be other, easier, more efficient or just plain better ways to do it than your original design.
  4. Watch the demos given by Bubble. Then go find more. Spend a couple of days watching the YouTube videos out there (and there are some great ones) to learn, and to get an idea of what you’re eventually going to get into.
  5. I wish I showed the app to users much sooner than I did. I basically re-did the entire front end based on just a few comments. But it’s so much better now.

I came to Bubble after a fiasco of an experience with a low-code tool (I won’t mention who, but I’m not going back). I tried Softr and a couple of others but stayed away from Bubble because it looked a bit too complex for me. But it took me maybe a week to become dangerous enough to build a simple MVP version of my app.

3 Likes
3

Hey there @treb.gatte,

I’ve been Bubbling since what, 2018?

Here are a few things that I’ve learned the hard way:

  1. Don’t use Sendgrid (bubble’s default email api provider) if your app needs to send emails. I learned that Sendgrid has a terrible delivery rate and I had to go through and migrate everything to Postmark (my recommended email API provider)

  2. Creating an efficient database. If you really want your product to scale and want your app to run efficiently, you need to have a properly structured database that is more efficient.

  3. If you get stuck, search on the forum, don’t automatically create a new topic with your questions because chances are, the same question you had has been answered before.

  4. Naming has always been a challenge for me, but without proper naming of elements, I feel like I’ve wasted so much time selecting the wrong elements for stuff. My recommendation is to pick a naming guide for yourself, whether that’s using Emojis or adding prefixes for your elements, whatever works for you, but naming I feel is important.

That’s all I can think of off the top of my head :blush: I hope that helps!

3 Likes
4

A big one for me is to create testing tools (debugging) in-page when you’re working on complex things. You can instantly see if the problem is the database, the frontend, a conditional.

2 Likes
5

How one go about that?

1 Like
6

Hi Johnny,

Naming has been a real struggle for me. Are there any systems/approaches that work well? I’d rather not reinvent this particular wheel.

Thanks!
–Treb

7

I mean it’s honestly whatever works for you and your team. I’ve seen @jamesdevonport with emojis on Twitter, which is unique and cool!

1 Like
8

Treb,

Here are some suggestions (coming from a traditional coding perspective).

  1. Don’t use spaces (particularly with data types). They can cause problems in API’s. Use underscores instead.
  2. UI Element prefixes (without the brackets):

Input Textbox = [txt]InputName
Dropdown List = [ddl]ListName
Image = [img]ImageName
Label = [lbl]LabelName (this is any field that is just used to display text)
Icon = [ico]IconName
Group = [grp]GroupName
Repeating Group = [rpt]RepeatingGroupName
Checkbox = [chk]CheckboxName
RadioButton = [rb]RadioButtonName

  1. Name everything immediately. Don’t leave the default naming conventions thinking you will come back to them later. You won’t and it will cost you minutes or hours, trying to sort through elements. Get in the habit of creating an element and then naming it properly as your very next step.
9

One of the challenges I’ve had is naming when I have a tabbed interface. Then I have Tab1_ddListName, Tab2_ddListName, etc. as there may be elements that refer to the same data column but are in different positions in the UI. It gets messy quickly.

10

Continue to get more specific Tab1_ddlListName[Right|Bottom|Top] or Tab1_grpRight_ddlListName. The names can grow into length, but I wouldn’t call this messy. What is messy is taking over a project where things haven’t been named properly or at all. So you have things like grpData and Group Data and groupData or Label A and Label AAZZ etc.

As Johnny said, the main thing is coming up with a system that works for you and that you can do consistently.

11

I’d really like a way to visualize the data inheritance between nested objects and show me where it’s broken. I’ve been bit so many times by forgetting to add a data source correctly.