Love the concept. I’m a big fan of sliders v. spinners.
Enabled and tried on many themes (Dark, Alien, Vincent, Star Wars, etc) on both 27" and 34" ROG monitors. Could barely see the loading slider. Seems very thin. On “dark” themes the thin line seemed too soft of a color to really notice.
Also tried the slider on mobile, iPhone 6s and iPhone 6+. Similar comments. Barely noticeable.
Trying not to be a social party-pooper, but objectively speaking, the slider seems promising but needs additional CSS work (IMO), and so we went back to the spinner on our site for now, since it is noticeable and tells the “reloading story clearly”. When I have time, I will enable again and work on the CSS for our site; since this looks really promising!
Looks very promising!
Thanks and keep up the good work!
PS: No speed issues. I’m on (just off) our national fiber backbone, on a dedicated fiber to the main backbone.
I just want to mention that I don’t really care for the new UX behavior when selecting categories, topics, etc., where the current view becomes faded before the new page loads. I think the old approach of just having a blank page with a spinner was a much nicer experience.
In either case the page changes twice. But because spinners are universal things, it didn’t really feel like the page changed twice. It felt like it was preparing to change, and then changed once. Now it feels like it’s changing twice, because there is still content after both transitions, once faded and once for the new page content. It’s hard to pin down exactly why I don’t like it, but I think it’s because there’s no longer a universal loading view. Now there are effectively an infinite number of different loading views, and I find the fade-then-load loading view to be distracting since the background content is different every time I transition to a new page.
Some things that use didInsertElement hooks will need updating, yeah. With the old spinner, all elements on the page would be destroyed and recreated. With this new system, Ember will reuse elements if possible. Which might actually make rendering a little faster, but could create some bugs if customisations are not following normal ember patterns. We’ll have to work through and clean those up as we notice them.
Do you have the code for your customizations in a git repo you could share?
That’s the main reason I want to experiment with this as a theme component for a little while longer - we’ll be able to catch as many issues as possible before moving it into core.
I think there’s a mobile bug (at least on iPhone) with this new feature. If you select “Latest” from the navigation dropdown, when the page loads the dropdown properly goes away. But if you select “New” or “Unread” (possibly others), the dropdown is still visible. It doesn’t happen 100% of the time, but often enough that it should be easily reproducible. Note that this did happen sometimes with the old version, but only with “Latest” and never with “New” or “Unread”.
Thanks @dodesz - I had a play with this and I think this is a better way of doing it, which should work with the new slider: https://github.com/VaperinaDEV/category-btn-name/pull/1 (sorry if I messed up any of the Hungarian). That kind of pattern should be useful if others need to update their components as well (using computed properties rather than didInsertElement and JQuery).
I think when scrolling up and down a topic / topic-list, activating the slider doesn’t make sense. The page isn’t changing state, we’re just adding content at the top/bottom.
Granted, when clicking the topic title it does feel like a full page load… so maybe that specific case should use the slider
In the place where the post will appear? I think in that case it’s not really a page transition, it’s just part of the UI loading, so the spinner is ok? I don’t think we’d want to trigger a full page load for this kind of thing, because it would fade out all the other topic content.