I have to guess I am not the first to run across this. Sorry if it’s already posted, but I didn’t see quite this issue amongst the previous threads.
I want my to onboard new users via 2 specific welcoming screens.
I have conditions set up so a new user can only see my first landing page, where they complete a profile then click a button.
That button’s custom action sets columns (which will hide that first page and reveal all other pages), shows a notification, then navigates to my second landing page.
In the Glide UI, it appears to do the right thing and navigate to that screen every time. However, the navigate to tab action does not work correctly on Chrome desktop or on my iPhone.
It usually navigates to the first tab I have, even when the whole tab is invisible (and even when all other tabs besides the one I want are invisible).
I have tested this under numerous circumstances and can always reproduce this bug on iPhone and Chrome. I can produce screenshots or a video if necessary.
Fortunately I can imagine some workarounds, but this seems like a serious bug to me, given that it influences the whole flow of the user experience, and it might be a difficult issue to debug later.
Yes, it is a tab I created at the same level as other tabs on the left hand side of my nav (not a new screen created within a flow), in case that matters.
The visibility for that tab works correctly, it is just that the user isn’t sent there.
I just tried the flow and it sent me to the Nearby Courts, I assume that’s not what you want, is that correct?
At the moment I finish the first step, all the other tabs should not be visible, and you can confirm you have configured the correct visibility conditions?
Can you include a video of how you set it up in the editor? Thank you.
I recorded two short videos that demonstrate the issue. It shows the database column I check against, the visibility conditions for all my tabs, and what happens when I sign up as a new user via the Glide UI (it does the right thing), then via my Chrome browser after updating that column in the database (it does the wrong thing). For clarity, I added a second, short video to demo a totally new user in Chrome, not just one I tweaked data for.
I updated the permissions for you. I appreciate your checking it out.
I think the videos will suffice to demonstrate the difference in behavior between browsing via Mac Chrome and browsing inside the emulator.
If there are any more specific tests or demoes needed for a bug report let me know.
It’s probably a timing issue. In the editor, you technically have access to all tabs, so it will navigate to them regardless of visibility permission. In the live app, you don’t have to blurred tab view, so they aren’t loaded immediately. What’s probably happening is you are trying to navigate to a tab before the profile has been marked complete. Since the tab is technically still invisible when the navigate action happens, it does nothing and instead defaults to your first tab.
Have you tried to not setting a visibility condition on the beta tab at all? Maybe just let in hang out in the side menu regardless if the profile is complete or not.
Another thought is to make a duplicate of that beta tab, and instead have 3 possible values to mark a profile completed. First they have to complete their initial profile and tap the button, then you display only the beta tab in the main tab row, then when they tap a button, it sets another value in the profile, hides the beta tab, and shows the rest of the tabs.
Another thought is to simply have the profile screen with two buttons, the first button will hide the entry components and show the info from the beta tab and a new button, then the second button will mark the profile complete and they are in the app with the rest of the tabs.
Lot’s of ways to approach it, but I think you just need to explore other flows because the actions run too fast and complete before the computed columns fully compute and visibility conditions activate. The action is done running and can’t navigate since the other tabs haven’t showed up yet.
I thought maybe so, too. I tested it and it does behave differently and oddly, but it still happens for me in both cases.
FYI I have since implemented an acceptable workaround, so this bug is much less of a priority for me.
I can still reproduce the bug where the behavior of using my Macbook Chrome and iPhone browser show different pathways than the Glide emulator.
Let me know if that matters.
I’m not sure if it could be a timing issue, but I think my visibility conditions are the opposite of what you described.
Yes, it is not navigating to the tab I want, even though it’s the only one with the right visibility conditions at that point.
Where it does navigate to is a tab that is not, at the very moment the user is seeing it, matching the visibility conditions.
I had already followed your fine suggestion of adding more variables and logic to help control the user flow, and it’s definitely better this way.
I can still reproduce the bug if I had to, but now it doesn’t matter to me.
GlideBugPart1.mov
