'Force page reload' setting is confusing #63599
Comments
jameskoster
added
[Type] Enhancement
|
Generally speaking the circumstances in which a user would actively want to enable this option are extremely rare. For that reason alone we might consider moving it to the 'Advanced' panel. The language might be refine like so: 
cc @WordPress/gutenberg-design |
What are those circumstances? |
|
The option is enabled by default, it is not clear to me if you meant that the default behavior should be the on page pagination, or if you meant that enabling the on page pagination is rare. |
I don't know, to be honest. @carolinan I'm saying the copy associated with the control doesn't describe what it does very well, leading to confusion. Also that it's rare that you'd want to enable it in the first place. Moving it to the Advanced panel would reduce visibility. A more aggressive approach would be to hide the control from the UI altogether. |
|
That's the confusion, the toggle is enabled by default. So you mean that toggling it off would be rare? |
No haha, it's the other way around. When it's toggled on the full page is reloaded, which isn't something I can ever see a user wanting to do. So toggling on would be rare, and it should 100% be toggled off by default. |
|
To me, saying that "the label and help text is confusing" and changing the default behavior of how links work are two separate issues.
|
|
I agree, but it's not clear to me what the default behavior is. It would be good to clarify that definitively. In my local environment it's toggled off when I insert a Query Loop, which is what I'd expect. It gets toggled on only when there are incompatible blocks in the Query Loop. Rich's question is a good one though. Regardless of what the default is, when would a user ever want full page reloads? If the answer is never then maybe the setting can be hidden from the UI. |
|
I have never seen it toggled off by default. Not even on a fresh WP install that only has the Hello World post and I insert a query, choosing the "start blank" option with only a title and excerpt. Blocks that should not prevent the option from being changed. When the option can not be changed, when it can't be toggled off because there are non-compatible blocks, the toggle is disabled and this message shows: |
|
I just tested on a fresh https://playground.wordpress.net/ site and you're right, the option is toggled on by default there. I wonder why that's not the case in my local environment. I don't see a good reason for this to be toggled on by default, do you? Making off the default state, moving the control to the Advanced panel (to reduce visibility), and tweaking the copy still feel like good changes imo. |
|
I wonder if it could be specific to Playground? Maybe there are constraints around the Interactivity API and how it needs a specific site setup. Maybe it isn't compatible with Playground's local setup? Feel free to disregard this suggestion, but maybe there's some nuance we're missing. If that isn't the case, I can't think of a reason we'd turn the toggle on unless there are incompatible plugins and/or features. Interactivity API is the future and we should default most sites to it. |
|
I'd totally support some drastic simplification of the help text for this setting. See #63598 (comment) |
|
I understand the problem with the text, but not the problem with keeping the default as the "force page reload" which is the default behavior for links when not enhanced with the JavaScript. I would like to ping @SantosGuillamot and @DAreRodz to help us sort any remaining questions about |
|
@carolinan paginating without reloading the page is the superior experience, so that should be the default (when possible) imo. |
And it auto opts out as well, correct? |
|
@jameskoster The message "Experimental full-page client-side navigation setting enabled." you shared in the image should only be visible when the "Enable full page client-side navigation" Gutenberg experiment is activated. That could be why you are seeing it disabled as default while the normal experience is having it enabled by default. Regarding why the "pagination reloading the page" is the default experience, I believe it was decided that way because not-reloading gets disabled when non-compatible blocks are included, being the Post Content one of them. But @luisherranz or @DAreRodz will know better than me. Having said that, this setting seems tricky and I agree it needs some discussion. |
|
Are there blockers preventing the experiment from being stabilized? (other than contributors time) |
There are some challenges that need to be addressed before it can be considered stable. There is a tracking issue specific to this experiment where the issues are listed and progress will be shared. |
Yes, when "Force page reload" is disabled (which means that this "enhanced pagination" is active), we are checking for incompatible blocks on each render. If we find one, the enhanced pagination is deactivated. We are also checking for incompatible blocks every time the user opens the Editor, as there might not have been one when the template was saved but now one could appear because it is inside a pattern that was edited elsewhere. If that happens, we reactivate the "Force page reload" option and show a modal to the user.
There's still a lot of work to be done on that front, and I don't think we'll have anything stable for at least a couple of cycles, so as of today, I wouldn't expect it before WP 6.9 or WP 7.0.
It was decided to keep this "enhanced pagination" disabled by default because it is actually a very new functionality and we were not sure if there would be conflicts on certain sites where it might not work well. So, as a precaution, it was decided that the user should manually enable it. In the future, once it is considered stable and robust enough, we could try enabling it by default. I don't know if, after two major versions, there has been enough time for people to test it and report issues (nobody has reported any problems yet as far as I know). |
|
I agree with the suggestion to move it to the advanced panel, but I think that would also mean less testing, which may not be what is needed. |
I'm sorry but this sound to me as a very bold statement. It may be perceived by some users as a better experience, but it for other users it may be a worst experience. This kinf of statements should be avoided in a project with millions of users who have all different needs and different levels of ability. Also, I would like to see this kinf of statements based on actual data and user testing. Otehrwise, with no data, they're only baseed on personal opinions, perception, and preferences. I would liek to remind everyone that the non-reloading pagination is non-standard, it introduces problems that need to be addressed to replicate all the feature of a standard pagination and, more importantly, could be non accessible for some users. For this reason, I think the default should be the standard pagination because the WordPress defaults should be the most accessible ones. Cc @joedolson |
I am not going to get into the discussion of whether it's a superior experience, but if there are any accessibility issues, we should resolve them. This experience should be as accessible, if not more, than reloading the full page. |
It is important to understand that it can't, because it's not standard. There will always be users or assistive technologies that will suffer from this model of page content 'updating'. There are no specifications or standards that define this model. As such, other software, for example assistive technologies or search engine crawlers, can't be fully compatible because there's no standard they can take into consideration. Also, there are important SEO concerns with this model of page updating. I'd leave this to the SEO experts but it's something that should be taken in serious consideration. For these reasons:
|
|
I'd agree that the assertion that pagination without a page reload is somehow "better" - it certainly isn't better for all users. It is certainly less predictable than a page reload. I do want to emphasize that the way the Query Loop pagination works is accessible - it has most of the the essential pieces of an accessible interaction; but there's an important distinction between "meets standards" and "is a good and predictable user experience." The specific problem is that there is no standard pattern for pagination without a page reload. This means that there are no semantics we can communicate to users that will inform them how they should expect this to work. Because the controls are still links in a Tabpanels, dialogs, navigation menus - these are all standardized interaction models. There is a "right" way to do them, and because of that, we can do them well and communicate clear expectations to a user. JS-driven Pagination doesn't have a standardized model. There are a few things we could do to create hints; like change the controls from links to buttons when this mode is enabled, but there isn't a standard experience. Which isn't to say that there shouldn't be a standard pattern for this - it's a pretty major gap in standards, but it still remains the case that it doesn't exist. |
That statement is false. There's no issue with SEO because the HTML that search engines see is exactly the same with or without this option.
Links navigate to a different page. That doesn't change, we are still navigating to a different page, but faster and without losing the user's context and focus. |
This should be investigated more in depth before stating it's not an issue. I would like to recommend everyone to have a less assertive attitude and a little more open-mindedness towards observations that are reasonable to take into consideration. I said there are important SEO concerns. It's not a statament, it's reporting concerns. Some of them are clearly valid concerns. Examples:
I'm not an SEO expert but to me these concerns are valid and I'd like to see them be tested and considered by SEO experts. Still, I don't think this feature is should be communicated as a 'superior experience' because that's an extremely biased statement that WordPress shouldn't make, |
From an usability perspective, this is arguable. The fact the page doesn't scroll and focus stays on the clicked link does make users lose context and focus. In certain conditions, users may not ever notice the page content has updated. |
That was fixed in this pull request (before the feature was initially released in WP 6.4): I've updated the issue. It seems to me that you don't quite understand how search engine crawlers work yet, because, even though that was fixed, not updating the title on client-side navigation doesn't affect SEO. Crawlers fetch the HTML of the pages and analyze it, but they do not navigate using JavaScript. When they see links, they add that URL to their list and fetch the new page again. Since the HTML doesn't change when the enhanced pagination is active, for search engines, there is no difference between a WordPress site with enhanced pagination and a site without it. So, to answer your concerns:
The enhanced pagination updates the document title to whatever is on the new page's
The enhanced pagination updates the document title to whatever is on the new page's
As you say, this is not an issue of the enhanced pagination but of the Query Loop block with non-inherited queries.
Nothing. The HTML is exactly the same with or without enhanced pagination, and that's what crawlers inspect.
Nothing. The HTML is exactly the same with or without enhanced pagination, and that's what crawlers inspect. |
I'm sorry but that's not what happens. After a client-side navigation, we move the focus to the first post of the new page (which makes the page scroll to that position if it's not in the viewport) and we announce the navigation. If that is not the ideal behavior, we can modify it. |
|
I think we're getting a bit off topic here. The accessibility of the query loop navigation is pretty good; that's not at issue. It's pretty good within the scope that it's a non-standard interaction that has no standardized model, so it creates an unexpected behavior. As a result, the question here is challenging the assumption that
We'd also like to improve the text (per the original purpose of this issue), to make it clearer to users what will change, and to avoid any implication that one choice is better than the other. One question: is this default something that can be controlled via |
|
It can not be controlled via theme.json yet. Here is a link to the issue: #57623. |
Yes, let's concentrate on that here, everything else is clearly a bigger discussion. How do we feel about |
+1. I think the proposal at the top of this issue makes this setting a lot clearer:
Commas, em-dashes, or parentheses might further aid readability?
A few alts for coverage, but I'm not convinced they improve on the original solution:
One more thought—it's always a bit of a toss-up between concision and providing a rationale as to why someone would want to take a specific action. Is there a pithy, universal reason we could cite? It sounds like it’s primarily to resolve certain block compatibility issues? Even something as simple as one of these could help the user make a decision, but I appreciate that there are tooltips and documentation that might be a better option:
|
|
We can probably finesse the help text in a PR. I think the main thing is to update the label. |
jameskoster
added
Needs Dev
Any reason why we shouldn't do this as a first step? |
If the goal is to first have more people using and testing it, hiding it may do the opposite. |
|
First step can be updating the label, as suggested here. A next step can be moving it to the Advanced panel. Whether that's a good idea or not, isn't clear to me; it resonates because it's probably not a setting you need to change that often. And yet it the main feedback has been the lack of clarity of labels. |
@luisherranz that is just incorrect. You may want to read the basics of how JavaScript SEO works in this article on Google Search Central. I'll skip over any comments about individual skills because I don't think they contribute positively to the collaboration on this project but I have to say that I didn't particularly appreciate your language and tone in your previous comment. Thanks. Understand the JavaScript SEO basics |
|
@afercia, you are confusing client-side navigation of server-side rendered HTML (what WordPress with the Interactivity API can do) with pure client-side rendering (what single-page applications without support for server-side rendering do). Would you like to move our conversation to a separate discussion to avoid interrupting the main discussion on this issue? |
github-actions
bot
added
the
[Status] In Progress
I will ask the SEO specialists in the company I work for to better evaluate potential impact of this feature before creating a new issue. Thanks. |
The label and help text for this setting do a poor job of describing exactly what it does.
The text was updated successfully, but these errors were encountered: