I'm curious what you would like instead of spinners? This product makes database calls that could take an unknown amount of time to complete. How should they indicate to the user that they are waiting for the data to build the chart?

It knew which queries to run before I clicked, because those queries are baked in. Why did I have to wait for the app to do something it knew it had to do if someone clicked? Of course we can't make e.g. protein folding an instantaneous task, that doesn't mean common workflows and request patterns can't be. I guess it's the difference between "did I ask the computer a hard question?" and "did I simply ask the computer to do its job?"

In the example dashboards, I'm guessing something like 100% of requests make exactly the same queries. Maybe in a typical corporate dashboard, 70% of users will pull up the default view before leaving. These cases easy to optimize for and definitely worth optimizing for

If you own the frontend and the database, sure. But this product hits other people's databases. The only way they can optimize this is by making queries it thinks the user might want. They can't cache the response because they have no way of knowing if it changed, since again, they don't control the data source.

If I owned the database they were getting data from, I'd be mighty upset at the insane amount of useless queries they'd have to make guessing what the user wants.

Easily solved by a user configurable staleness value with some reasonable default. Google don't crawl the entire web in response to every query because for the vast majority of queries it's unnecessary. For those where it might be necessary (like news), they instead crawl at a higher frequency or use some special flow (like they do for tweets), either way the result is seamless, involves no progress spinners and is well suited for the vast majority of users.

Funny you should bring up Google. Google is so hard on infrastructure that most big sites have special handling for Google scraper requests. At reddit we put google on their own slower server cluster just so they didn't break the website.

We only did this because of the extreme value Google brings via traffic. But most crawlers and other things that made speculative queries like that were just banned.

Hi, really appreciate the feedback! I 100% agree that the way we handle initial page load is not ideal and is an area I have been meaning to prioritize for some time. We've just been swamped with other customer requests for new UI interface and charting functionality.

I am curious your thoughts on a better way to approach this. My initial thought is for a single loading state which ends when all the data is ready to display on the page. It feels inevitable that there is some loading moment when we are fetching the data. It sounds like, based on your comment, that you would prefer there to be no loading state thought?

Thanks for replying.

Precompute whatever you can I guess, but I'm guessing the app has parameterized queries and stuff like that which are hard to precompute. In that case even a cache or LRU list is fine, say precomputing the handful of most common views people will encounter most often.

Imagine even if only Jira's new ticket page and 'open tickets' search result were pre-rendered so loading them took <200ms. The amount of hate would probably drop by 90%

Separately if you can reduce the workflow for a page from being a task in its own right (most of which is waiting around) to something as simple as a click, it can increase user confidence a lot. If something that took 5 seconds (+4 of which is just waiting) suddenly completes in 200/300ms, folk learn new tricks for your tool, like middle-clicking open a bunch of screens, or noticing they can open and close it much more easily. It makes the whole experience feel more agile, which definitely has an effect on loyalty