Add a progress bar

Yup, that that was the plan.

I suppose a progress bar would work... Personally, I think that might be too old school and not very open to customization?

I would love to see the entire parent div that is being rendered, should go to a dark color (if the theme is light) and fade back to the normal theme color. For example: flash dark gray -> fade to white This is just one idea and I think CSS3 could tackle it without a problem.

Unfortunately, Drupal doesn't have very good APIs setup for cohesive UX. There is a lot of talk about adding a JS framework to speed things up and make the UX better, but a JS framework doesn't make for good UX, a good UX allows for an effective JS framework.

Point is, "Something Happened". The more we move towards server and client side JS approaches, the more need there is for excellent UX improvements that show exactly what happened. I see why Google did what they did on Android with Material Design.

Unfortunately, until the upper folks of Drupal realize that UX needs to happen from the top down, we're left with individual modules handling the UX.

It works fine for Turbolinks, Basecamp and GitHub. Also, you only see it doesn't load within a low number of milliseconds.

Finally, this is not the place for such broad rants. Please stay on topic.

By the way, if you want to contribute to Drupal UX, see the @DrupalUX Twitter account or https://groups.drupal.org/usability.

Also, you only see it doesn't load within a low number of milliseconds.

All the more reason to use a different approach to "something happened". A progress bar would be fine if it takes longer than a few hundred ms, but the times when it takes 10 ms and the page flashes so fast, the eyes can't see the changes, that is where the problem lies. When content is similar among pages, it can become extremely difficult to distinguish when the change happens. The smaller the area being changed, the more difficult it is for the eyes to capture it. What happens if the area changing, happens below the fold? Since the page isn't reloading, there will be no other indicators to the user that "something happened". Point is, the user may never see the change and end up clicking on the button or link for 5 seconds before realizing, "Oh, it DID change... When did it finally change??" This leads the user to feeling either frustrated or foolish. I know, because I've been on sites that use a similar JS method with zero UX queues which is why I'm bringing it up.

If half a page container changes, it is probably a pretty good indicator but when smaller sets of information change and the rest of it doesn't, it becomes a lot more difficult to decipher that something just happened. You also can't expect the users eyes to be trained on the area that IS changing. If they click on the button and the area changing is striclty in their peripheral, they may never see the change. You also have to take into consideration ADA folks, or (old) people who have a hard time seeing to begin with. That's why I say to flash the entire container that is being changed. If you want a loose example, take a look at a custom pure JS calculator I had someone build for me: https://www.asphaltsealcoatingdirect.com/products/big-a-alligator-asphal... The UI of the calculator is to be desired, but the UX gets the job done.

As far as my rant goes, all I'm saying is that it is unfortunate that Drupal doesn't have a UX plan in place already. As a result, it means a random choice has to be made for this specific module to handle UX in it's own unique way. This ultimately means there is a lack of UX cohesion among the ecosystem of Drupal as it gravitates towards JS environments and implementations, leaving each and every maintainer to come up with their own way of dealing with "Something (did|will) Happen".

I see a lot of low hanging fruit being tackled in the usability group and in the issue queue of D8/D9, but the topic hasn't gained the authority it requires to properly fix the problems from the ground up. I have the passion, but lack the authority and technical knowledge to get the topic properly motivated. I'll keep an eye on those locations though.

I just hope you can see that a progress bar will potentially only cover a portion of the use cases. I think a bit more creativity will need to come from this topic to really make the UX pop.

Thanks, that was a much more constructive and helpful comment. I appreciate you taking the time to write that up.

Of course, I agree with your overall premise.

But for this particular issue, I am not yet convinced, because animations must last longer than 10s of ms to be noticed by users and to be helpful, too fast animations are annoying. But too slow is annoying too. We'll have to experiment, and figure out what works. Drupal has basically 0 animations (motion) at this point, which makes this extra difficult.

Perhaps this module can be the testbed for the Drupal usability folks to bring motion to Drupal, to define best practices.

Thanks again! :)

I agree this topic will be difficult to implement well... One problem to overcome will be slower, older devices that have a hard time dealing with animations due to graphic limitations.

There are a lot of ways to accomplish it such as change color and fade, fade and slide in, shake the container etc but finding the option with the right balance of fluidity and performance while still being eye grabbing will be the difficult part.

Like @almaudoh suggested, an overlay might be the best solution though I'm not sure if a mouse over is the right approach. The simplist solution might be an overlay that blanks the entire page white as if there was a full page reload which has been the global queue for several decades and folks are used to it. Quick and dirty, but not overly elegant. It's a thought though.

