How would one accomplish this? And is there a way to insure that the fullscreen splash/loading page shows right away (as soon as the user clicks to the new page) and stays put until the transition to the new page has been completed?
Would appreciate any tips or advice on how to best accomplish this.
Sounds like a terrible user experience to be honest, so you should really consider NOT doing that.
The answer is, that it depends on how you have designed your app.
If itâs a single page app you can use a popup element and toggle it on/of every time a user use a navigation button, e.g. user clicks âmy recipesâ runs a workflow which shows the popup and hides it again after load.
If the app navigates to a different url than where the user are, you canât donor as the browser reloads all objects on screen.
@simon7 I know what you mean about the user experience. This is for a a few pages login, logout, and profile pages (the load time is slow compared to the many group transition in app so Iâm kind of forced to show some indication that the page is loading). These pages are all on different urlâs so the suggestion you provided wouldnât work?
You can put the loader into a reusable element. Set workflows on the reusable, when page is loaded to show the loader, when page loaded entire hide the loader.
Make custom workflow trigger which has action to show loader so that when from page have navigation action you can trigger the custom workflow in the reusable.
You could do the pop up in the reusable and make the reusable itself a 1 by 1 square with no background so it is small and invisible for when you place it on the page.
Ahh, I read at like, âevery time any page changes, I want a fullscreen splashâ, which would be really annoying
For a couple of pages its fine if there is no way around the loading times, but I prefer using âskeleton loadersâ where possible. I show as much of the page as possible to the user and have animated skeleton loaders where it takes a sec before the data shows. On 1 page I have a fullscreensplash created exactly like @boston85719 mentions.
What I meant about singlepage-app vs unique pages was, that if you are on page â/loginâ and show a loader after the user clicks a button and the page redirects to âuser/1234x4321â, then the user will see this transition which again can look weird (especially if there is a new loader on the â/user/1234x4321â page.
In the past I created a skeleton loader using native Bubble and it was horrible.
This is much much better.
I am a bit confused about your comment
Are you saying that when the repeating group is loading itâs data, the repeating group itself is collapsed and therefore it wouldnât show the contents and the elements inside as the skeleton loaders?
It is not possible in the new responsive engine. Even when you put the number of rows to fixed the RG doesnât show if there is no data present in the new responsive engine. Unless they put a checkbox to âshow repeating group while data is loadingâ. Current function is same as legacy responsive engine, the repeating group is not visible while loading the data.
Except the repeating group actually is there and visible, it is just the contents are not visible, even if the contents are an element with no data to be shown.
Thats a bummer. Iâm in the process of rebuilding my app, havenât gotten to any pages with skeleton elements yet. I think the solution I will go for with RG is to make a couple of reusable element with standard groups as a skeleton placeholder (in a design that mimics the targeted RG). This element can then be used as the skeleton while the RG loads. A little bloated, but should work without too much overhead.