Submenu: Add revert button. #38203
Submenu: Add revert button. #38203
Conversation
getdave
added
[Type] Enhancement
getdave
added
[Block] Navigation
|
Size Change: +1.64 kB (0%) Total Size: 1.15 MB
ℹ️ View Unchanged
|
There was a problem hiding this comment.
I'm hesitant to enable this without showing a warning when there are items in the submenu. As it is, it's too easy to delete a whole submenu by clicking on a button with an icon that looks like a simple "undo" action.
Even if we show the text label, it might be confusing, particularly if "Open on click" is enabled (users might think they're just converting the top-level item back into a link instead of getting rid of the whole submenu).
|
I recognise the concerns expressed here. That said, we have a clear use case where users are being confused by the continued presence of a submenu block even when there are no submenu items. I'd really like to find a way to smooth out that path. I appreciate your help.
That's a fair point. Would adding a confirmation dialogue if there are sub items resolve this concern for you? If not is there anything else you can think of that would? |
I concur. If users leave the parent menu as having a submenu when none are present, website visitors would also be confused seeing the drop-down with no submenu items present. I am not the best yet with code, but the idea would be, if there is 1+, then show dropdown, else show standard link. |
|
Is it feasible to make deleting a block function as the users expect? That has the advantages of users not needing to learn another pattern for destructive actions. I think it'd also be generally useful as well to allow for blocks to provide an |
@TimothyBJacobs Would you be able to go into more detail about this?
It could also be that the button only appears when the submenu is empty so that there's less risk. I think there's also the possibility for more natural in-canvas options for add/remove submenus. Like a |
I think that's a good simple solution @talldan. Thank you for the clear insight.
I don't think it's possible at this time and, whilst I understand the motivation, I'm also not convinced it's something we should be doing. The delete action always performs the same behaviour across all blocks - removing the block. If we start making exceptions we could end up with a fragmented and confusing user experience. I would still vote for a clear button dedicated to this edge case (as per this PR). I'm going to refine the PR today to include some of the suggestions included here whilst avoiding any "magic" behaviour (i.e. things happening automatically based on assumptions about user intent). I hope you don't mind me adding a few of you as reviewers on the PR? I'll ping you when it's ready. Thanks again for all the feedback and input here. It's really productive and useful 🙇♂️ |
|
Ok @talldan @courtneyr-dev @TimothyBJacobs I've now changed the code so that the button only appears is there are no items in the submenu. That feels like a healthy compromise. I've updated the design to use the |
|
Random thought: what if instead of yet-another-button we move to do things preemptively:
On the PR in particular, the icon absolutely has to be changed. I do think that showin that button only when the submenu is empty is a great idea, but my suggestions above are an attempt at a more fluid experience. |
That's another option I'd not considered. More "hidden" though.
Some prior discussion on this here. There was no clear consensus but in general I dislike "magic" in UIs. Generally I prefer clear unambiguous controls that respond to user action. Automatically converting the submenu back to a link might also be a confusing experience, but I'm more than open to alternatives - I might even open a PR for comparison...perhaps that will be best!
I agree as I mentioned in the description 😄
Kudos to @talldan for that one.
I recognise this. I still have concerns about having things happen "by magic" but I'd like to explore this direction as well. |
This is no longer required
@adamziel I responded to that in this comment. Hopefully that explains my reasoning around at least trialing this more explicit approach as a first option. |
|
Assuming the e2e tests pass on CI I'm now seeking a technical ✅ on this PR. |
| @@ -529,6 +550,11 @@ export default function NavigationSubmenuEdit( { | |||
|
|
|||
| const ParentElement = openSubmenusOnClick ? 'button' : 'a'; | |||
|
|
|||
| function transformToLink() { | |||
There was a problem hiding this comment.
wrapping this in useCallback could help avoid some re-rendering
There was a problem hiding this comment.
Did you notice a performance problem here? If not I generally adhere to KCD.
|
It tests well, thank you @getdave! That being said, I have a UX concern: As a user I am confused why is the "revert" button sometimes not there. Could we always display it but make it inactive with an |
Good question but that's one I'd prefer to defer to an expert such as @javierarce.
Also one I'd appreciate @javierarce's opinion on. @adamziel are there any other examples of this pattern in Gutenberg right now? I can't think of one. |
|
@getdave I'm not sure! I'm just biased towards not hiding UI elements without an explanation – otherwise I find myself thinking wait, there was a feature here, hmm... I guess they removed it. |
I like @adamziel's idea. It will probably help reduce the frustration.
I don't remember examples that are identical… the closest thing could be these disabled buttons in the list toolbar.
|
|
Next step: add disabled button and update e2e tests. |
|
@javierarce @adamziel I've updated with the disabled state. If you're happy with the result (and the code) I'm seeking a ✅ |
Looks good to me! |
cbravobernal
changed the title
Description
In #36977 (comment) we learnt that some users want to be able to revert the submenu block to a standard link. The expectation was/is that deleting the submenu would restore the link but of course as the block is in fact a submenu block this just removes the entire block.
This PR seeks to implement one possible solution which is to show an explicit "Revert to Link" button in the block toolbar. This effectively just does the same thing as the block's built-in "Transform" option, but it makes it more explicit for this specific use case.
I'm no designer so this is just one idea for solving this case and we will also no doubt need a better icon choice.
Curious to hear from those more experienced with this block as well.
Also would love feedback from @courtneyr-dev who originally noticed the quirk and requested the change.
How has this been tested?
Screenshots
Screen.Capture.on.2022-01-31.at.10-57-20.mp4
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).