[ Navigation block ] Hide the empty Links in Navigation when the block is not selected

[dwolfe]

Describe the bug
In the Navigation Block, empty new links persist with nothing entered (no link text, no URL). Clicking the inserter adds new empty links.

To reproduce
Steps to reproduce the behavior:

1. Open the Block Editor
2. Add a Navigation Block
3. Click the inserter button ([+]) to add a new link
4. Click the inserter button again to add another new link
5. See multiple empty new links with greyed out "Add link..." placeholders

Expected behavior

• After clicking the inserter button and the new link interface appears, I would expect the inserter button to be hidden or disabled until either the link text or URL fields aren't empty, or until the user clicks away and the new link block is no longer focused.
• If the user clicks the inserter and then clicks away from the new link block, leaving it empty, I would expect that new link block to be deleted.

Screenshots
Actual observed behavior:

Expected behavior (Figma prototype - ignore everything but the empty link behavior):

Editor version (please complete the following information):

• WordPress development version 5.5-alpha-47616
• Gutenberg plugin, Version 7.9.1

Desktop:

• OS: macOS
• Chrome version 80.0.3987.149

[jasmussen]

Good ticket, thank you, it surfaces a very key interaction that has more complexity to it than it might seem like it does.

Because for the navigation block alone, it does seem like a bug. But if we zoom out and look at not just this block, but any container block that has child blocks, this behavior is actually consistent with any other blocks in the block editor. Which is to say, if we agree that empty navigation blocks are useless and should be removed onblur, is there a path forward that lets us re-use this heuristic for other container-with-child blocks? It opens up a number of questions worth discussing.

• Should a group block with 5 paragraphs, 3 of which are empty, also delete the paragraphs onblur?
• What if you add a link to a navigation menu item, but not a label, should that be deleted?
• What happens if an empty block is removed and you press Undo? What about Redo?

I actually quite agree that empty navigation items are not that helpful. One of the features I like the most of Figma is that if you delete the last item inside a group, the group itself also disappears. No empty groups. It feels very natural and does not take a lot of getting used to. If we can find a heuristic for this interaction that feels as intuitive, it could be an incredible quality of life improvement for all container blocks. But as it is, I would not consider this a bug, but rather, something that would be really valuable to discuss!

[dwolfe]

Thanks Joen, good points! I have a couple of thoughts, don't know that this adds up to anything I'd call an answer, but maybe this will move the discussion forward a bit.

Because for the navigation block alone, it does seem like a bug. But if we zoom out and look at not just this block, but any container block that has child blocks, this behavior is actually consistent with any other blocks in the block editor.

In a general sense, shouldn't the Navigation Block (specifically) be different from other container blocks? If not, why use a Navigation Block, versus a column block containing multiple paragraph blocks with linked text in them?

Having said that, I do think empty blocks should be removed in other cases as well, generally. Your list of examples actually formed some of my thinking there. Taking these out of order...

• What happens if an empty block is removed and you press Undo? What about Redo?

For the navigation block example, I think the automatic removal of an empty nav block should actually be an undo operation. Then if the user clicks redo, a new link block would be added, and focus given to that field.

• What if you add a link to a navigation menu item, but not a label, should that be deleted?

If you add the link first, the link text defaults to the URL, but however this situation occurs (say you delete all the text), I think that should throw an error at the level of the navigation item block. There's data in the URL field in this scenario, which I think we shouldn't delete.

And now for this one:

• Should a group block with 5 paragraphs, 3 of which are empty, also delete the paragraphs onblur?

For me, empty paragraph blocks break the pattern, because users sometimes add them to create whitespace. The Spacer block is of course the "right" way to do this, but adding paragraphs is quicker/easier, and I think it would be contrary to user expectations to delete these.

So I guess "empty" isn't the best way to describe the blocks that I think should be automatically deleted. I thought maybe the common characteristic might be anything that's a "no-op" on the front end - if it's not going to display to the user's users. But your example of a navigation menu item with a URL but no text would be such a thing, and as I mentioned, I don't think we should delete that user-created data. So that's not enough.

Maybe it's "the user's only act was to create the empty block", plus "this block will have no effect on the public site in its current state". What do you think?

[jasmussen]

In a general sense, shouldn't the Navigation Block (specifically) be different from other container blocks? If not, why use a Navigation Block, versus a column block containing multiple paragraph blocks with linked text in them?

It should be different insofar as every block is different, and should be designed to be a good user experience, absolutely.

But it's important to not think of the Navigation block as being special in any kind of way. It's simply a block using the same block API that every other plugin or 3rd party can use, there's no reason Coblocks or Kioken blocks couldn't write their own Navigation block, should they choose to. In that vein, all blocks are created equal.

The balance to strike here is to decide when we are adding software complexity to one block in order to improve the experience, vs. when are we adding it to fix a fundamental issue with the block API that if fixed at the source could benefit every block. Given that the navigation block really just is a container with children, and in that vein is very similar to Social Links or Buttons, it feels like any fix made should also benefit those, and other similar blocks.

Maybe it's "the user's only act was to create the empty block", plus "this block will have no effect on the public site in its current state". What do you think?

