Handle loading

[michele-franchi]

Please describe the problem that your request should resolve.

We do not have a loading concept and we should display implement a way to handle loading in the dashboard, panels and tables (for all pages). For example, with a slow connection only some parts of the dashboard are loaded and no loading indicator is displayed. @danilosierrac please also take in consideration that there could be also cases where some rows inside panels are loaded in a second moment, after the page completes loading.

Describe the solution you'd like

Handle loading of sections in a nicer way.

Is it already possible to achieve the same outcome in any other way? If so, how?

Additional context

Dashboard example: https://user-images.githubusercontent.com/11598532/231723651-06d8e4fc-6f56-4b5c-838b-5ca2bec82b3d.mov

[danilosierrac]

Howdy!

I created a basic layout for loading states for table panels. Proceeding also with a details panel now. Find them on the left side of the Figma.

[janmichek]

Thanks for the preparation of the new concept. This is called a Skeleton. Which is also good, but I would wait a bit longer to implement skeletons. It's one more step further over the classic loading indicators. Skeletons are better at giving a user signal that something similar will soon load. It's a bit of a brain hack, because it decreases the user's perception of loading time, just because it similar looks .)

The problem with the skeleton, it's not resilient to changes in UI. Once we have a more stable UI eg - to know the height of the table container, or its rows, we are ready to go. We are still in the stage of many changes in UI. Changes in UI itself would mean changing the skeleton. I suggest implementing a loading indicator first, and later those skeletons.

[michele-franchi]

@danilosierrac @janmichek I think the main issue, if we exclude dashboard for a moment, is with tables especially when you navigate trough pages. To avoid the "contraction effect" we could go with one of the most used ways: display an opacity on the table and spinner at the middle of it. Something like this:

And for the initial loading we could simply display a spinner in the table body.

[danilosierrac]

Hola! I did it like this. What do you think?

[janmichek]

Hola! I did it like this. What do you think?

I personally like this one, but it has pros and cons

Pros: Content will not be jumping It's also basically a skeleton approach which will make the perceived loading time shorter

Cons: I see it will be implementation heavy. We would have to know (or guess) the container height before it loads. Not very resilient to changes. We would have to adjust the loading status skeleton for some changes in table content.

I would suggest going iteratively. The most significant pain now is there is no loading state at all. So the first logical step is to add at least a spinner (or some other visual representation)

[danilosierrac]

I agree 100%! My first idea was to just have a spinner with a fixed container height, calculated at minimum nice looking height, and then let it expand at once when the data loads. Or if it loads individually per row instance, we can let it so it cascades as well. I think is nice to see the data populating progressively. What do you think? We have a couple of discussions with @michele-franchi here but at the end I would go to what you decide knowing the software. I can also design more iterations later.

[michele-franchi]

Closing this. Loading feature was splitted in different tasks.