My app is built to be a Social Networking Service, however picture and posting has long loading screens, especially posting; whenever someone posts they get stuck on an endless loading screen (Their post posts immediately as they enter this endless issue)
I encountered the same problem few months ago (like many Adalo makers do).
Good news! There are many ways to enhance the user experience and speed up your app.
The reason why users get “stuck” or stay long on endless loading screen is because there are many click actions that will run once a user submits a post. This needs to be optimized.
Here are my tips on how to improve this. I use it in my app, and it works like a charm:
Generic App Speed Advice
Optimize and reduce Click Actions as much as possible. Challenge the need for every click action, reduce them or remove them if you can. If its already optimized, then lets improve the User Experience which is what makes all the difference here.
- Toggle OFF the instant navigation on click actions.
- Once a user clicks on button to “Post”, just have 1 click action which links to another screen which we will call “Loading Screen”.
- In this new Loading Screen, put a lottie file animation with loading spinner of your choice and put a text field that says something like “Uploading your post, thanks for your patience”.
- Put all your click actions from the “Post Button” now into this new screen under the page actions “When a User visits this screen, run these actions”
This way, the user knows that something is happening in the background and they won’t be just looking at the death spinning animation.
Good luck with the changes, once you make them you will feel a major difference.
Wonderful advice @Mohammed
Just to add a little nugget here, if you have a lot of API calls on those actions, it may be a good idea to use an external tool like Make to perform some operations in the background.
For example, on some apps that I’ve developed that use a user-to-user messaging feature, I only perform 2 actions, “Create Message” and then display a hidden webview within the message to trigger a custom webhook within Make. Then, I perform several actions within Make that happen in the background, which makes the UX pleasantly fast.
Check out this example here:
When a user sends a message, we trigger this scenario which checks the User if “SMS Notifications” and “Email Notifications” boolean parameters. If both are set to true, send SMS and Email (top flow). If one is true and other is false, perform specific operation (flow 2 and 3). If both are set to false. The last update record action on all flows marks the notification as “sent” to true, preventing the notification to go through the flow again. And all of this happens without the user experiencing any delay while these operations run.
@Flawless Thanks for the great advice, I never thought of using Make (Integromat) for this. Interesting.
I have about 3 API calls which trigger emails to 3 different recipients (Order Purchaser and 2 other emails). The APIs go to MailerSend.
I gotta take a look at this, could help speed things up for sure!
This looks like a great strategy. Can you please explain this part a little further? What do you mean by a “hidden webview within the message”?
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.