@Wim Leers it would be fantastic if the UX team used this module as a test bed. Ultimately I would love to see a suite of APIs within core that handle UX issues such as this. BigPipe is another rendering mechanism that might be able to benefit from this topic.

So, it sounds to me like there needs to be two different solutions.

1) slower than normal indicator
2) page has loaded indicator

1 will only trigger if the load time is over a certain time frame and 2 will "always" happen. With that said, it might be worth implementing an override for the rare cases where the site builder doesn't want #2 happening on a particular page or set of pages. (The changes are so obvious that an indicator is just an added distraction)

Just some more food for thought.

I've been looking at this issue, as a path forward for Drupal core. My role is primarily in shaping Drupal core UX, occasionally I find myself in contrib that is finding new ways that could be incorporated.

Micro interactions such as this play a vital role in creating a pleasurable user experience, it is indeed hard to notice but that should be on purpose. Most users should not be effected by this, as the page loads quickly enough. However for all those who don't, this will provide a small cue and will find usefulness in this. The group that is effected by this is huge, slow loading times are incredibly common in many communities. As Wim Leers correctly points out, its become an industry standard across many very timely and usable applications.

I prefer to star this with a proven pattern (e.g. Github's). Let's not confuse, contrib which should be a testbed for core and the larger UX plans. For this please post your thoughts in the usability group.

Let's do it! Looking forward to see an initial experiment.

Here's a suggestion that might resolve both issues (indicating regions that have changed, and providing immediate feedback on click):
fade out then fade in.

On click, start a fade out that takes 0.5 second to complete
if the new content has not arrived by the end of that time, keep the region blank.
After the content arrives, blank the region (if not already) and then fade in over 0.5 seconds.

That sounds very, very annoying TBH.

Some thoughts on this...

One thing with D8 that has always bugged me is how the toolbar "jumps around" on page load. I haven't pinpointed exactly why it does it, but IMO, it's really annoying. I made a comment about this in a G+ group and Chris Weber made the comment that "It doesn't happen with Refreshless". Unfortunately, that's only half true. The toolbar stays static on the front facing theme, but it still jumps around on the admin side which makes me wonder if refreshless is working on the admin facing theme? (I've brought this up in the past and if memory serves, it's supposed to work... beside the point)

This brings me back on topic of a progress bar because doing the testing on it got me thinking and I believe there are two points where this needs to be addressed:

1) Page is at the very top and a link is clicked that will keep the next page at the very top
2) Page is slow to load new content

This means we ideally need two loading indicators of "Something happened" and(or) "Something is happening".

When a page is at the very top, clicking a menu link makes it hard to distinguish that something happened. If the page is scrolled down lower, say half way down, the page jumps back up to the very top which is probably fine for an indicator that "something happened". But what about when you're at the very top? I think this is the most crucial area that will need a "Something happened" indicator because the very top of the page is usually where the majority of static content resides (logo, site name, toolbar etc.) and anything that is not static within the above the fold area will be difficult to see change unless you're looking for it.

So, while thinking about this topic, we probably need to not only address the slower loading content issue, but also the scenario when a person is at the very top of the page and a link is clicked within that area that will keep the page at the very top. One thought is to use the toolbar as a loading progress indicator (contrast of color increasing from left to right, flashes when finished, etc) but this doesn't take non-authenticated users into account and to be quite honest, I have no idea what to suggest there. Maybe a 5px-ish tall x 100% width loading bar at the very top of the page that can be easily themed with different contrasts? On that, I just don't know. This approach might work fine if Refreshless gets moved into core and people just know when they enable it: "It has a loading indicator at the top of the page that can be themed".

I know this isn't a hot topic and I don't expect it to be, but hopefully these are a few more things to think about if this does gain some traction at a later date.

Thanks for taking the time to write up your thoughts — it's much appreciated!

Unfortunately, that's only half true. The toolbar stays static on the front facing theme, but it still jumps around on the admin side which makes me wonder if refreshless is working on the admin facing theme?

It only "jumps" when switching themes, because that's when RefreshLess doesn't work: it can't work across themes. When you switch themes, a full reload is necessary. As long as you stay within the admin theme, RefreshLess works.

When a page is at the very top, clicking a menu link makes it hard to distinguish that something happened.

Sorry, but this makes no sense to me. Already today, if the next page is pre-rendered, browsers behave this way. There's no special indicators. There's only the browser's progress bar that flashes briefly.
You can see this yourself by going to a site that's either very fast (try wimleers.com) or by going to any site and using the backward/forward buttons.

