I’m confused about the sign up and onboarding process. I’ve created a sign up form. I am not sure how to direct new users to that form and how to direct people to the main content once they’ve completed the form.
I’m also unsure how to make sure returning users aren’t presented with the sign up form.
Should I be doing something with the sign up button on the menu screen?
As you can see, I’m pretty clueless about this whole process. If someone could point me to a tutorial, I’d be grateful.
Here is a tutorial:
3 Likes
@nathanaelb Thanks for the response. I’ve tried to work my way through this tutorial, but I had a hard time understanding how and why it works. I’ll give it another shot because other people seem to think it’s really instructive. Obviously I have a lot to learn 
. If anyone has any other thoughts, I would sure appreciate any help.
There are a lot of variables at play. If you allow your users to access the app, without signing in, then you have to build screens that will ultimately direct them to sign in. For this you’ll use the condition of whether “email is (or is not) empty”.
Once the user has signed into the app, then we want to force them to complete onboarding.
This means we need a column to refer to see if the user has completed onboarding or not. I typically use a datetime column for this.
If the datetime column in the user profile table is empty, then they haven’t completed onboarding. If the datetime column is not empty, then they have completed onboarding. This means we need to direct them to a screen where they’ll ultimately push a button to set a date time in that column.
I typically do is use a visibility condition on all tabs that will show the tabs only if that datetime column is not empty. Then I have a separate screen for on boarding that is visible when date time column is empty.
On the screen, I include some entry components that will allow the user to fill out more information about themselves. Once these entry components have been filled out, I display a button that will write the current date and time to that date and time column. This triggers the visibility conditions of the tabs which allows the user to see the app content.
I don’t have a specific video on this, but the very first video in my gamification series uses this technique.
https://community.glideapps.com/t/gamify-glide-apps-updated-2022-11-28-episode-11-craft-items
4 Likes
@Robert_Petitto Thanks. This sounds like my situation. I’ll study your video.
Much appreciated!
@Robert_Petitto after looking at your video, I have some questions. Here’s the beginning of my draft app:
As you can see I’ve created this sign in form. I’d like this to be the first thing a new user sees.
Do I need a separate user profile tab aside from the data I’m collecting from my sign in form?
Can I use this sign in form to populate the user profile as well as creating the other data I need for my app?
What sort of filter can I use to hide this from returning users?
What’s the deal with the sign up button in the menu? How do I assign an action to it?
I know that’s a lot. I really appreciate your help!
BTW… I’m using tables rather than sheets. Is that a problem?
First up, I don’t think you should show any other tab rather than “Sign Up” before the user has finished the onboarding process. We’re having 2 tabs here.
You should just collect it straight in the user profiles row. Assign the “Sign Up” tab to your User Profiles table, and filter the screen to “email” is signed-in user.
Not sure about the “creating other data I need for my app” part. Can you explain more about it?
Add a “Joined At” timestamp column to your user profiles table. When the user has filled in all the required fields in your Sign Up tab, show them a button. Clicking it will set the current timestamp to the “Joined At” column.
Show/hide the tabs based on that field (and add more conditions if needed). Basically Sign Up visible when “Joined At” is empty, and vice versa for other tabs.
If you mean the “Sign Up” tab “button”, then you can’t assign any actions to it. It’s only meant for navigation.
No, any sources should work.
2 Likes
@ThinhDinh Thanks for the very thorough reply. I’m working my way through your answers, but I have a question about this first one.
I’m mimicked my form from this post:
In his video, Darren suggests collecting the form data in a table called “Form Submissions.” So that’s how I set up my form.
That’s where my question came from. I’m confused about the interaction between the submissions table and the users table. Because it seems like the users table is required?
I really appreciate your help sorting this out. Darren’s video did a great job explaining how to set up the form, but he didn’t explain how to use that data to populate the users table or even if that’s necessary.
Does that make sense?
You should be updating the user table. You can choose any table as the destination for a form.
Like @ThinhDinh said, your tab should be filtered to the signed in user. This is assuming that a user has signed in before finishing their profile. When a user signs in for the first time, a user profile is automatically generated for that user, so what you want to be doing is editing that newly created row. It seems that you are trying to add a new row instead of editing an existing row.
1 Like
@Jeff_Hager I think I’m starting to understand.
In the app I used as a guide, @Darren_Alderman collected the data in a FORM SUBMISSIONS table. However, it sounds like using the form in an app requires storing that data in USERS table instead.
Is that right?
I haven’t studied Darren’s video very closely, but it appears that he is maybe onboarding a user BEFORE they sign in whereas what we are explaining in onboarding AFTER a user signs in. I’m not sure if his “form submission” table is intended to be the user table or not.
It’s up to you when you want onboarding to happen and will have to adjust your Privacy settings accordingly.
Ultimately, tab visibility can only be controlled by values in the user profile table. If you are performing your onboarding prior to a user signing in, you can still write data to the user profile table, but you will have to make sure that the user uses the same email when they actually sign in, so they can attach to their existing user profile row that they created prior to signing in. If you are performing onboarding after a user signs in, then they can automatically attach to their autogenerated user profile row, and can just update that existing row.
If you don’t use the user profile table to handle your onboarding, then it’s going to be a lot harder to control tab visibility. So, I’d focus mainly on getting that onboarding data into the user table, rather than attempt with yet another table.
It also should be noted that Darren is using a different approach. He is using what we call Custom Forms, which are not a native Glide forms. He is updating data in a helper table, which he might possibly be writing to the user table afterwards. It’s a more advanced approach, so I’d probably try to first understand what we users call Custom Forms. It can have advantages and disadvantages depending on the user case
Overall, there are a thousand ways to skin a cat. Darren’s is one way. Other people use a different method. It’s best to first understand what you want your app flow to be. What should a brand new user experience when they want to use your app for the very first time? Also, be mindful of your end goal. You want to ultimately control tab visibility to force users into an onboarding flow by showing only an onboarding tab, and when it’s completed, hide it and show the rest of the app tabs. Tab visibility can only be controlled by values in a user’s user profile row, such as email and/or a profile completed value. To get that value, a user has to create a new row or edit an existing row. That row is created when a user signs in for the first time, but it can also be added through a form prior to signing in (depends on the app flow you want).
3 Likes
@Jeff_Hager This is very helpful. Thanks very much for taking the time.
I THINK I get the general idea custom forms and how Darren used a helper row. If I understand you right, Now I need to figure out how to use the form I’ve created to populate the user table so I can use it to control tab visibility.
Answers a lot of questions!
2 Likes
That sounds correct. Please let us know if you have any further questions regarding this.
1 Like