Building a massive form on a page, ideas on best practice?

I have a form where I am asking users to input drugs they are taking. Most users won’t be taking more than 3, often less, but I need to make provision for more in case. Each drug will have a set of about 25 questions asking them about various things, each of these questions has its own set of workflows and conditions (so its not just a RTE field - there are other functions working behind the scenes). So there could be as many as 75 fields being served up on a page if there are 3 drugs entered.

Each drug is also given an identifier of 1, 2, 3 etc entered in by the user so the database can create a new line item for each of the drugs, but use there user’s name to link them all to him or her. The 25 questions are nested under a heading which has toggle to allow the set of questions to be collapsed.

In my mind, I would have a form where they enter the first drug, then press a button where another ‘set’ of questions appear for their next drug, and so on.

What I’m finding is that Bubble is taking about 8 seconds to load the page with 2 drugs on display, but it’s editor that is struggling massively. The page is about 50,000 pixels long. I’m also concerned that users will have their page crash as they’re completing the form, thereby having their entries lost.

Most of my form pages aren’t as big as this one, so I’ve not had to think creatively to manage forms as large as this before.

What new approaches can I consider to make the page more manageable from my side developing this, and from the UI perspective?

I’ve already thought about subpages for each drug, but not too sure how I’d build this out in Bubble as the user should then be able to create as many of these subpages as they like given the number of drugs they need to input.


Sam here, with Bubble support. This is a really interesting UI project! I have a few thoughts and things to clarify that should help you make some smart decisions about how to structure this.

First - the Bubble editor needs to load every element that you have on the page. It is expected that the editor performance will be dreadfully slow if your page is overloaded with elements that aren’t part of reusable elements. Your comment that the page is 50,000px in height is an indication to me that this may be the cause of the slow editor performance.

In run mode, we only load things that are visible on page load. Make sure to set things “not visible on page load” by default, and only show them conditionally if they are needed. That should help improve your run-mode page speed.

My main thought here that should help improve both the performance of your editor and run mode page is to structure this set up using either option sets or data types and repeating groups. You can have one option set or data type for “Drugs,” and another for “Questions.” The questions option set or data type should have an attribute or field that relates it to a drug.

Then, on your page, use a nested repeating group setup to display the UI. The parent level RG can contain the entire list of drugs filtered by only those the user selects. In a nested RG within that parent you can set up a list of questions filtered by only questions who’s related drug is the current cell’s drug.

This will allow you to keep your editor page relatively clean and short (it should be a lot less than 50,000px with this setup), which will in turn make the performance of the editor much better. It should also have good performance implications on your run mode page.

Let me know if this makes sense or if you have any questions about it!

Hello Sam

Thanks for your input.

Yes, I thought of setting the sets of questions under collapsing heading which can be toggled which start off collapsed as to quicken the page load.

The questions are stored in a database along with other corresponding information pertaining to that question, such as the number of the question and other notes. This was the main reason of storing it in a database as we needed something a bit more expansive and robust that option sets. The question and drugs are their own data type and have their own tables.

I thought about the RG option, but realised that each field of the response for the question has its own features and workflows specific to that question. This means I manually configure each and every question’s workflow and condition to work as it should. I wasn’t sure the RG would work in this situation.

This is really helpful additional context. I understand your hesitation with the RG setup based on the need to have such a different UI / workflow setup for each question. You can use hidden groups with conditions to handle this (ie: if question type is X, display group X) - but if you really have a situation where 25 questions will require 25 different setups, then storing these in an RG and having conditionals trigger 25 different groups within that RG will be overly complex.

If the latter is the case, you may have the best results storing each question’s UI in its own reusable element. Reusable elements can really help speed up your editor performance as well, since the editor only has to load a reference to the reusable rather than all of the elements contained within it. Have you given that a shot?

If you need more specific advice, feel free to reach out to - we’re happy to take a look at your app specifically and suggest a few different options for how to improve the performance of things.

This topic was automatically closed after 70 days. New replies are no longer allowed.