Pattern Editing: Display link controls for nav links and submenus in the Inspector Content Tab#75042
Closed
Pattern Editing: Display link controls for nav links and submenus in the Inspector Content Tab#75042
Conversation
talldan
added
[Type] Bug
4 tasks
|
Size Change: +220 B (+0.01%) Total Size: 3 MB
ℹ️ View Unchanged
|
Member
|
Thanks for looking into this, @talldan. I've also been looking into #74895 recently and was exploring something similar to this as a possible solution. I think it's worth exploring if this placement for these settings is intuitive to users. I'm thinking that it may make more sense to expose the settings from the List View. For example, adding an "Edit menu item" link to the options menu for each item in the List View. It's probably worth getting some design feedback here, cc @fcoveram as you've been helping out with Nav work. |
Contributor
In general I agree that we need to modify the existing behaviour of the Editable List View in order that we can access inspector controls of Navigation Items. Why? Because we've identified (via User Testing) that the ELV is an important piece of UI that should be default when selecting Navigation - even in "simplified editing" mode.
Given that it's crucial for users to be able to perceive the status of a given link and also amend it easily we should try and expose this without the need to discover a niche piece of UI. The original behaviour of click to see block settings seems the most obvious and logical given that there's little/no value in having it select the block in the canvas. |
Member
I was looking into a new item for the Options menu because that's an existing piece of UI in the List View, but are you saying that it would be better if users could just click the menu item itself, and this would expose the inspector controls? And then if they specifically click the Options menu, that's when this menu is exposed (as it is currently)? 
|
getdave
reviewed
Jan 29, 2026
Contributor
getdave
left a comment
getdave
left a comment
There was a problem hiding this comment.
Thanks for exploring this Dan 🙇
I tried to check it out and get it working locally but I'm having trouble making it work. I think my environment might be broken - working around that for now.
Overall I think my principle concern with surfacing the controls like this is that it (appears to) require the user to utilise the canvas to trigger the controls for each block.
Ideally we'd just show the List View for Navigation because that UI has been shown to be more effective than the canvas for editing menus. As you mention that is being tackled elsewhere but I wonder whether those changes will mean this approach isn't as useful?
I'm definitely curious to hear your perspective on this.
talldan
force-pushed
the
try/showing-nav-link-content-controls-in-content-only
branch
from
082e40c to
9733296
Compare
github-actions
bot
added
[Package] Editor
…if it has support
Contributor
Author
|
I tried a few extra things here (sorry, the video isn't great): Kapture.2026-01-30.at.16.39.21.mp4The short summary is:
It feels ok, but think there are still improvements. There's no back button to the list view from the controls when a nav link is selected. No focus management. Also, I feel like it might be better if the tab selection is inferred based on the block selected, rather than a procedural |
talldan
requested review from
MaggieCabrera,
andrewserong,
mikachan,
sarahmonster and
scruffian
and removed request for
sarahmonster
Contributor
|
@talldan Thanks for iterating on this. It's looking a lot better and it aligns much better with what we've been envisioning for Navigation.
This is great. Taking you to a context where you immediately edit is absolutely key to the experience.
Again I think this is very important. Action -> Intent mapping is strong. Marries well with wider Pattern work.
Being able to drill down to see the controls for the sub block is very important for Navigation context so this is very strong. I think that's what users will expect to happen and aligns with Matias' original vision (i.e. editing in the List View is preferable to editing in canvas and should be the primary experience).
This is the bit that feels like it needs refinement. You've already identified that "there's no back button to the list view from the controls when a nav link is selected.". I think that's going to be a big problem. SuggestionWhen the UI allows drill down I think we should:
This is, after all, very similar to the current experience provided by the Navigation block specific List View in 6.9. As you know I'm not wedded to anything from previous releases, but it feels like a logic experience and one that has previously been validated by stakeholders and user testing. Thanks again for moving this forward. It feels like a strong candidate for the final UI. |
Member
|
Thanks for the updates, @talldan!
I'm not sure about the 'Edit navigation' link opening the List View, and then when clicking a nav item, you're then taken to the Contents tab. And yet if you open the Contents tab manually, those editing controls aren't shown. I'm wondering if it would be better to either:
|
Contributor
Just to be clear Sarah, I am precisely advocating for that very experience 😬 Because I think it's critical that the clear user intent "I want to edit my Navigation" maps to the UI updating to a state where they can immediately start editing. See #73383 for more context. |
Member
I think it makes sense that the List View is opened when clicking 'Edit navigation', but it's the second part I'm not sure of. I'm not a fan of switching to a different tab when clicking an individual nav item within the List View.
That makes sense to me, but the part I'm not sure about is the use of the two tabs. I'm not quite understanding the need to navigate users through both the Content and the List View to eventually drill down into the individual nav item. We're already listing the nav items within the List View, which is why I think the editing controls should sit in this tab as well. |
Contributor
I agree. Personally I think we should stick to the List View rather than switch between them 👍 |
Contributor
|
It does feel strange that the inspector shows information about three related blocks in one place instead of drilling down to indicate the groups relationship. 
Based on the video shared here, selecting a child block and switching to the content tab in the same inspector is the most confusing part of the experience. To communicate what the user is selecting and editing, I think it’s clearer to refresh the content section in the panel and show the navigation part that indicates the root and selected blocks. |
Contributor
This direction actually feels pretty good to me. I'm quite possibly in the minority here, but I don't mind switching tabs for editing content as it means you can still click the list view icon to get back to where you were. (This isn't blocking feedback in any way) One challenge, though, is that with a section selected, I imagine you should still be able to click on the Content tab to get back to the overview of the whole section / pattern / template part? In any case, wherever we wind up placing the controls / how we handle the drilldown, I do think this overall direction is promising, and I like that clicking "Edit navigation" takes us straight to the list view in the inspector where we can add and re-arrange links, that's feeling nice to me 👍 |
Contributor
To me this is the confusing part. Clicking on a tab to go back is an unexpected pattern. In that case, going back in the Inspector's header is easier to understand.
Agree. That action bypassing multiple levels of drilling down is nice. |
Contributor
Author
|
I've tried another alternative to this PR here - Pattern Editing and Navigation block: Remove content tab and show navigation controls in popover |
Contributor
|
The approach in #75194 feels good to avoid the tab switching. Does the work in this ticket should be closed then? |
Contributor
|
Yes this is no longer the agreed approach. It was very useful to help everyone compare the options and decide though. I'll let Dan close this one out if he feels ready. |
talldan
deleted the
try/showing-nav-link-content-controls-in-content-only
branch
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
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.
Related #74895
What?
Moves the navigation link and submenu inspector controls to the 'Content' group/tab, so that they are displayed for patterns.
Why?
See the issue for more context.
This PR presents a potential avenue, but currently an imperfect one. I'm curious about feedback so sharing early.
While it is possible to display the controls in the inspector for nav links and submenus, I don't think the interactions are quite right. For example the Controls are shown in a panel that just says 'Settings', and perhaps the block icon/title should be shown in this context (similar to the block fields experiment). The video below is also of a Template Part with only two blocks in the 'Content' panel. When the 'Content' panel is longer, the nav link/submenu settings will be further off-screen.
There's also the missing interplay between the List tab and the Content tab that was present before. Some changes to the tab selection are being proposed in Navigation: select list view tab on contentOnly, so that might help move things closer .
If we go this route and resolve the interactions, then it might be worth also showing similar controls for List Item, Button, Social Link which have a similar List View feature to the navigation block.
How?
Switches the
InspectorControlsgroup tocontent. Also adds some conditions:isSelected- for patterns, multiple child blocks can display their controls at once, for simplicity this only shows the selected nav link's controls.! hasDataFormBlockFields- prevents duplicate controls from the block fields experiment when that's active.Testing Instructions
Screenshots or screencast
Kapture.2026-01-29.at.16.23.23.mp4