Navigation Screen: MVP Designs

[shaunandrews]

The current Navigation experiment (which aims to replace Core's Menu screen) looks something like this:

Its an obvious work-in-progress. While it contains a good amount of the functionality required to replace the older Menu screen, its lacking in design.

My first instinct was to suggest we make use of the Interface package which would give access to the top bar and sidebar components, which are also used in the Block Editor, the Site Editor, and the experimental Widgets Editor. It could look something like this:

It seems like this might not be the best solution. Instead I've tried to work with the existing experiment to see what I could do to get it ready for prime time. I tried my best to clean up the layout, hierarchy, and (hopefully) improve the overall usability.

Here's where I've ended up:

--

There's a lot in the GIF. Here's a breakdown:

• The "auto-add" pages option and the menu location settings for the menu have been moved into the Navigation block's settings (Issues Move "auto-add pages" into the Navigation block's Inspector #25010 Move theme location selection into the Navigation block's Inspector #25011).
• Add the current menu's name to the top of List view (Issue Add menu name to the top of the list view #25233)
• When the Navigation block is selected, hovering over a menu item with children should display those children in a dropdown. Selecting a menu item with children will force the display of those children. If a block other then the Navigation block is selected, hovering should have no affect on the display of children (Issue Show Navigation block's children on hover #25012).
• Theme locations have been moved into a popover containing the list of locations, each with a select to choose a menu. This could be problematic if themes offer more than a handful of locations. We could scroll the popover as needed, or simply keep the separate screen (Issue Move theme location selection into the Navigation block's Inspector #25011).
• When the Navigation block is selected it's toolbar displays the name of the menu. Pressing on this name enables you to edit it (Issue Navigation Screen: Allow for editing a menu's name #24581).
• I've updated the Navigation block's description to "A collection of blocks that allow visitors to get around your site." (Issue Update the Navigation block's description #25013)
• Creating a new menu flows more like the Core Menu's experience; A new Navigation block toolbar is displayed, with focus put on the menu name input. The rest of the UI is disabled until the menu is named and the button is pressed (Issue Update the "Create menu" flow #25014)
• The Navigation block placeholder takes a cue from Navigation Block: Reconsider placeholder state #23207. (Issue Update the Navigation block's placeholder #25015)
• Other than the Link block, the Navigation screen should support the Page Listing block (outlined in New "Pages" Block: Display a list of links to a site's pages #23689), variants of the Link block for Categories and Tags (Navigation: Add Post, Page, Category and Tag variations to Link #24670), the Search block (Issue Navigation: Make Search block look nice when added to a Navigation #24643), and the Social Links block (Issue Add SocialLinks block to the Navigation block #25016).
• The List View incorporates the new designs from List View Design Updates #24029.
• I've incorporated the new Link UI designs from Link UI: Add and edit links directly within the block toolbar #23375.

There's a clickable Figma prototype if you'd like to see full-size designs and experience the flow for yourself.

[mapk]

@shaunandrews thanks for sharing the prototype. My initial click-through went something like this... I see 3 different modules that include buttons/text/dividers/icons, but because of the gaps in between each of the modules, they feel disconnected… until I click on something... then visual changes appear everywhere. This was a bit difficult to process how each related and what was happening.

For example:

Feedback

• They feel disconnected without the Editor to unify them all together.
• When editing the menu, I'm a little unclear. Should I be editing in the left module (list view) or in the right one (block)?
• The icon in the topbar is unnecessary. Is it a block icon? Am I editing a block in this screen? I can't tell. It appears clicking that is the same as just clicking the Menu name.
• There's a lot of popovers that sprout up. In addition to the visually disconnected boxes below them, it's really busy.
• That top bar, because of its positioning on the page, doesn't look like a block toolbar, nor does it look like the Gutenberg topbar. It took me a bit of time to figure out how it was related to the menu below.
• Is the "theme locations" in the settings popover the same as the Manage Locations option at the top of the page? They seem very similar.
• I'm seeing a lot of redundancy throughout.

I know this screen is a difficult one. It's been lingering around for a long time, so thank you for taking it on! I'm just noting that a lot of these issues could probably be solved by bringing in the Interface package as you mentioned above. It ties everything together in a way that makes sense. My vote would be for that direction. :) It would also align really well with the Widget Editor.

[afercia]

Glad to see a visible H1 heading as first thing in the main content, as also asked on #24937. Is there a similar design also for the Widgets page already?

[paaljoachim]

Hey @afercia

Check out this comment by @mapk
#24561 (comment)
There is a comment and a mockup that includes the Widget H1 page title.

[draganescu]

One thing here @shaunandrews: I am not sure the SitePages block makes sense in the Navigation editor as this works all right with the auto add pages functionality and we can also create from pages. This block is a good feature in the context of using the block in the post and site editors where we save the navigation using block storage and so we cannot simply implement the auto add.

I suggest we remove this requirement from the tasks above 😆

[shaunandrews]

I am not sure the SitePages block makes sense in the Navigation editor as this works all right with the auto add pages functionality and we can also create from pages. This block is a good feature in the context of using the block in the post and site editors where we save the navigation using block storage and so we cannot simply implement the auto add

The existing "auto add" checkbox only adds top-level pages; The Page List block is designed to show hierarchy with an option to display literally all pages.

I do think a Page List block would be helpful in the Navigation screen, but its probably not a requirement.

[talldan]

@shaunandrews Is there a way to add a label to the 'Change Menu' select element? I realize this changes the flow of the design, but preferably there would be a visible label for form fields.

What were you thoughts on how things might look on mobile? This isn't too different to the layout of the current design, so it may be fairly similar.

[talldan]

One other thing I've been thinking about is how a user can tab around using the keyboard as well. Just throwing out a potential option for tab order based on the visual order of the screen:

• Add New
• Manage Locations
• Change Menu
• List View
• Block Toolbar
• Blocks
• Save
• Block Inspector

The thing that stands out is that the Block Inspector is after Save. Would it be better to switch those in terms of usability? (cc @tellthemachines).

[shaunandrews]

add a label to the 'Change Menu' select element

We could probably do something like this:

[manmotive]

Can the menu select box also include the names of any locations the menu has been tagged to? As in the current nav-menus.php screen:

[paaljoachim]

A new test design.. inspired by Shauns designs (took some of the screens), the new Widget screen, the current Navigation screen and the beta Navigation screen.

The focus is on the flow of the Navigation screen using elements/methods we are already familiar with from Gutenberg.
Such as the inserter panel to add blocks.
List view.
Sidebar settings.
Center title with a drop down is new and being worked on in relation to Full Site Editing.

I made a wireframe in Figma located here:
https://www.figma.com/file/8it5sK19F8jbmpefHglFx0/New-Nav-screen-exploration?node-id=0%3A1

Prototype:
https://www.figma.com/proto/8it5sK19F8jbmpefHglFx0/New-Nav-screen-exploration?node-id=1%3A2&scaling=min-zoom

Here is an animated gif showing a possible flow with focus on using the Inserter, list view and settings.

The purpose is to inspire.

There is some duplication of controls in the footer and the Nav settings screen.

A few additional thoughts....
The inserter section on the left can be extended with additional blocks.
One example the social links block. #25016
Having a panel that can be extended will be helpful also for the community as plugin developers can add their own blocks.

Drag and drop should also be made possible directly in the Navigation menu area. A press and hold (see outline of item) and then drag & drop. It would be supplementary to the Navigation structure. The user can then choose direct manipulation of the items in the menu or use the Nav structure.

The Navigation h1 label should likely be the first element in the top bar like so: Navigation (title) - Inserter (icon) - Nav structure (icon).

[afercia]

The thing that stands out is that the Block Inspector is after Save. Would it be better to switch those in terms of usability?

Thanks for pointing out this @talldan. Yep, the accessibility team asked for having the Save button as last thing in the tab order in the block editor as well, no luck so far 🙂 The thing is that for accessibility, the DOM order and the visual order must match so I do realize that visual design needs and accessibility needs clash here.

The Save button at the end is expected by users who navigate or perceive the content in a linearized fashion. For example, keyboard users or screen reader users navigate the content sequentially, at least at the beginning when they are learning the interface. Screen reader users, once they learned the UI, have lots of tools to jump to parts of the UI, as long as there's a good headings structure, ARIA landmarks, etc. Regardless, it's basically a linearized experience as there's no concept of "layout".

A Save button in the middle of the UI would be more or less equivalent to placing a Submit button in the middle of a long form 🙂

We also considered to have two visible Save buttons, with the second one placed as last thing in the relevant UI. No luck, and I do realize two buttons would be visually problematic, although not unprecedented in WordPress. One thing we didn't consider so far is to have a second Save button that gets only revealed on focus. This could serve well all keyboard users (including screen reader users) and still keep the UI "clean". Will ask the accessibility team for their thoughts.

[noisysocks]

A had a go at implementing the broad strokes of this in #25178.

[shaunandrews]

Based on some of the feedback above, I've updated the design and have been working with @noisysocks's PR #25178 to explore these ideas:

[mapk]

This feels so much more cohesive!

[paaljoachim]

It is nice to see the stronger cohesive with Gutenberg methods.
This looks really interesting.

Is there a prototype we can test out Shaun? As I would be able to test it out in my own pace.

I see the toolbar and also settings change depending on what is selected.
There might be some discoverability issues as one will first need to click something to have specific options seen, but on the other hand one sees the options needed with a current selected item.

I am wondering if we should have the Navigation structure icon to the right just left of the Save button.... perhaps something similar to this. I also experimented with moving the settings to the right as well.

Purpose: To have the Nav structure open at the same time as one is working on the menu. As one can see adjustments done in one place reflected in the other. The purpose with moving the settings to the right is so that it does not cover the menu below. As one might be editing a menu item and opening the settings panel might cover the item being worked on.

I am hesitant in moving Nav structure icon and the Settings icon to the right as they were nicely grouped in the toolbar with the other icons on the left side.

---

I assume the Rename word seen in the toolbar will then rename the current menu. I am hesitant in giving the word "Rename" so much attention as it gets in the toolbar. What if the name of the menu is there instead? Clicking the name opens a text field to where it could be edited. Similar to I am guessing would happen when clicking "Rename".

Purpose: Rename takes too much attention, as it is the only word in the toolbar. The rest are icons.
Against renaming to menu name. As the menu name is listed just above in the Currently editing drop down.

---

I think it would be better not to have a black background of the current item in the Navigation structure as it creates a very high contrast from what is not selected. Having a more subtile background color would cause less contrast when selecting any Nav structure item. It would also be helpful to add the tree branch lines back again, so it better shows the flow of a top menu item and it's submenu below it.

From the animated gif:

From the current PR:

Perhaps something like this:

(I used it further above in the first mockup.)

I will see what else pops up.

[manmotive]

The latest design looks very nice. My concern is it is a further step away from a 'data' view of a menu structure, which is what the current nav-menus.php page provides. (I am aware the data view is available in the drop down and that themes will be able to output the same block html that is being displayed here)

The current nav-menus.php page is used to create a plethora of styles of menus - off canvas mobile menus, vertical menus, accordion menus, 'bog standard' horizontal menus. I have concerns that at best the primary 'preview' view is going to look somewhere close to the front end menu, at worst it will look nothing like the front end at all. In either case I imagine it would be confusing to a good proportion of users.

In the new designs we are effectively looking at a data view of the menu (as in most cases, it won't reflect what is seen on the front end), but presented as a front end menu. Stepping back a bit, is that the intention here? And from a users point of view, is primarily presenting and managing the menu structure as a 'front end' menu better than presenting/managing it as a purely structural tree view?

[afercia]

Noting that the "Currently editing" select element needs a button and should not trigger changes of context on the change event. See #25312 for more details.