Allow selecting from all available Pages when adding to Navigation block

[getdave]

Problem

As originally illustrated in #38121, users can find it difficult to locate the correct Post (typically Pages) when adding links to the Navigation block.

Whilst the search in the Link UI has been improved, it still requires the user to recall the name of the Page in order to be able to search for it by string. This can cause issues which become pronounced on larger sites with lots of administrators.

Proposal

I propose we introduce an ability to see the full tree of all the Pages on your website directly from the Link UI interface in the Navigation block.

Similar proposals have been made previously including:

• Improve relevance and ordering of search results in Link UI and Navigation block #38121 (comment)
• Consider Bulk Add Mode for Navigation #50831

My proposal differs in that I recommend we do not attempt to shoe horn this UI into the search results of the Link UI as presenting a hierarchical tree in this view which cause a lot of visual issues (not to mention technical overhead).

Instead I suggest we re-use the established UI pattern used by the Add block interface which exists in the Navigation block today. This can be repurposed (roughly) as follows:

Once you click "Select Pages" you would see a hierarchical tree of all the Pages on your site perhaps somewhat similar to:

We could even consider a "Bulk Add" mechanic for this interface.

Benefits

• Avoids over-reliance on search to find the Page you wish to add.
• Makes it easier for users to identify the Page they wish to add - especially if Pages have the same name but are under different "trees".

---

Create a means to see all your Pages in a single view and pick the one you want rather than having to rely on search.

@richtabor On this point, I wonder whether we could expand upon the UX pattern introduced into the Link UI with the Add block area, to add a new option called Select {Post Type} (i.e. Select Page).

When clicked, it would show a tree representation of all your Pages which you could pick from. I believe that a dedicated view is best because trying to shoehorn in a hierarchical, nested view into the Link UI search results will only add further complication.

In envisage this include a UI similar (but not identical) to that I mocked up in this Issue.

Originally posted by @getdave in #38121

[getdave]

cc'ing @richtabor @jasmussen who have both been heavily involved with Link UI and Navigation.

[jasmussen]

Here's an older prototype, which hasn't been shared beyond the public Figma files because it diverges a bit from existing link UI explorations. But in case it inspires fresh ideas, it seems related.

[getdave]

@jasmussen Perfect. That Figma is exactly what I had in mind here. Here's a video capture:

Screen.Capture.on.2024-11-19.at.13-15-29.mp4

I propose implementing the choose from all Pages element first.

[rinkalpagdar]

Once you click "Select Pages" you would see a hierarchical tree of all the Pages on your site perhaps somewhat similar to:

Hello @getdave, What if there are thousands of pages? Then, the hierarchical tree will be too long. I think it might impact the UI. Please share your thoughts.

[getdave]

That's a really great question - thank you. I would say we load a good chunk of the data and then use on-demand loading patterns to progressively disclosure the full list.

For example, you could load say 2 sub levels of the tree for any node, but further nodes need to be loaded on demand. This could be triggered by expanding the given node.

For a site with a large number of top level pages we may need to introduce a way to load in more pages from the tree.

Ironically I believe Classic WordPress uses search to solve this problem which we already have in place.

[fabiankaegy]

I love the direction of this :)

The only thing that comes to mind for me is that right now it is too pages focussed.

I believe this is actually one thing we can learn from the classic menu screen. It was really easy to find content you wanted to add to the menu. There were clear ways to get to all the different content types and then perform a search for any items in that content type. And you saw the hierarchy directly in that listing.

[getdave]

I love the direction of this :)

Great to hear. I'm also keen on the advantages of this interface. It's great to have your feedback on this as well so thanks for taking the time here.

...that right now it is too pages focussed.

I take your point here. As I understand it the focus on Pages is because the majority of (obviously not all) folks will be adding Pages to a Navigation rather than other content types. This is why today, the default inner block for the Nav block is the Page variation of the core/navigation-link block.

My concern with adding too many content types in a single view is that people become overwhelmed by the choice. I'd be interested in @jasmussen's thoughts here.

That said, we could develop this so that if you add a specific variation of the Navigation Link block (e.g. the Posts Link) then it would say Link to Post. This would also work for CPTs like Link to Book. The Add block prompt allows access to these other link variations.

And you saw the hierarchy directly in that listing.

There have been past discussions about introducing a hierarchy into the search result listings but this becomes extremely complicated. Indeed the Classic Menus screen does not show a hierarchy when searching.

That's why I believe we need a separate view for the hierarchy like the Classic Menus screen offers.

I prefer the idea of progressively disclosing complexity. So the UX is:

• Search for content (primary)
• Try one of the other options (secondary)