I have some complex apps with lots of ‘link to screen’ driven by buttons and things.
However this word ‘screen’ is somewhat misleading. You get taken to pretty much a sheet, often a sheet you are already in.
For a big app with lots of functionality, it would be nice to name ‘screens’ so that you can navigate through the app more easily with less rework.
For instance in my corona test app I have been using a single tab to drive a lengthy process for a user to take a corona test… including picking a test kit, picking a service, and going through 8- 10 unique steps (including a web cam session) before seeing a final ‘success’ image.
It would be a heck of a lot easier to work things as named screens. It is doable right now, but I was trying to think about how it could be easier. Just an idea!
It would also be great to be able to put a descriptor line or two of text below the title, and to be able to decouple the tab title at the top of the tab from the tab name in the menu.
I have also been using Separators - not visible - and then retitle them in the UX on the bottom left so I can write in notes to myself about what UX components are doing.
Yes! I’ve mentioned this elsewhere, but just like how we can name actions, we should have the ability to name screens AND forms AND be able to access our named actions/screens/forms from their own sections in the Glide builder.
I’m going through the process of creating multiple sequences of screens based on the user type that they select at the beginning - what I can’t figure out is if I can merge the sequences at the end whereas everyone sees the same last screen. Right now I have to recreate the same screen for the different forks. All the screens are writing to the same table.
This is the use case I was trying to handle - a process might start with 1 branch… then have 3 possible branches… and in the end they all arrive in the same place
In the Action, Link to screen, I was hoping that the Title field would be where you can also pick an existing screen, but that’s not the case right now.
I found that if you delete the button that links you to a screen, you lose access to all the subsequent screens in that sequence. Recreating the button exactly doesn’t fix it. Thankfully it occurred to me that this could happen, and I confirmed it in a test app. To me this is a dangerous situation…
I know that problem… the good news is that you can copy tabs, so I tend to do that quite often in my apps, hiding the ones under development with a visibility setting.
So do you use “Navigate to tab” instead of “Link to screen”, and does this solve the problem? Can you navigate to hidden tabs? That would be interesting, I’m going to check it out now.
Edit: So I tried it out; it does work, and it does kind of solve the problem. Although, I tried to make the change the Tabs visibility so that they didn’t show, when on that Tab, but it didn’t work on my computer or phone. I think what I can do this is change the visibility show that the Tabs show/hide in a sequence while I go through the Tabs.
Edit 2: This would also solve the merging forks issue that I mentioned previously. I will be able to make multiple forks point to one Tab! I guess I’ll be rebuilding my app a third time haha. First as a single page app, then a multi-screen app, now a multi-tab app.
Edit 3: Another nice thing when you use Tabs instead of Screens is that the Menu isn’t hidden. So now I can move more Tabs to the Menu.
Yes, if you have complicated actions or link to screens tied to a singular button, make sure you back up that button! You can simply do a clone component and then give it a visibility condition so that it never shows up in your app unless you need it to.
Yes, this was my first approach, the equivalent of the web single-page app, (SPA). I could not get the visibility rules of the components to work to save my life.
The challenge I am working on now is cross-app syncing. I have a User app and an Agent app - and they are working from the same row in a Google Sheet.
There is a lag of 15 - 30 seconds unfortunately - not good in a call center!
So I did some tests with using a Glide Table instead across apps - it can only handle basic columns, but that is fine as I am writing in and out of the sheet. The latency is only 3 - 4 seconds on my manual stop watch - a big improvement.
Now all I have to do is work out how to include it in my app (given I have to do user testing on Wed…) So no big rearchitecting, just something sneaky that is safe and works
you can have a title in the UX, which is not really the type of naming I was expecting 