Add Block: Navigation

[melchoyce]

...Which I think we should rename to "Navigation Menu." :)

I have a lot of questions around best practices for something this dynamic:

• Should the menu building happen in the Inspector, or in the preview?
• Like the Custom HTML block, should there be a way to toggle between entering content and previewing it?
• Should the block start with any pages, or should it be totally empty when you make a new block?
• Should we have an option to display pages as a vertical list, or a horizontal bar/list?

Related to #1011.

[melchoyce]

Also worth noting: once we establish the pattern for "building" a block's content in Gutenberg, we can also then show how that could be applied to something like a contact form block.

[jwold]

@melchoyce just to clarify, are we trying to replicate experience from: Appearance > Widgets or Appearance Menus?

I started to think through how the experience should be with the Widgets but realized I should check first.

[melchoyce]

To be honest, I don't think we should necessarily replicate either — I think this would be a good chance to re-examine what it looks like to build a menu, independent of menu locations. Maybe in the short-term, any menu built as a block is back-compat as a new menu to nav-menus.php so you can use it in other places, but in the long run, I think abandoning menu locations for blocks is going to make site building much easier to understand.

[jwold]

What do you think about this? Anything we should change/add/remove?

[melchoyce]

So: list of pages/etc. in the inspector, drag (or tap) from the inspector into the menu block? That's an interesting idea — @jasmussen, what do you think?

Since this is a complex block, it might be good to explore a couple different ideas before settling on a direction.

[jwold]

Since this is a complex block, it might be good to explore a couple different ideas before settling on a direction.

Absolutely! I think this idea is one direction to pursue, but would love to see what others come up with.

[jasmussen]

✨

Solid discussion, great ideas. I think the inspector feels like the obvious place to configure the contents of this block, yes, but even then it's just nice to see baby steps to fix this.

I think a pretty key aspect to figure out, and perhaps this overlaps with #1516, is how do you save these menus and how can you re-use an existing menu. Does each menu you save become a new block in the inserter? Or is there a single menu block you insert, and you then pick a saved menu from the block itself as the first step? And/or customize it then and there? Probably good to explore a few directions so we can cauterize them until only the best approach remains. (As Mel essentially said already)

[folletto]

how do you save these menus and how can you re-use an existing menu.

I feel the shared blocks idea is how to deal with it, without making an ad-hoc UI specifically for menus.

In the work I've done so far with menus both .org and .com the "reusability" factor didn't show up as a user need, and in fact caused a LOT of trouble due to how complicated it made the UI (associating a menu is a hard concept to grasp).

I'd consider not addressing that part of the UI for the time being, and iterate back once #1516 reaches a solid v1.

[westonruter]

I think the initial version of the block should omit the “create a new menu” link. This is only present in the Customizer, and it is not available on the Custom Menu widget that appears on the widgets admin screen.

Aside from the issue of being able to create a new menu in a block which isn't yet published (i.e. what the Customizer implements as a placeholder menu), an additional complication for the menu block is that nav menus aren't yet available for manipulation via the REST API.

[melchoyce]

@westonruter I think those are issues we're going to want to solve before pushing up this block — definitely before launching it to the next-gen Customizer. I think it's worth doing the hard work now so we can create a block with a more ideal menu creation process.