It only "jumps" when switching themes, because that's when RefreshLess doesn't work: it can't work across themes. When you switch themes, a full reload is necessary. As long as you stay within the admin theme, RefreshLess works.

Not from my experience. Once on the admin theme and changing pages within the admin theme, the menu jumps around, regardless of the admin page. Off topic though, so if it's an issue, we can get one going in another thread.

Sorry, but this makes no sense to me. Already today, if the next page is pre-rendered, browsers behave this way. There's no special indicators. There's only the browser's progress bar that flashes briefly.
You can see this yourself by going to a site that's either very fast (try wimleers.com) or by going to any site and using the backward/forward buttons.

Ok... I guess the question is: "Do we want to leave it upto the individual browsers to denote that something happened?" Before caching ever really became a thing, the page would blank to white and then load the next page. On slower sites, this is still the behavior but obviously with caching mechanisms and what-not, this is becoming far more seamless.

I guess when I think about this issue, I look at what Google has done with Material Design for Android (Dunno how much that carries over to the web), but with Material Design for android, everything you do has some sort of visual to either tell you that something did happen, is happening or is going to happen. I hate to say they broke the mold, or raised the bar, but I feel like "It's the right way to do it". An element of design that flows and makes sense visually with everything you do. I dunno. I just see it being an issue if 95% of the elements on a page don't change, and that 5% that does, is just barely above the fold.

Great discussions, but this issue is about a feature request, we can debate its merit forever.

It seems the maintainer agrees, this is contrib - so lets do it! If you don't want it, just disable it - should be easily doable :)

#15:

Not from my experience. Once on the admin theme and changing pages within the admin theme, the menu jumps around, regardless of the admin page. Off topic though, so if it's an issue, we can get one going in another thread.

I can't reproduce this, or at least I know this used to work. Can you open a new issue, post steps to reproduce, and perhaps include a little screencast (no audio necessary, just video).

Before caching ever really became a thing, the page would blank to white and then load the next page.

And that is terrible.

this is becoming far more seamless.

And that is great.

I guess when I think about this issue, I look at what Google has done with Material Design for Android

That's not how the web works. One could add page transition animations for sure. But that's not something for RefreshLess to design, it's something for Drupal core or a particular theme. Because, like I said, for well-performing web sites, this very same problem already exists.

So, what you're asking, is out of scope for this issue. Please open a new issue called something like Add page transition animations.

#16: Indeed I agree! But I disagree with the page transition animation aspect, so per the above, I'm pushing that to a separate issue, so that issue can remain focused.

it's something for Drupal core or a particular theme. Because, like I said, for well-performing web sites, this very same problem already exists.

I bring this up in the contrib, because enhancements gain faster popularity through contrib, than core. There are too many fingers in the pie when it comes to core and decisions take a while to hash out and mature. If a contrib can show people what is possible, the chances of it garnering cores attention becomes much better.

That said, I won't argue the page animation merits any longer. I will note, that great caching with bad UI, can still create a horrible UX. This can be experienced on countless websites that load content before images or dynamic content without wire framing the stuff that loads later. It's great that the content shows up within 1.5 seconds, but the user still has to wait 10 seconds for everything else to load because if they don't, the content jumps out of view and the user has to scroll back to it. 10 seconds of that, is very frustrating. (primarily talking mobile, but I've seen it on desktop as well). The caching guys say the themers should fix this, the themers are clueless and don't even realize they should fix it, or push it back to the backend cache guys, so it never ends up getting fixed by anyone. Point is, UX should still be considered when dealing with how the cache loads. Guess I'm just trying to point out caching UX might need a little more thought put into it than just making the page load quick.

I like the idea of @ztl8702 in #19, it would be great if we have same callbacks.

We could postpone this issue (progressbar), and start on #2767767: Extensibility via Events or "hooks"/callbacks.
If we get that in, developers / themers can create whatever they like.
Then we can propose, for example, a sub module in this issue that adds a 'generic' progress bar.

The main goal for 2.x is #3238865: META: Incorporate Symfony UX Turbo Into Module which uses the Hotwire Turbo library under the hood; one of the many benefits of using Turbo is that it provides a basic progress bar if the request takes longer than a certain amount of time (500ms or half a second by default). It also provides an API for more complex UX to be layered on top.

Marking this as fixed because we now have Hotwire Turbo working in 2.x (see #3393105: Hotwire Turbo minimum viable implementation) and it provides this sort of progress bar.