Communicate sync'd nature of Navigation blocks

[getdave]

The Navigation block has a ref attribute which "points" to a Custom Post Type entity which stores the inner blocks for the given menu.

However, unlike Template Parts and Reusable blocks which were given visual affordances in WP 6.2, there is nothing to communicate the "sync'd" nature of the block.

I would like to propose that we add both visual and accessible affordances to indicate the status to better communicate that the items are "saved".

Note that I explored this in #46412 but it was not accepted. It's worth reviewing however for visual and code options.

Related

• Apply purple colour and "click through" to Nav block #46569
• Synced blocks: Define them as such in the Inspector #43261

[jasmussen]

There's a fair bit of overlap with #43261, and it would be good to find a generic solution one that isn't unique to the navigation block.

I've previously suggested we could make the block appear (in list view, block toolbar and inspector) purple, same as template parts. Also tracked in #47546 and #46569 (seem like unintended duplicates). But it looks like @jameskoster has some deeper thoughts on when and how to apply this. Jay, do you think the difference between how navigation is synced compared to TPs is significant enough to not make this purple?

For what it's worth, I'm happy to refer to Jay if he feels strongly about that. The fact that the navigation is synced does not feel to me like the standout feature — its intrinsic behavior of loading a menu initially seems to imply this enough that perhaps we really don't need additional indication.

[jameskoster]

Jay, do you think the difference between how navigation is synced compared to TPs is significant enough to not make this purple

I still have some reservations about marking Navigation as synced without some context in the UI. Mostly because it creates inconsistency with the convention that folks are taught in the Template Part / Reusable Block experience, where synced blocks with the same name appear identically in all instances. But in the case of the Navigation block, you could have two blocks in the same document, with the same name, marked as synced, but displaying totally different menus, with different behaviours.

As things stand, the only thing that's synced in the Navigation block are the menu items in the referenced menu. So unless we're willing to rework Navigation to be more aligned with Template Parts / Reusable Blocks, that's the thing I think it would explore marking as synced. A couple of rough ideas:

Denote the referenced menu in List View / Inspector:

Some educational content in the menu panel, more eloquent than this but you get the idea:

---

All that said, I acknowledge the nuances may be lost on folks, so it's not a super-strong opinion :)

[jasmussen]

Mostly because it creates inconsistency with the convention that folks are taught in the Template Part / Reusable Block experience, where synced blocks with the same name appear identically in all instances. But in the case of the Navigation block, you could have two blocks in the same document, with the same name, marked as synced, but displaying totally different menus, with different behaviours.

Ah, that's a good note. In that light I would lean to keeping things as is, no purple, no chips, but at most a notice like you mocked up, but I'd keep it gray, and maybe shorten the text.

Just to not leave the stone unturned (I'm not sure it's a good idea), but we could theoretically change the name of a navigation block in the list view according to the menu that was loaded. Like TPs and RBs:

[jasmussen]

Also good to think about the pattern block here #48458

[jameskoster]

but we could theoretically change the name of a navigation block in the list view according to the menu that was loaded

I know it's super nuanced, but I think this still fails because the same menu can have entirely different properties, which breaks the 'sync'.

my.menu.mp4

The items are synced, but the settings / appearance are not.

[getdave]

Great discussion here folks. Thank you.

The items are synced, but the settings / appearance are not.

Right. This is key. So to be 100% clear this is my understanding:

• Template Parts/Reusable Blocks
  • the block itself is just a "wrapper" - it doesn't have any styling properties.
  • all of the content is sync'd to an entity, including the styling and everything else
• Navigation
  • the block is an actual block (not just a wrapper) and can receive its own styling and other properties on a per instance basis
  • only the items within the block are persisted.

But there is nuance here, because in actual fact the items can have their own styling (and other properties) which is persisted to the entity. For example, see this hideous Navigation I made which has both custom links and social links which both have styling attached which is saved to the entity. Both Navigation blocks reference the same menu and the styling attributes are shared.

Note however that I applied different styling to the Navigation block itself. It's quite confusing 🤔

So how do we resolve this?

I think we ought to better communicate which Nav menu is currently in use. Be that Primary, Secondary whatever.

The next question is do we need to draw a harder line on what is/isn't saved to the menu entity? What is user expectation?

[talldan]

Just to note, I do still have this PR open - #46457 (surprisingly it has no merge conflicts).

It may serve as a good basis for addressing this issue, or could be closed by the outcome.

But there is nuance here, because in actual fact the items can have their own styling (and other properties) which is persisted to the entity.

Template parts and reusable blocks can also inherit styling from parent blocks like groups, so they don't always appear the same, but I guess they do in isolation. Maybe i'm nitpicking 😄

[jameskoster]

Note however that I applied different styling to the Navigation block itself. It's quite confusing

Yeah, that encapsulates my concern with marking the Navigation block as synced.

So how do we resolve this?

Perhaps we wait and see how #48458 progresses? The designs there might help unify many things, including Navigation, Template Parts, and Reusable Blocks.

[annezazu]

As we explore examining this, I wanted to note that I hear feedback from time to time around understanding where menus are used, especially when deleting or making changes. If there's a way we can surface this while we communicate the synced nature that seems ideal!

[jasmussen]

I have a feeling that as we surface all synced menus in a list in the site editor > navigation section, it will help here as well, to indicate their synced nature.

[getdave]

Circling back to this Issue which has not moved.

My feeling is we need to communicate which Menu is being used on which block. Currently to do that you have to:

• Click on the Navigation block
• Open the block sidebar
• Click on the List View tab
• Click on the 3 dots menu
• See the currently selected Menu.

That's not helpful to users.

I believe we should consider addressing this in small steps:

Firstly, surface the menu _name_ next to the word `Menu` in the Navigation block's `List View` tab


Secondly, consider surfacing the menu name in the List View next to the Navigation block.


There may also be additional affordances we can offer but I believe this Issue should be renamed and refocused on communicating the name of the associated Menu without overloading the UI for less experienced users who may not need to know about the sync'd nature of Navigation Menus.