Add option to add other types of blocks to navigation block

[karmatosed]

In the current implementation of the navigation block, you are limited to adding a link. In talking about iterating the sub-navigation experience, @mtias brought up a good use case for this of having a paragraph describing what a sub-menu does. We might want to limit what you can add in terms of blocks, but at least being able to just add longer text makes sense.

Option 1: block selection step

This would show the block library where you would pick the type to add. I would suggest limiting this, perhaps to the following:

As you can see, this also could allow the social links to be added if wanted.

Option 2: allow longer text to be added

This option takes out the block library and allows you to write longer-form easier within the existing link. I haven't mocked this up as for me this isn't as flexible and limits. It might be an easy short-term win.

Feedback

I am looking for specific feedback on next steps here. For me, the easiest is to just add a block selection step and then have the flow unchanged.

[mtias]

Social links should be exposed as its own block, not the child blocks themselves (which can only be inserted within a social-links parent).

[shaunandrews]

I've always found the current behavior of the + button in the Navigation block confusing. Having the inserter show makes a lot of sense to me. I'd expect to be able to add the Heading, Paragraph, Image, and List blocks to my navigation.

I'd also expect a way to add the Columns block in a sub-menu, but that likely requires a lot more work.

[karmatosed]

Thanks for the feedback everyone. I think we can then move this to 'needs dev' and note the following as a potential starting point:

• Heading
• Paragraph
• Image

The one I ponder is list, but happy for that to just be me. I would also like search to be considered as a later iteration.

[mtias]

My main worry for this is whether the "Link" is sufficiently clear as the primary item. Should we have variations of the "link" block that are "Page", "Post", "Category" to help streamline the action? (Note this was discussed very early, when we didn't have variations, and it meant creating separate blocks for each type of link, which was determined undesirable.)

[karmatosed]

Interesting, I actually like the idea of various links, it's a great way to stop those massive searches:

Note the icons are just there to suggest and would need to be worked out.

Then the link interface would just adapt based on entry point selected. I am half wondering if the fast row interface works better for adding over a full library here. Similarly, I am not convinced that search is needed. Here are some variations around that, putting back on feedback label as that can be opened.

[ZebulanStanphill]

Yeah, a simple list feels better than a 3-column layout... actually, I think we should consider using a list in all forms of the block inserter.

Using block variations to show the Navigation Link block multiple times with different presets is a clever idea. I'm not sure how exactly it would work in practice, though. Wouldn't it require creating block attributes that exist solely for determining which placeholder UI to use? Or can block variations also set local state?

[ballio2000]

Looks great! I also prefer the fast row interface, the "Add to navigation" label also helps clarify things. The regular 3-column layout might confuse users that you're adding blocks, but not navigational items.

Some ideas:

• I wonder if "Add to navigation" area could also act as a search, which one can type in the pages/items they'd like to add.
• For the list items, is it possible to predict popular items that users might want to add as navigational items? For example, we can surface unused/unpublished pages to the top of the list to suggest things to add. :)
• Also agree with Matias's note of the Link item could be confusing as Posts and Pages are also links.

[rickybanister]

To make it easier to understand that adding links to pages, posts, categories, or tags, I tried a quick sketch reusing the latest inserter UI that would allow filtering or searching:

[ZebulanStanphill]

@rickybanister That's a really neat mockup, though I wonder how it would work with languages like German where words tend to be a lot longer. (That tends to be the biggest issue with using tabbed interfaces.) It looks like there's barely any room for the 4 tabs as-is.

I think when a person goes to add something to a Navigation, once they've chosen what kind of thing they're adding, they don't need to go back and change it. Perhaps an interface where "Pages", "Posts", etc. are all provided in a vertical list, and after selecting one, the popover switches to a list of the kind of thing you chose (plus a search bar).

Then again, that's not so different from the vertical-list-style inserter idea, so maybe we should just go with that.

[kellychoffman]

having a paragraph describing what a sub-menu does

Could you show a flow (a few screenshots, not necessarily a full prototype) of the steps you would take to add a paragraph to describe what a sub menu does? Its a good use case and I think a full flow would more clearly illustrate the effectiveness of both design options. (or surface another)

[mapk]

I'd expect to be able to add the Heading, Paragraph, Image, and List blocks to my navigation.

The complexity of this block with just links is very... complex. Adding more items/blocks to the mix is a good idea for a future iteration. But right now, I'd like to see us get the link interface dialed in first.

To help bring this full circle, there were some early post/page/link explorations which may spark more ideas: #13690 (comment)

[olaolusoga]

Question, which story are the works above solving for:

Story: I would like the option to add different blocks like paragraphs, lists, headers,etc to my primary and sub navigation, so that I can create a robust navigation structure that includes more than text links.

or is it

Story: I would like the option to add different blocks to my sub navigation while keeping text links as my primary navigation option. I want this so that I can maintain a clean/clear primary navigation structure, while providing a more robust sub navigation that could house things like paragraphs, lists, videos, images, etc.

If they aren't solving for either, then could you share the story(ies) it is solving for.

having a paragraph describing what a sub-menu does.

