Optimal way to store checkbox data from form

[tpmc123]

Hi All,

I’m working on a form (~15 questions + a set of ~10 checkboxes). This has led me to wonder what’s the best way (organizationally and performance-wise) to store checkbox data, assuming the checked items will be dynamically displayed on a different page (if an item is NOT checked, it should NOT be displayed).

Here’s an example form to illustrate:

I wonder if the checkbox data should be:
(a) stored in a field as a ‘List of texts’ with only the checked items added
(b) stored in a field as a ‘List of yes / nos’
(c) stored in individual ‘yes /no’ fields (one field per checkbox item)
(d) stored in its own data type, with that data type then stored in a field of the ‘parent’ data type

At this point, I’m guessing (c) and/or (d) are the best options. But I would love to hear from others how they’d handle this situation.

To test this, I created a Data Type with all options above:

NOTE: when testing each scenario, I hid the fields I wasn’t using to make it easier to read

And here’s the Option (d) ‘child’ data type:

OK, on to the ‘Submit’ button’s workflow.

Option (a) - Checkbox data stored in a field as a ‘List of texts’ with only the checked items added:
In the workflow, I added each checkbox value individually, but changed the ‘Boolean Formatting’ to the type of activity (i.e. ‘reading’) for ‘yes’ and nothing (or an empty string) for ‘no’. Here’s a workflow image:

The results were funky. Specifically, if you don’t check all options, you have the unchecked items represented by empty strings in your list:

Question: Is there a way to add selected items only to the field’s list? And would this be a reasonable way to go?

Option (b) - Checkbox data stored in a field as a ‘List of yes / nos’.
Here’s my workflow:

This clearly did not work, since I only got 2 of the 4 checkbox values entered into a database row:

I’m obviously doing something wrong here. But I’m not sure this would be a good option even if I got it to work, because it likely would be difficult to deal lists such as [yes, no, yes, no] … not easy to track which value is associated with what checkbox.

Option (c) - Checkbox data stored in individual ‘yes /no’ fields (one field per checkbox item)
Here’s the workflow:

And here’s the results:

This seems nice and organized. Since I’m just learning Bubble, I’m not sure if this method would get overwhelming if you had, say, 50-100 checkboxes?

Option (d) - Checkbox data stored in its own data type, with that data type stored in a field
Here’s the workflow (2 steps):

• Step 1 - create new ‘thing’ storing the four yes/no values
  
  
• Step 2 - store step 1’s ‘thing’ in data type that also includes name & age fields
  
  
  
  The results also seem to work, and is perhaps easier to work with than Option (c) with larger sets of checkboxes, although I’m not yet sure. The results in 2 pics:
  
  The above pic shows a unique identifier pointing to the ‘yes’ and/or ‘no’ entries in another Data Type:
  

So, in my non-expert opinion, I think options C and D can work, with option D perhaps better for very large sets of checkboxes.

Could some people who have experience with this chime in? What is your opinion on best way to handle this scenario?

Hopefully this thread will help noobs like me in the future.

Thanks,
-Tim

[keith]

You’re somewhat on the right track. (D) is the correct answer, but here’s a better a way to do it that’s more scalable:

Repeating Group - Creating a Property Features/Amenities List for a Property Listing

Here’s a pretty comprehensive video about how I do this (and why you should, too). Also teaches you how to make custom checkbox type behaviors and on/off indicators and a lot of other stuff! https://vimeo.com/278205539 Hope this helps, @luke2!

You might also be interested in the entire thread. What you’re talking about is the same type of thing as amenities (arbitrarily long lists of has this / likes this / etc.)

[tpmc123]

Hey @keith,
Thanks for the link. The video has been super helpful. It didn’t dawn on me that my checkbox choices should be the actual data in a table … I was saving them as ‘fields’. And creating the admin panel is a nice pro-tip.

Here’s where I’m at:
My situation differs from the video’s in that the checkboxes are part of a form that has not yet become a ‘thing’. So at 16:25, you make changes to an existing ‘thing’. I need to somehow get the checked info to a thing that will be created when my form’s ‘submit’ button is clicked. I’ll keep poking around but if you have a solution, please let me know!

Thanks,
-Tim

[keith]

@tpmc123

It didn’t dawn on me that my checkbox choices should be the actual data in a table …

They don’t have to be, it’s just that, if you’re going to have a lot of states like this, it’s helpful to think about in this way. (It also makes it easy to add new things to ask about in the future, right?)

As far as the interface:

@tpmc123

My situation differs from the video’s in that the checkboxes are part of a form that has not yet become a ‘thing’. So at 16:25, you make changes to an existing ‘thing’. I need to somehow get the checked info to a thing that will be created when my form’s ‘submit’ button is clicked.

