Help UI - Snapiness when change state - w Video demo

Hi all :ok_hand:

Kapture 2021-10-23 at 19.04.49

Check on that video, in the SPA i load a repeating group by clicking on the card (blue or red one)

  1. Click
  2. Workflow change state
  3. In this spa, when change state (from 2.) > hide initial cards component > and show another one with a repeating group loading up to 100 things

In this video from my desktop Mac M1 everything looks pretty snappy but on mobile web iphone 12, from the click on 1. , to get some reaction, there is a 2 second lag where it looks “like nothing happened”. It should be worse on older phones, most probably.

How can i make it **instant to show a reaction on the click? Tried with a pop-up, but it doesn’t even show :-1:

live version will help, boost and this speed is still user friendly.

Could you preload all three cards with the summary card on top, and then hide to reveal, rather than hide + show?

1 Like

+1 for the above

You could also use hidden satélite elements to preload the data.

I was trying to go more with a solution on the ui responsiveness more than preloading data.

How can i show a loader/element immediately on click to be dismissed when data has loaded ?

ListShifter. Its loading state actually works.

Also, I recommend not adding any animation to the groups.

2 Likes

Starting with the slow loading times:

We often notice similar cases in apps involves multiple “full list” repeating groups with performance-heavy data sources (because the app must immediately load and query through a long list of data entries on page load), or when an app involves multiple repeating groups embedded within other repeating groups. In your case, I noticed that you had a “Repeated Group Grouping” (ext. vertical scrolling) embedded within “Repeating Group Activé.Toutes” (full list) on your home_juene page, which may have been causing the slowed rendering. While running some tests, however, I found that changing the layout style of “Repeating Group Grouping” to “Full List” actually significantly improved the page load performance. I think the original layout style of “ext. vertical scrolling” may have been causing some slowdowns because the app had to perform more extensive responsive calculations, but I’ll certainly be sharing this finding with our team for further investigation.

From support (thanks support team! :muscle:) that made the research and found the trick. I had this going on.