Template editor: only disable the save button if no changes rather than hiding it #47895
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
glendaviesnz
added
[Type] Bug
|
Size Change: +11.2 kB (+1%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in f4ebe92. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/4138536678
|
kevin940726
reviewed
Feb 9, 2023
|
You cannot hide the save button from the DOM completely. I can already hear the accessibility issues without even testing the PR. Consider disabling the button instead but not removing it from the DOM. Thanks. |
glendaviesnz
changed the title
glendaviesnz
changed the title
@alexstine I have redone the PR so that the button is always visible but disabled, so now behaves the same way as the Save buttons in the Post and Site editor. I thinks this also fixes the issue noted in #47882 as the button isn't now suddenly appearing for no reason. I have asked for some design feedback though as it feels like the placement isn't quite right if the button is permanently there. |
alexstine
approved these changes
Feb 10, 2023
There was a problem hiding this comment.
@glendaviesnz Code and accessibility look good. This is good to go pending design feedback.
kevin940726
approved these changes
Feb 10, 2023
There was a problem hiding this comment.
Same as @alexstine, code looks good, let's see if the design is ok too. 👍
|
I think this needs some design review as well. cc @jasmussen @jameskoster |
youknowriad
added
the
Backport to WP 6.7 Beta/RC
|
I'd like to ask to be added as a reviewer to all the PRs that target the site editor on going work. That would be appreciated. Thank you. |
|
When there are unsaved changes could we keep the disabled button in the DOM but visually hide it? |
|
@jameskoster This would be difficult considering the button would need to appear visually on focus. Generally disabled buttons cannot gain focus but we have made a work-around for our disabled buttons in Gutenberg. Just do not want it to be confusing if a user tabs to a disabled button and it suddenly appears visually. I am also still confused why the big thing in this project is hiding/showing things all the time. That would drive me nuts as a sighted person always looking for something that is not there because I did not complete some pre-condition. Just my take, thanks. |
It's definitely a fine balance... the site editor is fairly advanced and exposing all the tools all the time can be overwhelming. I don't think it's unhealthy to consider disclosing certain parts of the UI contextually. That said, saving is a very established and familiar concept, so it's probably okay to display it permanently, even when disabled. This would open the door for us to include related affordances here (e.g. access to revisions) in the future as well. |
@jameskoster should we go ahead and merge this then? |
aristath
approved these changes
Feb 14, 2023
|
@glendaviesnz would you this more bug or more enhancement? I'm working on prepping labels for the changelog before tomorrow's RC. Both labels are applied at present. |
ntsekouras
added
[Focus] Accessibility (a11y)
|
@DaisyOlsen I took the liberty to classify it as a11y bug fix 😄 |
|
I just cherry-picked this PR to the wp/6.2 branch to get it included in the next release: 36dcb00 |
ntsekouras
removed
the
Backport to WP 6.7 Beta/RC
|
I don't think this is a great solution. The save button (at this higher level of the interface) is an affordance only relevant for when a user is making changes across templates, styles, navigation, and so forth. Displaying it so prominently all the time is a considerable distraction and potentially misleading (a single disabled big blue button can be mistaken as active, and draw attention to it). This item is meant to contextually explain what is going on, and it's failing to do that at the moment. If we need to define a permanent area to contain it we should explore other alternatives, like a collapsed panel when there is nothing to be saved, auto-expanded when there is, and always focusable. Alternatively, the disabled state should not be that of a primary button in this context, it could instead read when the last saved happened, with access to revisions, etc. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
Makes the save button always visible, but disabled if no changes, rather than hiding it.
Why?
There are accessibility issues with adding and removing the save button from the DOM, and this change makes it behave the same as the Save buttons in the Site and Post editor.
Also, currently the buttons saving state suddenly shows when saves have been initiated from other places, eg. the template rename dialog - this change avoids this confusion.
Fixes: #47882
How?
Always shows the button rather than only for an isDirty state.
Testing Instructions
Screenshots or screencast
Before:
save-before-2.mov
After:
save-after-2.mov
After with template change save:
after-save-3.mov