Navigation Block: Reconsider placeholder state

[shaunandrews]

When adding a Navigation block to a document, you see the block's placeholder state.

There's a number of things that this UI is trying to do, including:

1. Create a new, empty menu.
2. Create a new menu using a sites existing Pages.
3. Choose a previously created menu to populate a new menu.

I think the dropdown UI is a little complicated, and the current copy is awkward to read. There's an issue to update the copy, but it's kind of stalled; The UI is difficult to explain.

Looking at the Image block for inspiration I wound up with something like this:

This feels a little easier to understand, but it is still a rather large representation of a real websites navigation. Lets take a look at it in the context Full Site Editing, where you would be adding a Navigation block to a page template:

After digging through more of the previous Issues and PRs around this subject, I tried rethinking things a little bit; What if we default to adding an empty menu (1 above), with shortcuts for adding existing Pages or Menu's (2 and 3 above):

An alternative to this is to default to a menu containing all top-level Pages, with a somewhat hidden option to remove all Link blocks within the menu:

[mapk]

I like where you landed Shaun. Your first iterations that followed the Image block still left some confusion around how the "Add existing menu" option would work. I believe that's why a dropdown was proposed.

The further iterations to just add all top-level pages automatically remind me of some very early concepts that were explored. When seeing this block added to a template, I agree that this direction fits better in the allotted space than showing a large placeholder screen.

The last iteration also works better than the option to "Add all page" because it just focuses on top-level pages and not on ALL pages. If I were to add all pages, I'd assume sub-pages would also be added automatically. This could get a little daunting.

While it's somewhat hidden, the "Remove all links" option is vital and I'm glad that's being considered.

I'm still left wondering about existing menus though. If I've got an existing menu for my Footer already built, how would I select it from the block in regards to your last iteration?

[MichaelArestad]

An alternative to this is to default to a menu containing all top-level Pages, with a somewhat hidden option to remove all Link blocks within the menu:

The more I think about this idea, the more it makes sense to me in a majority of situations. What if I go to add a menu to my header and I just insert it, maybe arrange the links a little, and that's it?! I think it would feel like I inserted a menu and not a container for a DIY menu.

There are pitfalls:

• It isn't the most straightforward to move or remove current links. I think this is the biggest blocker to an "Add all links by default" method.
• What happens on sites with hundreds of pages? Perhaps we could detect this and default to an empty state with a warning letting the user decide if they want to spawn a huge menu?

[jasmussen]

Shaun, an idea that I heard Matías float, could the quick inserter absorb some of this functionality? I don't have a full mental picture of how it might work, but if the quick inserter is limited to the allowed child blocks, could it also hold options to insert a full menu? I imagine Riads new inserter might accommodate it potentially #22789

[draganescu]

@jasmussen there is an open topic to start developing a Pages block that would track the pages structure.

This Pages block doesn't solve all issues immediately (say a site with a hundred pages) but it could alleviate some of the burden of the Navigation block. Also filtering and customizing this Pages block is easier in a stand along fashion, without the other options of a Navigation.

If we go wild we could have a block for "Legacy menu" :) - I don't think this is a great idea, but thought I'd mention it to maybe spark some other idea. This delegation to more particular blocks could make the Navigation block more useable and easier to grasp.

cc @shaunandrews

[tellthemachines]

What if we default to adding an empty menu (1 above), with shortcuts for adding existing Pages or Menu's (2 and 3 above):

I love this idea! It's much more flexible than defaulting to top-level pages, because if we want to create a completely different menu, we don't have to delete all our pages first. Having it empty and the options to add stuff a click away seems ideal.

I wonder if it would make sense to have the ability to add and combine multiple existing menus too.

[shaunandrews]

could the quick inserter absorb some of this functionality? I don't have a full mental picture of how it might work, but if the quick inserter is limited to the allowed child blocks, could it also hold options to insert a full menu?

Maybe something like this, @jasmussen

[jasmussen]

That just might work! Could add the basic "all pages" there too.

[shaunandrews]

[jasmussen]

As a wireframe and concept, this feels like it checks the boxes of allowing you to quickly add a specific menu, without having a giant setup state full of dropdowns and boxes and cogs, yet it still uses existing UI — the inserter and the plus button.

