I’ve seen other websites keep the current page completely visible while the other page is loading and the loading bar is going across the screen. Maybe that version is worth a try.
8 Likes
I want to add one more thing. I think I noticed another big difference between Discourse and some other websites that use a loading slider. The three websites I’m comparing to are https://www.youtube.com, https://github.com, and https://bookmeter.com. Here are the key differences:
- As mentioned in my previous post, rather than change the content being replaced to a blank page, these websites keep the previous content on screen (no fade or anything) until the new content has loaded.
- Generally a lot more content stays on the screen even after the new page has loaded. These websites have much more content on the top menu, and sometimes even have a secondary top menu that may stay depending on what link was clicked. They also have side menus that sometimes also remain after navigating to a new page. On the other hand, Discourse has a very simple top menu, and only the search icon, the hamburger menu icon, and the user icon always remain.
Maybe switching the behavior to keep the old content until the new content is ready will work well. But it’s also possible that it won’t work well simply because so much of the content is being replaced no matter where you navigate in Discourse.
7 Likes
In my instance I use category banners, tag banners, a sidebar showing categories on topic lists. Discourse by default also has some routes that keep top or side bars, like user profiles or groups. I very much prefer keeping the old view before transitioning so these elements on screen don’t hide just to show up again on the same place.
7 Likes
Yes, this is is how we use the new Discourse slider theme component, for about a full week now, and we really like it. We simply disabled the body transition code and use only the slider.
The natural browser action of loading (or reloading) a page takes care of the transition; and so no addition code for fading or blanking out any HTML is required. This slider looks great without any additional page transition code (faded, blanking, etc) and is how we have been running it on our site for a week now.
Thanks for this great slider and for the ability to customize it as a theme component!
4 Likes
Maybe you misunderstood what I wrote, but what I described is not how Discourse currently works with the theme component. Right now, Discourse makes most of the content a blank page while the new content is loading. The other websites I linked to keep the current content while the new content is loading. This is not the same thing.
1 Like
I am pretty sure I understood exactly what you mentioned @seanblue (above). It’s quite simple what you said, and your post was east to understand, in my view.
If you comment out the SCSS body transition (the animation) in the Discourse original slider theme component (FWIW, I modified the theme component by forking it a week ago, but there are other ways to modify a theme component).
Then, the behavior is just like. you describe.
The current page (in our mod) is displayed while the new content loads (which is simply the normal behavior of a page loading without any added body animation. The “fading” and “blanking” you see in the current Discourse experiments was due to CSS body animation code in the version of the theme (see below) when it was released a week ago.
Without the CSS body animation, the loading slider runs its normal course and there is no body “blanking” or “fading” because that animation was specified in the (original) theme component CSS. Most web sites (as you mention) do not add additional animation to the body, and that is why you said:
This is “the norm”… which happens after the body animation is removed from the CSS (I’m talking about the release a week ago, as I have not been tracking, i.e, GitHub says, our modified version is:
After we made this change, a week ago, the slider looks great (so our users say) and requires no additional body animation (fade ins or outs, blanking animations, etc.).
Below was the CSS we commented out in the “initial release” of this cool slider. This worked so well for us (and our users love it), so we have not been following all the “combo spinners, blanking” animation, body experiment code changes subsequent to making it work nicely for us; except what results I see with experiments on meta).
// body #main-outlet {
// transition: opacity 0.2s ease;
// }
// body.loading #main-outlet {
// opacity: 0.2;
// transition: opacity var(--loading-duration) ease;
// }
HTH
5 Likes
Ah, I didn’t realize you were using a forked/modded version. My bad. I’m glad this version is working well for you. Hopefully they’ll try that approach here on meta next.
6 Likes
@david / @awesomerobot I know we have gone back and forth on this quite a few times, but think we should try out the original implementation (with minor refinement) prior to a fade, let me summarize the options we have on click:
-
Keep old content on screen, flip to new content once it is ready.
-
Render “white screen”, flip to new content once it is ready.
-
Transition to opaque content (anywhere between 0 to say 40%), flip to new content once it is ready.
With all of these we also are sure we would like to add: “If content takes longer than 2 seconds, render a spinner”
(1) is the only solution that minimizes transitional states, yes, there is a bit of getting used to: “Hey, I clicked something and nothing appears to have happened”. But that is how the web works anyway when you click a hyperlink. Browser does not render a white screen or fade stuff out when you click a link to another site.
(2) what is have now, is considered harsh by some, cause one of the biggest wins of this pattern is that we avoid white screens. It is only a very very minor change over the old spinner.
(3) can be very distracting, finding the right opacity is hard. From experience when I tried it, it got extremely fatiguing after 1 hour of use.
@david we gave (2) a proper shot, can we now give (1) a proper shot for say a week. I think it is probably best cause it minimizes on screen change.
9 Likes
This… isn’t true. There is a loading animation that starts immediately on click. Look at the tab in your browser as you click a link. Note that on click or tap it immediately switches from the favicon to the loading spinner.
5 Likes
Sorry, yeah that was my point here, we can simulate something very close here to “standard”
navigation (we can change the icon on the tab for example while loading, we can change the text on the tab).
When you click an arbitrary link on a site, the current page does not go 100% white, nor does it go opaque. Old content remains on the screen for a period of time until DNS resolves for the new site and content is ready to render.
To me the big power of this component is around reducing intermediary states. If we can make it “feel” like standard browser navigation by faking it, it would be nice.
12 Likes
No worries. We really like the slider (with a few added pixels for the desktop); but found there was no need for any body animations (blanking, fading in/out, or otherwise).
The slider indicates loading nicely enough; and the page will load and change, naturally, without adding any body transition CSS or extra spinners. We have been running it this way for 8 or 9 days now, and users are happy, and I like it as well. Users did not like the “fading in / out” animations nor the “blanking the page animations” nor the “additional spinner + slider animation”; but then again, our users are not crazy about unnecessary animations and extra web-gizmos, in general.
I hope the meta team keeps this code as a theme component, or at least permits site owners to continue to override whatever they settle on; since it appears what our users like and what others like, as far as page transitions go, are different.
When in doubt, “be gentle and give sites the ability to choose” is a good approach, me thinks.
3 Likes
sounds good, I’ve reverted the component back to this original implementation
7 Likes
I think the “oh no 2 seconds passed, show a spinner” is definitely a minor but important thing to add
Except for that let’s see what people say, I think this is probably the version we will ship
8 Likes
Where should it display? As some kind of modal? Or should #main-outlet be hidden after 2s to make way for a spinner?
4 Likes
I am thinking we hide main outlet. We may want to tweak the threshold, 2 is a bit arbitrary, maybe 3,4,5?
6 Likes
The spinner will now be displayed after 2s:
12 Likes
That’s pretty neat, without the additional spinner layer after 2 sec things will get weird for users. This way we got best of both worlds, 1. Pretending to be lightning fast thanks to the slider (We’re cheating here TBO). 2. Filling the gap if loading stuck. (Psychological transition)
Well done! 
8 Likes
I just tried it on a simulated slow network, and the spinner after 2 seconds definitely feels good to me. I do want to reiterate that on desktop (on a large-ish monitor at least), the loading slider is basically nonexistent. I think another 2-3 pixels vertically would go a long way.
5 Likes
I have been following this conversation as I am a brand new user to Discourse. I have to say that I am very impressed with the level of thought and hard work that is going into this very “modern” UX feature. Sorry for going off topic here… but this is a very impressive conversation for someone that has been using other forum software for years.
Keep up the great work… love this feature.
11 Likes
Maybe I should mention that I just clicked a topic after already clicking it because I thought I misclicked, even though it was loading from the first click. Probably just need to get used to the lack of spinner though…
5 Likes