Navigation: Add delete nav menu button #35981
Conversation
talldan
added
[Type] Enhancement
|
Size Change: +271 B (0%) Total Size: 1.08 MB
ℹ️ View Unchanged
|
|
|
talldan
force-pushed
the
add/delete-nav-menu-button-to-nav-block
branch
from
92a4d3e to
25199fa
Compare
talldan
force-pushed
the
add/delete-nav-menu-button-to-nav-block
branch
from
25199fa to
7bebfcd
Compare
talldan
force-pushed
the
add/delete-nav-menu-button-to-nav-block
branch
from
7bebfcd to
718c855
Compare
|
The issue with the entity saving process has a temporary fix now, so this is ready for review. It would be good to get in for 5.9. |
|
Thank you for the PR. The ability to delete an automatically or manually created menu is nice: I do have some concern about the prominence of the panel, and saving feature itself. I had hoped that changing the storage system would have no visible effect on the user experience. The balance to find here is tricky. If we autosave menus as your other PR does, it eliminates a big point of friction to using the block and gets us closer to the "no visible effect" experience, but there would still be a proliferation of patterns. Adding a delete button would give a way to manage that, but the less we'd need to manage, the better. One solution idea of managing prominence could be to put a delete button directly in the menu selection dropdown, appearing when hovering a non-selected navigation: Another option is to restore the CPT management screen and add a link as we do for Reusable blocks: |
|
@jasmussen There's an issue for restoring the admin page, but it isn't straightforward (#36036). If that doesn't land, users will need a way to delete menus. I did wonder about a separate modal for managing menus as another idea.
I don't think this would be accessible. Using the keyboard, this menu would need to work as a grid, which unfortunately breaks the accessible menu concept. Any other thoughts? I don't a huge amount of time to iterate on this, so the simpler solutions are better. Could we lower the prominence of the button somehow? |
|
I think it's unfortunate that the inspector panel pushes down the visual appearance controls that are so important for the navigation block. I think a tool to delete menus might get buried if put under the "Advanced" collapsed-by-default panel, and my best other instinct, as noted, would be to have an item in the ellipsis menu next to Reusable blocks. If that needs to open a modal, perhaps that's a way forward. I know you feel these mockups might be a mouthful, but part of what they do by embracing the multi entity saving flow is to both reduce the weight of having to think about saving, but also in doing it only when you're done with the page, minimizing the potential proliferation of saved menus, reducing the need to delete them. Is there anything we can do to simplify that flow, but keep the principle the same? The placeholder plus selection dropdown is already in a good place per Isabels fast work, we don't need the snackbar, we can omit the "Unsaved" button from the toolbar until the menu has been saved, and we don't need the ability to rename menus in the multi entity saving flow. In my mind that means all that's left is to remove the modal to name the menu, and have the saving happen only as part of the multi entity saving step. Do you think that would be feasible? |
I'd be concerned 'Advanced' is too buried. Do you have the same feeling about the 'menu name' part of the panel Maybe we need a more concise version of the whole thing that doesn't push the other options down so far. Something like this? Screenshot isn't this clear, but this would be a row in the inspector underneath the block details. The icon on the right could open a dropdown that would have 'rename' and 'delete' options. To be honest, some of these smaller details have been hard to focus on while we're changing the big picture. But if we can come up with feasible suggestions for them in the extremely limited time we have, there's no reason we can't improve them. |
I keep coming back to the solution existing in the existing save buttons: As someone using the block editor, I shouldn't have to worry about my content being saved, or even about multiple different ways to save things. This is ideally complexity we handle for you. And so embracing that existing flow seems like it should be able to reduce the work we have on our table. |
|
I don't really understand how saving helps a user delete a menu? |
|
Saving only once when you're done editing the page means you end up with fewer overall, reducing the urgency for a delete button, at the very least it reduces the need for it to be so prominent. |
Right, but it doesn't seem like it removes the need. |
|
No no, but it means it might be fine to make it a tiny button at the end of the menu, maybe?
|
|
My feeling is that renaming and deleting a menu aren't actions that are only for advanced users. They are, whether we like it or not, something many users will want/need to do. For example, people make typos. Or they accidentally create something and then realise they don't need it. Maybe we don't quite give the features the priority they have right now, but I do think they need to be accessible, not too hidden away. |
There was a problem hiding this comment.
The way I see it is that we're working on new foundational features without a UX designed. So we approximate. And when we approximate we get feedback as complex flows that reroute all work to new horizons instead of allowing us to make the next step. That means we can postpone the realisation of these designs to future iterations. Future iterations thay may very well be next week ;D
This is how the entire project moves, I don't see how this particular thing has to be different.
In this case, we can't work with independent menus that can't be deleted. Hopefully once the editing in isolation will crystalize the need to delete from the block will vanish or will be moveable to a secondary place. For now adding a button is a good stepping stone allowing us to figure out the lay of the land in the UX of managing reusable menus.
Maybe in the end we realise that the block theme system doesn't encuorage users to create useles superfluous menus, because of the direct manipulation UX. Then also the delete can be relegated to some accordion at the end of the inspector. But we don't know.
I'd go ahead with this PR so we can have something to move around later but also something to work with now.
|
I'll merge this one. If there's an alternative design that's relatively quick to achieve and doesn't hide the feature away too much, then I'm happy to look at it. |
andrewserong
changed the title
Description
Adds a button for deleting 'wp_navigation' posts to the nav block's block inspector:
Deleting has a confirm step:
There's a bug in the multi-entity saving flow that needs to be shipped, preferably before this is shipped. When deleting an entity, it shows in the saving panel as an 'undefined' change 😬 :
This should preferably be filtered out, deleting entities is immediate and doesn't need to be saved.
How has this been tested?
Types of changes
New feature (non-breaking change which adds functionality)
Checklist:
*.native.jsfiles for terms that need renaming or removal).