Things I've learned while building complex apps

@petter - Nevermind. I just rewatched @dan1’s grocery app demo video and I think I realized my probem. I was trying to create a list or add the first value on my list for that user as part of “creating a new thing” using the “set a field” function like I had for the other input cells. Looks like I need to have a separate element to create the list ahead of time and then use the “add to a list” function as a secondary workflow after creating a new thing, rather than trying to do it all at once. I’m going to try that and see how it goes.

2 Likes

@dan1 - Watching the second half of your “How do I build a grocery list app?” video has helped me with custom states and lists. However it is still not clear to me how types of things behave when a field of another type of thing. For example: when creating a list, why can’t your user field be list of “thing”? In your video at minute 14, you create this field on your user type as “List_item”:
image

I was expecting the field type of “Grocery_List” to be “List” for each of the grocery lists you’ve created as their own “thing”
image
and then you are adding that “list” to your “Grocery_Lists” list even though it is the “wrong” type
image

Hopefully you can follow this example from your video.

In more general terms, I’m running into this same issue a few different places. On my user type, I have a field named “Companies” defined as list of type “Company” but then I can’t add the names of companies to that list because they are being entered in the inputs as text not as a “company” type. Or I can get the company to be added to the list, but then all I can see is the string of characters, not the company’s name.

I’m not sure what I’m missing, but would appreciate clarification on this point.

1 Like

On my user type, I have a field named “Companies” defined as list of type “Company” but then I can’t add the names of companies to that list because they are being entered in the inputs as text not as a “company” type.

Wouldn’t the simple solution here be to use a search box that has a data type of company and you search the company’s name? Not sure why you’re using an input with type of text here. Could you explain / share a few screenshots?

If you could, please try to upload your screenshots with a bit higher resolution. A bit hard to decipher the ones you shared earlier.

Sorry if I’m making this too complicated. I’m trying to partition data through creating privacy rules (and dynamic choices) as Petter describes below.