In this scenario, couldn't a person achieve this by grouping a navigation block, and paragraph block? To make it "global", couldn't they a) make the group (pattern) reusable b) place it in a global template area if the group live in the header, footer, or sidebar?

[karmatosed]

Thanks for the feedback on this. A little status update that has come from this discussion and conversations around the original idea posed by @mtias. For now, this is going to be put to one side, however, that doesn't mean I won't be updating and responding to feedback. That also doesn't mean others can't jump in and continue their explorations, there are some idea seeds would be great for others to explore.

Let's recap a bit and update though as some questions were raised that it's worth before pausing to respond to.

Flow

I have created a very rough flow of what adding text for subnav could be like. I know @kellychoffman asked for that, so spun this up fast to at least show the steps. Note, this uses all existing interfaces and shouldn't be considered an ideal final flow, that's for deeper exploring.

In this very rough flow, however, it shows how you could:

• Add a paragraph as sub-navigation.
• Have that paragraph's block toolbar show, just like columns work right now.
• Be able to colour text, bold and add a background, just like you can in paragraphs. Also worth noting you can style the entire navigation block, so this over-rides on the new block you add. I didn't show the entire flow here, just showing a click.

This is just one very clunky example, but it shows the flow without the one of adding a link. I also did a rough one of simply adding the link that uses all existing flows, over adding new.

Sub-navigation has some work in development for improving that experience #22087, so it's worth noting to split that out from this flow. Similarly, columns block behaviours are probably good to learn from, but there's complexity with the toolbars in a small space, that could do with iteration. This iterating would benefit not only navigation but any child or group blocks.

Questions answered

Now, there were a few questions I wanted to ensure got some replies.

I wonder if "Add to navigation" area could also act as a search, which one can type in the pages/items they'd like to add.

I love that idea @ballio2000 and potentially this could see some exploring around the block library itself as far as an iteration.

For the list items, is it possible to predict popular items that users might want to add as navigational items? For example, we can surface unused/unpublished pages to the top of the list to suggest things to add. :)

I'm nodding as I suspect this could happen and I love the idea of it being supportively predicting and saving time.

@rickybanister I think potentially the link interface itself could benefit from your improvements, navigation block or not. I personally love tabs for a solution in these little box interfaces.

But right now, I'd like to see us get the link interface dialed in first.

After chatting to @mapk, you confirmed this was the moving of child blocks. I agree that they need refining, I don't think one is a blocker for this work, however, there is an opportunity for wider exploration which we now have. The link interface itself is another story and right now is pretty solid as far as iterations go, although I wouldn't mind seeing the exploration by Rick in PR to see what it feels like for all links.

@olaolusoga your first story seems close to the intention. I would caution against opening up all blocks. I think having a strong use case for any block is key here and should have each looked at individually. For example, video strikes me as a less common and potentially problematic addition.

In this scenario, couldn't a person achieve this by grouping a navigation block, and paragraph block? To make it "global", couldn't they a) make the group (pattern) reusable b) place it in a global template area if the group live in the header, footer, or sidebar?

Potentially, I think that knowing to group and the learnt behaviour of this is quite a tall order for most people using the editor though. That could indicate grouping needs iteration to level that steep learning path though.

[mapk]

After chatting to @mapk, you confirmed this was the moving of child blocks.

Yes, moving blocks is one aspect. There's a few others that can help the Navigation block:

1. Line breaks in subnav items: Nav block: Line break happens when adding subnav #22181
2. Subnav popovers: Visual and experience improvements to existing sub navigation flow #22107 (comment)
3. Subnav backgrounds: Fall back to default block styles when a new block is being inserted #22167 (comment)

I'd like to see us nail these down and really create a good Navigation block experience (with just links) before we add more complexity.

Thank you, @karmatosed, for all this great work!

[javierlorente]

Unable to add native menus?

[mapk]

I see you're making the rounds, @javierlorente. I answered you on the other issue where you asked that question. 😄

[noisysocks]

Quick update on this issue:

• Navigation: Allow Search block to be added alongside links #22656 implemented the technical infrastructure necessary to support non-link blocks inside the Navigation block on the Navigation screen. We're using the Search block as a test-case.
• Extract navigation link rendering code from the navigation block #21075 implemented the technical infrastructure to support non-link blocks inside the Navigation block in a post, page, or in FSE. We're using the Search block as a test-case.

There are some issues that need to be resolved:

• Need to fix some styling issues with the Search block when it appears in the Navigation screen. Navigation screen: Add .editor-styles-wrapper #23736
• Need to fix an issue where non-link blocks are not rendered inside an <li> when inserted in a Navigation. Navigation: Non-link blocks should be wrapped in a <li> #23915

With these fixed we can then proceed with building out the rest of this feature:

• Add support for more blocks including Spacer, Divider, Social Icons, Paragraph, Image.
• Split the Link block into Post, Page, Category, Link, etc. Navigation: Split Link block into Post, Page, Category, Link, etc. #22919
• Investigate supporting complex submenus. Navigation block: Make nested menus fully customizable (Megamenus) #23745

[noisysocks]

Closing this in favour of #24364 which overviews at a high level how this feature will work and what the next steps are.