Best way to build the onboarding/signup?

Orbit · 2025-01-15T08:36:27.477Z

Hello Bubble,

I’m currently working on the signup process for my app, which includes a comprehensive onboarding flow. The process involves around 20 screens featuring various elements like input fields, sliders, buttons, and more.

What’s the best way to implement this? My initial idea was to use states represented by numbers, for example, when the state is 1, a specific screen is visible. A button on each screen would then update the state to its next value (e.g., state + 1). However, I’m wondering if there’s a more efficient or better approach to handle this?

Thanks for support

ahmed.elkaffas · 2025-01-15T08:39:27.626Z

Your approach is good. based on the state, you can update which screen to be displayed. I believe you mean by screen a hidden group within the same page. and only one group is shown at a time based on your custom state’s value.

Orbit · 2025-01-15T09:03:54.192Z

Yes i mean hiding/showing group based on the state. But not sure if that is smart if i want to add a group/screen in the middle for example i need to change he conditions on all 20 groups, but i guess it is what it is?

ahmed.elkaffas · 2025-01-15T09:16:22.166Z

You will just display each group based on the number in your custom state, so by default all your groups will be hidden and collapsed when hidden.

for example (to display the 1st group):
You will add a condition (custom state’s number = 1) → This element is visible
the same applies for all the groups.

Please let me know if you need me to show you more details

rishabh2810ag · 2025-01-15T09:18:26.526Z

using a parameter/page path ( a go to page action ) would be a better solution.
if you use states, the going forward and backward on the screens will be messy, and also wont work with the back buttons in mobile.
you can give the screens name and combine option sets for this.

ahmed.elkaffas · 2025-01-15T09:24:21.591Z

You mean redirecting to the same page ?

Orbit · 2025-01-15T09:27:05.525Z

Yes good idea, i was thinking this as well but the app will be a native mobile app so i dont think it matters then right?

rishabh2810ag · 2025-01-15T09:51:23.382Z

yes. when using on a mobile, if you try swiping back like you do in all native apps, states wont change doing that. you need a click to change states.

rishabh2810ag · 2025-01-15T09:53:50.740Z

even in a native, the swiping back on mobile won’t change states, only if you click.
states are fine in desktop , you click to go back and forth.
while in native mobile experience, you want to be able to swipe.
for this one reason using parameters makes it a better experience.

hadirs · 2025-01-16T03:01:37.728Z

Alternatively, you could use a data type or an option set to store the onboarding steps with a ‘next step’ attribute. This way, if you need to add a step in the middle, you can simply add a new item and update the ‘next step’ attribute of the previous item. Hope that helps

samnichols · 2025-01-16T03:28:24.009Z

I use a user field called “onboarding” (number, default is 1), and show/hide containers based on that. It’s worked out really well and ensures that if a user returns later on a different device, they app still shows the correct onboarding step.

Orbit · 2025-01-19T14:49:21.022Z

Thanks for the idea, this was very smart, i will add this

system · 2025-03-26T08:37:13.198Z

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