Question: once you've inserted an existing menu, or "all pages" — the behavior of the plus changes, doesn't it? I guess this is why you're using the big white appender button in the empty state, and presumably the black plus button would take over when no longer empty?

The only downside I see to this approach, is that in its empty state, it still doesn't look like a "navigation menu" — it's just a white blob. Smaller and with a plus, but still. This is no worse than what we have today, and solves a lot of problems, but it speaks to a larger issue we should keep thinking about: how can we improve the setup states to look more like the end results.

Nice work, Shaun!

[draganescu]

@shaunandrews @jasmussen we also seem to have this issue #20853 on the same topic. Should we close that and track here? If so just making sure we're updated with the discussion there :)

[jasmussen]

They do seem to tackle the same problem, yes, but we need to port the good stuff from this ticket to the other then ;)

[draganescu]

I would close that other one.

[jasmussen]

That works.

[getdave]

Great to see this evolving!

The only downside I see to this approach, is that in its empty state, it still doesn't look like a "navigation menu" — it's just a white blob. Smaller and with a plus, but still. This is no worse than what we have today, and solves a lot of problems, but it speaks to a larger issue we should keep thinking about: how can we improve the setup states to look more like the end results.

How about rather than just a blank block appender +, we have some "ghosted" placeholder nav items to make the placeholder look more like navigation that already has items in it?

---

I know we are supporting lots of block types in the Nav but do we need to have a search? Is it warranted given how few blocks are compatible with Nav? It immediately made me feel the UI was quite intimidating with a lot of items to digest and understand. Removing search would probably help with this.

Also:

• how would this search work for existing WP Menus?
• could you clarify what the graphics next to each of the existing menus represent? This wasn't clear to me.

Nice work - looking forward to seeing this move forward 👍

[jasmussen]

How about rather than just a blank block appender +, we have some "ghosted" placeholder nav items to make the placeholder look more like navigation that already has items in it?

The important part here is to focus on a solution that is generic to any block, or any theme, or any background. I.e. ideally we find something that works also for Buttons and Social Links, or perhaps even an empty group block.

The color problem we have already with the Spacer block, the light gray looks great on a white background, but not on a black background, or even an arbitrary color like green or blue.

I know we are supporting lots of block types in the Nav but do we need to have a search? Is it warranted given how few blocks are compatible with Nav?

It does seem worth pondering how to make this quick inserter as contextual as you can make it, so if there are less than n blocks allowed, maybe a search isn't necessary?

I also wanted to clarify my comment in #23207 (comment), because Matías pointed out to me that we can easily slide to the wrong side of the fence on this one.

It's good for the inserter to be contextually smart. But it's important that it only deal with actual blocks, or we risk it not behaving as you would expect.

[shaunandrews]

Ideally we find something that works also for Buttons and Social Links, or perhaps even an empty group block.

This got me thinking. The Buttons block starts out with a single Button placed by default. Now, it might be weird to default to a single Link block, but maybe we start with a new block that lists all your site's pages; A Pages block.

Here's a quick GIF that shows how that could work:

In the GIF, I'm adding a new Navigation block to a (mostly) empty document; By default, the Navigation block contains the Pages block. This new block displays links for all my site's pages. I'm unable to edit the individual links, but I can turn on/off sub-menu drop-downs, letting me only show top-level pages. If I remove the Pages block, I get an add button similar to the Group and Column blocks.

[jasmussen]

Looks promising Shaun!

The idea of an "All Pages" block, I believe, was brought up by @mtias at some point. In theory it seemed clunky, but thank you for mocking it up, because in practice it does not seem clunky.

I think it should be called "All Pages", though, not just "Pages".

The idea solves a number of problems:

• It implies (and is the case) that the pages block is locked to showing the pages on your website, which almost always make up the structure of your website: when you add or remove pages, it will be reflected here. This is a big one.
• It allows faster building of your menu — just insert this block, and you're probably done.
• It vastly simplifies management, because titles, links, sort order are defined by the metadata stored in the pages themselves.
• We could even default to inserting the All Pages block when you insert a Navigation Block. This would be a highly useful initial state.

