Reduce the number of ways to create a menu

[johnstonphilip]

The issue
Currently there are 2 new ways to create a menu. For example, on the "Appearance" > "Menus" page in the example below, there's the "Menu Structure" and the "Navigation Menu". Both do the same things, but are different UI's. I tend to prefer a single way of doing something because it makes reading/writing/maintaining documentation easier.

Describe the solution you'd like
Personally, I prefer the Menu Structure UI over the Navigation Menu flow. It feels simpler to use and understand for me.

Describe alternatives you've considered
It was proposed by @kjellr @melchoyce and @pattonwebz in the Theme Review meeting that a solution could be to add a toggle for edit/view, similar to the edit/preview tabs in the HTML block.

[paaljoachim]

Hey @johnstonphilip

I will add a link to the discussion about this during the Full Site Editing meeting in the themereview Slack channel. https://wordpress.slack.com/archives/C02RP4Y3K/p1591201979216200 (One needs to have created a login to be able to see the conversation in Slack.)

There was also some discussion of creating a kind of toggle to go between both methods of creating a menu. That way the user can choose the method they feel most comfortable with using.

[asathoor]

@johnstonphilip some users may prefer one way of doing things. Other users might prefer another way. That's the reason I'd prefer several options. If the UI should change, at least we need to know how most of the users prefer working. So I'd suggest a UX-test here.

[karmatosed]

There are a few things to consider here and I think starting to think how this is used helps frame that.

If you have a deeply nested navigation, you could easily get into some intense challenges using the navigation block. The navigator really helps in this regard.

Similarly, if you have a simpler experience you might prefer just to have to use the block itself.

Whilst on the surface it seems to be like 2 different ways, they are distinct in their limits and function. Along with this, the screen is a step on from the original navigation screen so having both makes that experience a little easier.

I would recommend keeping both over having an option and see what happens during testing of the experience. There are some existing explorations about moving to an all navigator experience for interacting #21727 has a few of those. For now, let's mark this low priority. My recommendation would also to be closing this to look at the work in #21727 as a starting point after 5.5.

[draganescu]

It was proposed by @kjellr @melchoyce and @pattonwebz in the Theme Review meeting that a solution could be to add a toggle for edit/view, similar to the edit/preview tabs in the HTML block.

The reason this screen will have both interaction models is to allow for faster and easier overview of large hierarchies, while at the same time attempt a close preview of how the menu will look on the front end.

For small menus editing directly with the block should be a better experience especially once the block will gain new features such as adding new block types, aside from links, plus the bock itself might get in the near future styling options that are good to be previewed at edit time.

For larger, deeply nested menus, a tree view is ideal and, given the screen estate present on a single purpose screen there should be no reason to toggle between modes.

I will close this issue, but feel free to reopen :) Thanks for chiming in!