[Navigation Screen] Broken first landing experience when no menus are present.

[talldan]

Description

When first landing on the Navigation Screen, if the user has no menus they're presented with a screen that has the message 'No menus available'.

However, the user can still edit and save a menu without being given a way to name the menu.

Step-by-step reproduction instructions

1. Enable the navigation experiment
2. Delete all of your menus (either on the old menus screen, or the new navigation screen).
3. Open up the new navigation screen
4. Observe that there's a menu present that can be edited

Expected behaviour

Either:

• The user has to explicitly create and name a menu before being able to edit and save (this is consistent with how the screen generally works, but we'd need to decide what to display on screen when the user has no menus).

Or:

• The user can edit their navigation and is prompted to name the menu before saving (I think this is an ok option, but it's different to how menus are named in all other cases).

Or something else entirely (this needs some design thoughts).

In tandem with this, we might want to think about what the user's first experience on this screen should be, how do we make it clear what the first step should be?

Actual behaviour

When there are no menus present, the user can still edit a navigation block in the editing area of the screen. The user can edit and save it, but has no way to name it, assign it to a location, or delete it (so this is very bad bug!).

Screenshots or screen recording (optional)

[jasmussen]

Good ticket.

There's some work to be done here:

• The edge to edge spacing of the white sheet disconnects from the menu above.
• The positioning and behavior of the cog gives it undue prominence.
• The list view can potentially be integrated visually in a more connected way with the block.
• The buttons above need love and additional prominence.

Those are some of the issues that will all help to make clearer how to interact with this screen. I currently have to focus on the navigation block itself, but I hope I will have some time to take a stab at this, but no promises.

Looking only in isolation at the problem described in this ticket: how do I name my first menu? I'd take inspiration from the existing menu editor:

• "Create your first menu", it says, with no option to "Add new" before that.
• The menu name is a permanently visible input field with an actionable button right next to it.

Suggestion: Replace the "no menus available", with a "Create your first menu below" message. Remove the "Add new" button entirely, and make the menu name input field visible right on the menu box. Remove "select menu" and "manage locations" so long they are empty.

Once you've saved your first menu, you get this:

Note how it shows you can edit the currently selected menu, or create a new one. Manage locations also becomes visible.

Like I said, I hope to be able to push some tweaks in the near future, and my instincts go towards reduction and moving a little towards the existing screen. Here's a very rough doodle:

Hope that helps.

[shaunandrews]

I mocked up a sort of "first run" experience that looks something like this:

Menus.First.Run.mp4

It was mentioned that this could all be unnecessary if we create a new menu automatically (perhaps with a general "Menu" or "Menu 2" name) when you first visit the screen. That might be generally simpler, but I also like the opportunity to educate users — but maybe it isn't worth the time for this aging system and screen?

[talldan]

It was mentioned that this could all be unnecessary if we create a new menu automatically (perhaps with a general "Menu" or "Menu 2" name) when you first visit the screen.

I had a look into the idea of using an automatic name as a quick fix, and it seems to be more complicated, though I might be looking in the wrong place. It's not just the name that's a problem, but the way it's working at the moment is that the screen has a menu with a null id, which is causing all kinds of bugs when saving.

The way to solve it properly would be to create a menu post type on the server when the user has no menus, which is taking us towards what your mockup does anyway.

That might be generally simpler, but I also like the opportunity to educate users — but maybe it isn't worth the time for this aging system and screen?

I also like this a lot. I don't think it'd be too much work and would offer a lot of value. From a dev point of view, I think we could potentially break this into two parts:

1. Implement the initial state for naming the user's first menu
2. Implement a placeholder for the navigation block that's more appropriate for this screen.

The first part generally seems straightforward to implement, and the second part is something we already need to do (#23953).