An empty paragraph still outputs <p></p>. It's possible to write a block that, if truly empty, outputs nothing (``). The Custom HTML block is an example. Editor:

Previewed/published post markup:

However if that block was removed as soon as it was inserted and you deselected it, not only would it be confusing and frustrating for a user, it might even be an issue with page templates where you might intentionally want the block pre-inserted even if empty.

In fact I'd argue it's the same with buttons. Here are three buttons preinserted in a Buttons block, but not filled in:

The short of it is, it's incredibly difficult to find a good heuristic for when to automatically remove an empty block that is both generic across blocks, and easy for a user to understand.

[karmatosed]

What a lot of great thoughts here. It is important to note the origins of this block because for a child block the functionality makes a lot of sense. That doesn't dismiss that within the context of a navigation block it can feel a bug.

Some great questions posed here I wanted to dig into more from @jasmussen:

Should a group block with 5 paragraphs, 3 of which are empty, also delete the paragraphs onblur?

That's a great question and I know there is even an argument for blank multiple paragraphs to be limited outside the group block. I have no clear answer here but would caution into veering too much into predicting use of the group block and expectations. We need some solid user (not us) feedback to determine what is expected, or not.

What if you add a link to a navigation menu item, but not a label, should that be deleted?

This could be valid as you might be building a menu rapidly, you can do this using the keyboard pretty fast. Another angle could be creating in the block navigator rapidly the outline of a menu. The question is probably more as to how common this is and what again breaks in expectations.

What happens if an empty block is removed and you press Undo? What about Redo?

Such a great point as it's often easy to forget that foundational principle in the editor. What happens here can be an interaction hitch if unpredictable. That really is what a lot of this boils down to, how can we not shock with interactions.

Now, that all dug into. I also think that for the majority of cases empty navigation within the block interface causes more friction than limiting. It's just the how and expectations that need refinement.

@davewolfe you have a few points I also wanted to dig into.

In a general sense, shouldn't the Navigation Block (specifically) be different from other container blocks? If not, why use a Navigation Block, versus a column block containing multiple paragraph blocks with linked text in them?

There are other functionality like the block navigator and styling to consider within the navigation block. These add up to going beyond what you'd achieve with a column block or text links. Similarly, the ability to stack with sub-navigation, this isn't something you can do outside this block. Whilst this all seems smaller, it's key to the differences. So yes it's different, but the foundation is the same and that expectation of how a child block works is a strong foundation interaction across the editor.

Having said that, I do think empty blocks should be removed in other cases as well, generally.

We need to have some caution between our expectations and known user cases. This is a great area to dig in and find those. I pretty much agree on the need for there to be reductions in empty states, it's just what those limits are. I also think it is more incomplete states than empty, so that's a great reframing. If we start thinking of those as actions not finished, how we might treat them seems a little clearer.

For me, empty paragraph blocks break the pattern, because users sometimes add them to create whitespace.

I would propose that the same use case for this could see building a navigation block using empty states. It's worth discovering if that is the case.

I do side with @jasmussen as I feel any improvement made here could be done across all of these types of blocks, that's an exciting proposition.

[dwolfe]

I think this discussion has spiraled a bit, and I have responses to the above, but I think we've veered too far away from the original issue. Maybe the current behavior of the Social Icons block offers a way forward, specifically for parent blocks that contain one type of child block (ex. Navigation/Navigation Links, Social Icons/Icon, Buttons/Button, etc.):

Instead of deleting the empty navigation link blocks, could we hide them when the Navigation Block isn't selected? That would at least solve the issue of communicating to the user that the empty blocks won't appear when the page is rendered.

[jasmussen]

Instead of deleting the empty navigation link blocks, could we hide them when the Navigation Block isn't selected?

Yep, that seems like the next actionable step.

[karmatosed]

Just removing the bug and design feedback labels as there is a next step forward and confirmation it's not a bug.

[talldan]

I'm a bit concerned that by working on this in the context of a single block (Navigation Link) we'll be introducing inconsistencies across the editing experience.

I don't think the use case matches up with that of the Social Icons block. With Social Icons, several 'empty' blocks are added by default, so hiding those blocks is a way to clean up the initial state.

For Navigation Links, the user has explicitly added these links and hiding them would be unexpected given that this isn't done for other text based blocks. If the user doesn't want the links, why don't they just remove them?

[annezazu]

I just wanted to briefly chime in on this thread that as we work on this, we should also generally think about the overall flow for adding menu items to begin with: #23326 Right now, the current flow compared to the prior menu screen allows "empty" menu items to be almost too easily added resulting in this problem raised in this issue 😅 My fear is that currently we make it too easy to add a fully empty menu causing great confusion if people click out of the navigation block only to find a completely empty state.

[jasmussen]

The recently landed setup state for menu items has potentially changed the equation a little bit:

This setup state principle is being explored further for draft page items that show up in the editor but not on the frontend.

While hiding empty menu items definitely made sense before this setup state existed, it seems like it is less urgent now, or potentially even counter to that effort. Should we close this one out?

[shaunandrews]

This one seems resolved now.