Add clear Apply and Cancel buttons to Link Control #46933
Conversation
|
Size Change: +84 B (0%) Total Size: 1.33 MB
ℹ️ View Unchanged
|
getdave
added
the
[Feature] Link Editing
getdave
requested review from
MaggieCabrera,
scruffian,
jasmussen,
SaxonF,
ajlende and
draganescu
|
Flaky tests detected in ee46cf2. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/3955139415
|
|
If anyone notices the misaligned labels on the control I fixed that in #46936 |
getdave
added
Needs Design Feedback
|
Just a quick take: I like the substrate of this PR and I agree with the problem it tries to solve, illustrated well in the 1st video. However I think the two buttons are just too much. The improvements seem to be more likely in:
|
|
FYI I've had an Issue up for while about this but didn't make much effort to get it traction. |
I'm no designer. However whatever route design suggests it needs to cover the scenarios outlined above. Currently everything relies on "discovering" how to do things. IMHO it should be clear without having to learn or undue cognitive load, even if that's at the expense of aesthetics. A critical point to note is that (in the future) I'm suggesting making all changes to links require the user to explicitly submit them. The key example is that I should be able to toggle the If you look at the code for how all the various implementations of "link creation" consume Standardising on "user must explicitly commit all changes to links" makes it a lot clearer.
Just noting that the x2 buttons only appear when editing. Here are some examples in the wild that use clear buttons:
IMHO a |
I think this sort of thing is not expected anymore for quite some time, because UX has more and more discarded apply in favor of easy undo. Apply should be for destructive or hard to undo things, like a sequence of updates where you can lose track of what you did. A toggle is on when you toggled it on in just about all places from system settings of OSes to browser settings and so on. |
|
I also appreciate the sentiment of this change and agree the link editing experience can feel a bit ambiguous. But I'm also not sure that the solution is as simple as universally adding these two buttons. One thing that works well at the moment is that clicking a search result is equivalent to an "Apply". It's a nice confirmatory action and it would be a shame to introduce any additional clicks there. Taking a step back, the problem seems to be that non-confirmatory closes of the link control do not feel predictable in terms of end result. IE if you click outside the popover there's no indication as to whether your changes were saved or not. This is particularly bad when editing a link because there's no visual feedback on the canvas. All that considered, an alternative idea to try:
Clicking a result (or pressing enter) is the only way to confirm a selection, doing so closes the link control. The Cancel button will cancel the addition of a new link, or discard any edits to an existing one. Consequently there are only two actions that can close the link control, and both feel predictable. Having typed that out I wonder if a popover is the correct pattern here, and whether a modal would work better. |
Agree.
I would think "Apply" and clicking on a result would both complete the same action.
It does add clarity, though clicking elsewhere to cancel/close a popover is a standard UX practice. If it's unfinished/unconfirmed, then it resets. What about if we add just the Apply button, and if one does not click "Apply", press "Enter" (which is how it works today), or click on one of the search results, then neither an initial link - or link edit - should save? |
My suggestion above is basically the opposite :) No "Cancel", but better confirmation via "Apply" (still keep the results, and enter flow). |
This comment was marked as duplicate.
This comment was marked as duplicate.
What would the flow to add a link look like? It seems to be:
In this case wouldn't the "Apply" button be redundant? For this to work I suppose the "Apply" button might only appear when editing an existing link. But still, if clicking a result is akin to clicking "Apply" then it still seems redundant 🤔
It is, but I think the problem here is that when you do so it's unclear whether the result is a Another idea: Adding a link works as it does now. Editing a link takes place in a modal. Very crude mockup:
|
You must have missed #46933 (comment) ? |
|
This one is quite complex. There are a number of different scenarios to consider other than just creating a new link. I will say that this PR does retain the existing functionality which is when you select an option it automatically selects that link (no need for However when editing a link or creating a link that's a URL (e.g. you type in Therefore I'd say the main changes to consider in this PR are really
Therefore the questions we need to consider are:
I appreciate this is a difficult problem so I appreciate everyone chipping in here to aid in improving the experience. It's badly needed for the reasons I've stated in the PR desc. |
|
I agree that we need different things when editing vs creating a new link. For example if I'm creating a new link as below, it's hard to imagine a situation when we'd ever need those buttons: However when editing a link the need is quite clear: I think this is also wrapped up in some of the changed being discussed at https://github.com/WordPress/gutenberg/pull/46891/files#top, where we also want to consider changing the experience for editing links, so a more thorough design exploration would be beneficial. |
Yes. I think it's fine. You're still confirming the action, either by clicking a result - or adding a custom url and applying it.
I'm thinking it should only be saved if you've taken action in the popover. I.e. You've applied a custom link, or selected a page via the results. |
|
This is one thing that annoys me about Gutenberg and other applications that work in similar ways. I do not want to guess if my action was committed or canceled, having a clearly defined set of buttons for this eliminates all mystery. I was never in favor of putting visuals above good UX. Where do we draw the line... I think this is a good path to go down and hopefully these common sense controls can be brought to other components. I'll A11Y review this when I have a moment. Thanks. |
getdave
force-pushed
the
add/clear-action-buttons-to-link-control
branch
from
e7b4e82 to
c900773
Compare
…pover doesn't reopen
| @@ -598,7 +579,7 @@ export default function NavigationLinkEdit( { | |||
| onClose={ () => setIsLinkOpen( false ) } | |||
| anchor={ popoverAnchor } | |||
| hasCreateSuggestion={ userCanCreate } | |||
| onRemove={ removeLink } | |||
| onRemove={ () => removeBlocks( clientId ) } | |||
There was a problem hiding this comment.
I don't think we should do this in this PR. It has knock on consequences. For example, it will not allow folks to add empty link items which I believe was functionality that was specifically requsted by users in the past.
The use case is that you might want to build out the structure of a Nav without necessarily adding links to each item.
With this change any nav link block that doesn't add a link using the initial Link UI popup will be removed.
Happy to consider this but I think it should be in a separate PR to avoid over burdening this PR 🙏
scruffian
force-pushed
the
add/clear-action-buttons-to-link-control
branch
from
d6acce6 to
ee46cf2
Compare
| @@ -68,6 +68,6 @@ exports[`Links should contain a label when it should open in a new tab 1`] = ` | |||
|
|
|||
| exports[`Links should contain a label when it should open in a new tab 2`] = ` | |||
| "<!-- wp:paragraph --> | |||
| <p>This is <a href=\\"http://wordpress.org\\">WordPress</a></p> | |||
| <p>This is <a href=\\"http://wordpress.org\\" target=\\"_blank\\" rel=\\"noreferrer noopener\\">WordPress</a></p> | |||
There was a problem hiding this comment.
I believe this snapshot has been invalid in trunk for a while. This is because the test sets open in new tab to it's active state which should result in the attributes being added to the HTML.
| @@ -235,6 +243,29 @@ function LinkControl( { | |||
| } | |||
| }; | |||
|
|
|||
| const resetInternalValues = () => { | |||
There was a problem hiding this comment.
Nit: do we need this function? Seems to be called once.
This reverts commit 875628f. # Conflicts: # packages/block-editor/src/components/link-control/index.js
* Revert "Move Link Control action buttons into lower area (#47309)" This reverts commit e605937. * Revert "Fix Link Control action button visuals (#47306)" This reverts commit 2499646. * Revert "Add clear Apply and Cancel buttons to Link Control (#46933)" This reverts commit 875628f. # Conflicts: # packages/block-editor/src/components/link-control/index.js
What?
Adds
ApplyandCancelbuttons to the<LinkControl>component.Affords the ability to explicitly cancel the creation or editing of the link.
Closes #46593
Why?
TLDR
There are a number of small UX issues with not having clear buttons to apply or cancel a link. Specifically there have been quite a few issues reporting around inconsistencies and bugs when submitting changes and UX confusion about how/when changes should be committed.
Examples
This PR is a first step in addressing these issues. See
Next Stepsfor followup ideas.Editing an existing link
When you have an existing link and you make changes to the text or URL it's not immediately obvious how to submit those changes. In fact you have to click on the very small icon button which is inside the URL input. Questions that might arrise:
By adding a clear
Applybutton it'sCancelling edits to an existing link
When you have an existing link and you make changes to the text or URL and then decide you don't want to commit those changes it's very unclear how to exit the editing process.
In fact you have to click outside of the component to close it. But that's not at all intuitive.
With a dedicated
Cancelbutton it is immediately clear how to exit the editing process and all ambiguity is removed.Cancelling the creation of a new link
When you are creating a new link and then decide that in fact you do not wish to do this it's not immediately clear how to exit the link creation process.
In fact you have to click outside of the component to close it. But that's not at all intuitive and can even lead to focus loss from the place where you were originally creating the link which is extremely frustrating.
With a dedicated
Cancelbutton it is immediately clear how to exit the editing process and all ambiguity is removed. Moreover your focus is returned back to where you were originally editing which avoids UX issues related to that.How?
Adds x2 new buttons
Apply- this replaces the icon-base submit button but displays all of the same behaviours and allows for submitting any current changes to the link value.Cancel- this is new and provides a clear means for the user to cancel editing or creation of links.Care has been taken to ensure that when cancelling an action any _un_committed edits to a link value are discarded.
Next Steps
If this PR lands then the next step would be to make changes to the link settings (e.g.
Open in new tab) to be explicitly committed by the user.Currently these controls require lots of custom code to handle when they should/shouldn't be committed and it's never resulted in a satisfactory UX.
We can greatly improve the UX simply by having a rule than any changes to the link value must be explicitly committed bu the user.
Testing Instructions
Manual testing
ApplyandCancelbuttonsCancel- see link creation is cancelled and focus returned to previous location.Cancel.Repeat the above with other locations where
LinkControlis used such as...etc
Automated testing
Review and then run the tests:
Testing Instructions for Keyboard
Repeat same tests as above but ensure that you can complete the tasks using the keyboard only.
Specifically check that the tab order of the Link Control allows for
Applyas the first tab stop (and thus the primary option) but also allows access toCancelas the secondary stop.Screenshots or screencast
Before
Screen.Capture.on.2023-01-06.at.10-51-27.mp4
After
Screen.Capture.on.2023-01-06.at.11-08-49.mp4