Looks good!
Clicking links on this menu (outside of the dropdowns) still shows the spinner:
1 Like
Currently it’s set to 2px, but if you’re on a hidpi display with scaling (e.g. a retina macbook), it might end up being closer to 1px on your screen. Will bump it up to 3px today
You’re right, this is kinda inconsistent UX at the moment. It’s a tricky one from a technical point of view. The loading slider is currently hooked into the Ember router, so it only shows up for Ember route transitions. Some ‘loading’ states within the UI are not actually Ember route transitions… will need to think about how we can make this more consistent.
9 Likes
I highly anticipate high DPI support. Maybe give site admins a choice between the loading slider and maybe a revamped spinning circle (cough cough 
)?
1 Like
It is now bumped up to 3px, so should be a little more obvious.
Admins can customize everything via a theme component, so if sites want to keep a loading spinner that will be possible 
12 Likes
@meghna published Custom Loading Spinner Component, which is a nice way of leveraging FontAwesome SVG icons which work at all DPI levels.
7 Likes
I absolutely love this and agree with @codinghorror that it should be moved into core as a default.
20 Likes
I think I got that one ironed out - the loading spinner should be gone from all topic list views
9 Likes
On the iPad, the loading slider does not show at all. (iPad 5th Gen… i think. iOS 14, DiscourseHub app)
See gif ^
5 Likes
Nice catch, thanks @CaptainZac. I made some adjustments so it should now work in the PWA/DiscourseHub view on iPad.
I also added the 1px top value that we need for DiscourseHub on iPhone. The full 3px height is now visible in the app and it seems to match up reasonably well with DiscourseHub’s own slider.
7 Likes
I like it a lot 
Really nice work! 
2 Likes
It seems the loading slider not activate instead of spinner loader on home page if click the logo.
4 Likes
Perfect, start using it - thank you!
2 Likes
Should be resolved now, thanks!
7 Likes
The problem with sliders is that they can actually feel slower (even if the page loads quicker).
The reason for this is because nothing happens to the bulk of the page until the page has finished loading - this is in contrast to the loading spinner version where the page goes blank immediately after click - i.e something significant happens immediately vs something significant happening after a delay.
6 Likes
Yeah that is true, and it’s something we’ve been discussing internally as well. Keeping all the old content on screen means there’s no immediate feedback after clicking a link. I’ve just pushed a change which (partially) fades out the page content during loading. (cc @awesomerobot)
Originally I had it fading all the way out, but then we were just left with a blank page. I think leaving it at 20% opacity could be a good middle ground. Enough feedback, but not too jarring? 
At the moment it’s fading out the entire #main-outlet. Unfortunately I don’t think there’s any way to target the {{outlet}} for the route that’s actually loading… but I’d love to be proven wrong. I think the only solution would be to replace all the {{outlet}}s in our code with some custom wrapper component…
18 Likes
Keeping better and better… 
7 Likes
Next level play: record how long requests take on average and make the fade animation take the same time 
14 Likes
Great. Seems much better. 
3 Likes
It’s better David …but still ‘feels’ slower. I’m not sure that will change unless the effect is as stark as it is with the spinner tbh. It may also just be an attribute of the slider, particularly if it always completes. This is because the page will have finished loading (or otherwise appear to have finished loading) before the slider completes …yet it’s the slider that will be the indicator of a page load and not the page itself because it is so noticeable.
6 Likes
https://meta.discourse.org/u/golaxo/summary
If we click from a profile view to the Discourse logo, the upper part disappears, which looks weird.
3 Likes