That’s exactly what I’m building there in that video. I’m building the interface that you could use for the User to select their “interests”. So your form will have an RG on it populated by Do a search for… the interests they can choose.

As they click the checkbox, that workflow action would push that interest onto the user’s list of interests (or pop it off of the list if they had checked it and then unchecked it). The way I’m doing it, the list is being created for you via autobinding, right? So on submit, you’re not retrieving anything from a local custom state or whatnot – the list of interests would already be on the user. All the “submit” button might do is grab the value of any other inputs (if needed) and then take the user to the next step or whatever.

The point is that the User actually already indicated their interests and that list of interests is already on the User object.

If this step in your process is ONLY about collecting these interests, the “Submit” button isn’t really a “Submit” button anymore, it’s just a “Continue” button, if you know what I mean.

Whether it’s advantageous to do things the way that I’m proposing depends on how many of these “interests” you might have. Personally, I think if you have 10 as you say in your original post, it’s definitely worth doing this way.

Especially if you expose this information in someone’s user profile, or it’s a dating site or something. You’ve now got a very simple way of displaying the User’s interests in repeating group (the source is just User’s List of Interests [or whatever you’ve chosen to call it]). However many “interests” the User has – whether 1 or 100 – is now displayable in a completely automatic/responsive way.

This same technique can be applied to a diverse array of common interfaces, whether they are “likes”, user activities, user “milestones” (like badges earned or whatever), etc.

[tpmc123]

Hey thanks for the quick response. So, I should explain: I don’t want these ‘interests’ to be attached to a specific user. The user is filling out a form about a custom travel itinerary. This form is the first step in itinerary creation process. So, user X could fill out the form and choose “surfing” but not “cooking” one time, and fill out the form again for another trip and choose “cooking” but not “surfing” … the interests depend on the trip, not the user.

I’m not looking into custom states, seems like this could be a way to go …

[keith]

Then you just attach those things to the Itinerary. The way the idea I’m describing in the video works is that I assume the thing you’re going to attach these “yes” states already exists.

If you don’t want to do that, you can still use a variation on this technique, but the “list of interests” should be a custom state that you can put anywhere on the page.

Instead of pushing or popping an interest off of the User or Itinerary in the database, you just use Element > Set State (which state? the custom state that is a list of interests. what value to change? “add list” or “remove list” that clicked item – just like the “straight to the database” case).

Then, when your Submit button is clicked, you create a new Itinerary and you set that Itinerary’s “Interest list” to “set list… your_custom_state_that_is_the_list_of_interests_we_built_up”.

In the example of Amenities (and similar cases where you might have a VERY long list of such things), I feel its helpful to shove them right into the database so that there’s no risk of an internet disconnection or accidental reload of the page (or similar) losing the User’s work.

Aside:

If the creation of an Itinerary is a somewhat long process (or “long-ish” process) you might want to consider creating the Itinerary (with a minimal amount of info) early in the process. In this way, you could do fancy stuff like identify if the users started but then abandoned an Itinerary. (Basically when you create an Itinerary you have a flag like “Completed” or “Submitted” or “Finalized” that will default to no/false. Then if the user goes somewhere else on your site or just abandons the whole idea, you could either prompt them if they want to finish or send them a nag email or whatnot after some amount of time. Just an idea!)

[tpmc123]

Hi Keith,

I finally got it to work, phew. I attached a custom state to the repeating group that lists the activities. In addition to your video and guidance, this video about selecting items from a list and the custom state involved helped me get there: https://www.youtube.com/watch?v=yahP3RyVggY (Note to anyone watching this video … the ‘minus item’ at 7:05 is now available).

Your “aside” advice makes a lot of sense. I’m only in the beginning stages of creating this app but could totally see how this would be a big benefit. Jotted on the to-do list. Also, eventually I probably will want to add activity preferences for users when they sign up. So I’ll come back to your video for that.

Thanks again for all your help.

[keith]

I’m really glad you found that useful! The idea itself took me quite a bit of time to develop. It came out of the general problem of “geez, this is too many dang checkboxes!” Some of the other tricks, like how you can create an interface that partitions the checkboxes by category (as in the amenity example) were similarly hard to get my head around when I was first developing this technique.

That 1 hour video I made about this is WAY shorter than the time it took me to come up with all of this in the first place!

[tpmc123]

Given my pace of learning bubble, I can’t imagine how much time that took, so thanks again for sharing your knowledge. I can foresee needing to partition my ‘activity’ tags into categories as well.

Happy bubbling …