So often, I look at a loader and think "How long will it take? Is it actually still doing something? Or should I try to reload the page?".
Also, I often wonder why developers put tools like this on an extra domain instead of just putting it on a page or subdomain on their personal domain. Is there a reason for this that I am missing?
Often there isn't much feedback that it is easy for the client-side to give, it doesn't get any feedback until the first byte arrives in response and the time between request and first byte is far more significant than the rest of the transfer.
For things like file uploads/downloads proper progress is very useful and it is irritating when that isn't present (uploading photos to facebook on a slow connection for one example). Client-side things like number crunching too.
One problem you see sometimes where things can be easily monitored and the user informed, is that developers neglect to test in less than ideal conditions. The process works within a second on their devices and connections so they don't think to include a progress indicator, it is only when someone tried the result on something slower (an old slow CPU over a patchy mobile connection) that this becomes apparent. Also more detailed progress information is on the “nice to have” list so gets passed over in favour of bug fixes and other feature updates.
> I often wonder why developers put tools like this on an extra domain instead of
I think just fashion/appearances. It may also be an SEO thing (short URLs doing better there?).
2. I think it makes it easier to get to your website without having to use search and it is easy to share like are we web yet dot org
It is worse than the other common problem of showing "no results" until the actual results load in.
Pretty sure this is a problem across many other development platforms. Odd that you singled out aspdotnet programmers.
I was talking about myself but didn't want to admit I am the problem. (:
Don't be so hard on yourself, even after 20+ years of .NET dev there are still things I can be a bit forgetful about, such as this UI annoyance.
I agree generally but things like "How long should it take?" is more about your internet speeds / consistency, or very odd unforeseen issues on the back end, and frankly there's no amount of goofing around with even more code on your computer to determine local internet issues ... will tell me any number that makes sense.
The only time calculating "how long" is under ideal circumstances (and at that point nobody cares) or say very predictable large back end workloads. As soon as things get variable, I can't give you a reasonable number.
Sorry if that is a bit of a jumble of words and ideas there, I'm actually taking a break from troubleshooting this exact kind of issue. Customer has varying weird internet issues, wants to know "how long" ... bro wat?