I followed your video example to create the lists @petter describes above and it seems to work within the repeating group visual, but when I look at the company list on the user, I see this (assuming these are the unique identifiers that Bubble creates for each “thing”:
image

and when I try to reference current user’s company_list as the dynamic choice in a drop down menu, I get 4 blank rows.

Does this make sense?

OK, for anyone else having the problem with the unique ID showing up in the data table, there is a button called “primary fields”.

You can find it in the “app data” tab of data and that is where you set the unique identifier field label you want to display, so that you see “company 1” not “1544913740854x649…” I might have read this somewhere, but didn’t have context for it at the time. One problem solved, still working on the much bigger one regarding database relationships.

Just this week I was also struggeling with making a list, another video gave me the simple answer: begin with the list field you want to populate as the first value and then use the :plus command to add the values you wanted to add to the list in the first place.

If you know then it is easy.

1 Like

Would you recommend planing from the database first or the design first? I seem to be trying both in my one site that is heavy on the database side and can’t seem to figure out which get me from point A to point B smoother with less backtracking and fixing.

best post I read and wish it was the FIRST post I read when I started down this Bubble path (which I love!!)

Thanks for the kind words!

Actually, I’d plan for the why before planning database structure or any design. By why I mean, why am I building an app in the first place? The reason this makes sense to me is that it gives you two different perspectives: what item is actually being stored in the database, and for what purpose? And with that, you can set up a structure that you don’t need to change later.

Let’s take two examples of database-driven apps that have a similar item but different purpose.

App 1:
An online marketplace for cars
Item: car
Purpose: Allow customers to search for different cars, put them in a cart, and purchase

App 2:
A repair shop inventory
Item: car
Purpose: Allow employees at a car repair shop to keep track of cars that are in their care

Both databases have the same item – a car – but the purpose of the database is very different. In App 1, the most important app feature you have may be to allow customers to efficiently search for cars they are interested in buying. In App 2, it may be focused around who owns a car, and what is its status

Each of the apps require you to make structural database decisions early on for them to work efficiently for their purpose. App 1 may need a bunch of data types related to search and recommendations, and App 2 may need you to consider privacy regulations for the cars and their owners.

So purpose first, then database, then design.

Hope that made sense.

5 Likes

I’ve found some value in design first helping me structure the database. But still learning to be efficient. Or at least trying.

I’m building a tournament software and there are a lot of moving parts. First build was database and design at same time and now reevaluating the database structure to make it more able to be scaled.

Yeah, there’s no “wrong order”. The best method is the method that works for you, so please regard my previous post not as an attempt to describe the “best” or “correct” way, but merely trying to illustrate what my thought process looks like when planning for an app.

o. I am far from right…I’m just winging it. I really appreciated your view and wish I had it when I first began…because now I am downstream fixing a ton of things and rethinking the design of database and design.

Thank you!

1 Like

Seconding @petter again here. Thinking through the why is an incredibly important part of building an app.

When I’m at the outset of building an app, I try to spend a few hours outside of Bubble trying to figure out what the app aims to do. Then I’ll design a close to ideal database structure. Only after that, do I start porting my structure into Bubble. (Otherwise, I’ll fall down a rabbit hole of experimentation…)

When you start developing apps (in Bubble or in general) thinking through a database may be difficult. But there’s great value to at least sketching out your data types (and their associated fields and relationships) to avoid a duct-tape database.

Regardless, one of the biggest mistakes I see beginners make is to go full force in building without a solid understanding of field types. (Ex. an address split into 5 different text fields versus using geographic address, using “text” for something that should be a number, using multiple fields when a “list” would work better - ex. Listing Image1, Listing Image 2, etc).

7 Likes

That’s some good stuff.

1 Like

Thanks for sharing your views with us. It really helpful for me.

1 Like

Thanks for sharing it with us.

1 Like

Great post! Thanks for it. It very helpful and informative not only for beginners like me but for those who have some experience. It contains great tips.

1 Like

Wow, am I glad I stumbled upon this. Thanks for the great tips @petter and others! :raised_hands: One question regarding mobile:

If I understand correctly, you’re using only the responsive engine. Why don’t you tick the “Mobile Version” and do a completely separate mobile design for each page? I’m new to Bubble and figured that would make sense so that I’ll have e.g. different font sizes for mobile.

1 Like

Thanks so much for the reply! I’m not sure what you mean by:

Good to know that fonts can be adjusted with width, I guess in a similar way as CSS media queries. For now, I only need a responsive web app but will check that out later :slight_smile:

To add to my original post, I’ve designed everything for desktop and mobile in Figma (I was working with a developer before discovering Bubble). Do you think it’ll be a nightmare to do separate mobile designs in this case, too – and why? It’s a bit hard to see this now as I’ve already planned out the designs.

I understand correctly, you’re using only the responsive engine. Why don’t you tick the “Mobile Version” and do a completely separate mobile design for each page? I’m new to Bubble and figured that would make sense so that I’ll have e.g. different font sizes for mobile.

Hi Codeless. You can of course do that instead, but there are a few reasons why I choose not to:

  • I consider responsiveness in general to be a best practice. Your app should respond to a changing screen size.
  • Search engines reward pages that a are mobile friendly. I assume that a light, responsive page is considered the most “friendly” in seo terms, and don’t know for sure if Google would punish you for separating it into two pages, none of which are responsive (there’s no way to say for sure how Google ranks this in the end though)
  • Only one page to update

There are absolutely cases where your solution would make sense though. If the mobile design and desktop design are radically different for example, placing both designs on one page would probably slow down your page load. So I’m not saying don’t use that, but as with everything else it does deserve some planning to see why you should choose one over the other.

For your last question, using the word nightmare may have been too strong from my part, scaring people away from solutions that may work for them. The point I was trying to make is that setting up a complete desktop design, and then change it to make it mobile-friendly afterwards can be very cumbersome. If you have planned it out on beforehand and have the designs more or less ready (which is how I understand your situation), then there’s no reason to expect it to be nightmarish. Though personally, in most cases I would still go for a responsive design rather than two separate ones.

5 Likes

Those are some good points, thanks so much.