There are downsides, of course. You click a menu item expecting to edit it, and you can't. There's no easy way to sort items in the menu, or change their labels, and items aren't in sync with new pages. However those interactions were also the ones adding the most complexity to the block.

This effort also does not preclude still allowing such editing of individual menu items. I'm sure you have a mockup of this already: selecting the "all pages" block, and transforming it to editable link blocks, just like you might transform a Gallery block into multiple Image blocks. Doing so would actively sever the connection between your pages, but at the same time let you edit to your hearts content — remove items, sort, change labels.

---

We used to have a Button block (singular). But it was hard putting two of them side by side. The Buttons block (plural), was created to solve that. I remember the discussion — isn't that just a group block? Yes, but it's a specialized group block that is tailored to handling just Buttons inside, enabling features tailored to just that.

Similarly, thinking of the Navigation block as a "tailored group" block, I could see it working. You can have an "All Pages" block inside, a "Social Links" block, a "Search" block, and you can choose whether to show them vertically or horizontally, space-between or flex-end. I can see it working.

[shaunandrews]

I think it should be called "All Pages", though, not just "Pages".

I started by calling it "All Pages" but have since decided upon "Pages." Mostly, this is due to the ways I can see this block adapting and being used; For example, perhaps the Pages block allows you to hide/show pages. Or, perhaps its added inside some imaginary Submenu block and used to only show child Pages. Basically, I think its possible this new block might not actually contain literally "all" of your site's pages.

That said, its a little early to tell and the name is easy enough to change still.

We could even default to inserting the All Pages block when you insert a Navigation Block. This would be a highly useful initial state.

This is exactly what I suggested in my comment above: "By default, the Navigation block contains the Pages block."

I'm sure you have a mockup of this already: selecting the "all pages" block, and transforming it to editable link blocks

I do, but I didn't want to go on too much of a tangent in this issue. Since you've asked, here's a few options I've worked up for how the Pages block could be "broken" or transformed into editable Link blocks:

[ZebulanStanphill]

I like the concept of the "All Pages"/"Pages" block and being able to convert it to Navigation Link blocks. It reminds me of something I have in my Table of Contents block PR, where the Table of Contents can be transformed into a List block if you want to customize the order/links, though this comes at the cost of losing the auto-add-headings-to-the-list functionality.

[shaunandrews]

Some more discussion around the proposed Pages block over in #23689.

[noisysocks]

In an attempt to make the Navigation screen project board contain only issues that are needed to ship the new Navigation screen, I removed this issue from the board and created #23953 which is smaller in scope.

[shaunandrews]

To circle back to this one, I still think an "All Pages" (or more general Page Listing) block makes sense to be inserted by default.

Seeing as we don't have that block right now, we should update the current placeholder so its not so large.

[ZebulanStanphill]

Removing the big "Navigation" label from the placeholder... would that be an accessibility regression?

[shaunandrews]

would that be an accessibility regression?

How so? There's still the block toolbar (not shown in my screenshot) and the block would still identify itself as a Navigation block.

[enriquesanchez]

Removing the big "Navigation" label from the placeholder... would that be an accessibility regression?

I don't think so. The block type is already announced as you enter the block. In the case of the Image block, you hear "Block: Image, group" when you focus the block. If I hit tab I jump straight to the Upload button.

I'd expect for this to be a similar case on this block: "Block: Navigation, group", if I then hit tab I'd hear: "Add all pages, button"

[jasmussen]

There's also a great deal of usability to consider, insofar as the compact placeholder state actually looks even a smidgeon like the final result. That definitely conveys the purpose of the block setup state in a way a big white slab doesn't.

[shaunandrews]

@mkaz is looking at this over in #26947

--

I really dig what @jasmussen proposed for the Social Links block: #26953 (comment)

I tried something similar for the Navigation block and think it might be worth trying it out:

Here's how that could look within a template, perhaps inheriting some colors from the theme:

[jasmussen]

Love it, Shaun, and in fact the social links placeholder state was inspired by your mockups right in this thread. Definitely agree this is worth trying.

perhaps inheriting some colors from the theme

We can use currentColor and opacity and it should work.

[jasmussen]

I'm making progress on this in #27018 (comment).