Navigation Screen: consolidate top bar with the one used in the FSE

[javierarce]

I want to propose using the same top bar as we do in the Full Site Editor. Using the same bar will help us solve some responsive issues we have and, in the long run, make the interface more predictable and easier to understand and to update.

Here's the first proposal:

We could have this simple toolbar that gives access to:

• Undo/redo
• Switching menu
• Save
• Settings

Users switch menus or create new ones by clicking on the name of the menu, which I think is consistent with the Template editor, but we could make the options more explicit with a slightly different version:

The downside of this approach is that the bar is more crowded.

Finally, here's a simple example of how this new top bar would look on the page:

[jameskoster]

I love this initiative, all unification endeavours are a win imo!

So far in the Site Editor, the popover that is exposed when you click the entity name in the top bar reveals options and actions that can be applied to that entity. Resetting a template, for example:

It looks like this heuristic may spread to the post editor as well via #27093.

So it may be that we can migrate the navigation settings here entirely, and reduce the reliance on the Inspector. What do you think?

For switching between entities, the Site Editor uses the sidebar menu (accessed via the W button):

Do you think this could work for the navigation screen as well?

[javierarce]

Thanks for bringing this up, @jameskoster!

I thought about using the sidebar menu, but I didn't suggest it because I felt that the title popover is lighter and could work better for the general use case (which I imagine it's a user with a small number of menus).

But the sidebar has some good features (like previews for each item, search and the add button) that could definitely work here. Plus, if the title popover evolves in a new direction, I think we should consider this idea and unify the interfaces completely.

[jameskoster]

Yeah I think that makes sense. Unify, then refine holistically! 🚀

[jasmussen]

For what it's worth, we've had a top bar, and one of the reasons we removed it was to avoid this looking like the block editor, and to look more like other wp-admin screens.

[jameskoster]

@jasmussen very good point. This speaks to the purpose of this screen, which still confuses me even to this day :)

If it's not something we see it as a component of block-based site editing, maybe the alignment is not worth it.

[javierarce]

I still think is a good idea to move forward with this change. It's not only about consolidating the two interfaces, but the FSE top bar offers a much better design than the current solution. And it's also a more scalable and organized way to offer important features.

We could definitely find an alternative third-way, but since we already have a nice solution, I'd say let's use it :)

[javierarce]

Here's a first look at how the Nav Screen would look using the sidebar. This change would require removing the current sidebar. Also, it would be nice to render previews for each menu (in the following video, I'm just using fake placeholders).

Screen.Recording.2021-04-29.at.18.10.54.mov

We could also remove one step from the menu creation flow using a popover (this is similar to the FSE sidebar)

Here's a link to the prototype above.

[javierarce]

I updated the previous prototype with a new version that doesn't close the sidebars when the user creates the menu.

Screen.Recording.2021-04-30.at.13.05.33.mov

[draganescu]

Howdy friends, it's not clear to me if there is enough consensus here to proceed with trying out such an UI update. Does this "unification" make things better for the block based Navigation editor? Does it matter that it's a completely different experience, compared to all WP-admin and even the new block based widgets editor? Thanks 🤝

[talldan]

It'd be good to get clarification on this.

I personally very much like the idea of unifying. The navigation screen is a similar initiative to the widgets screen which uses the same general interface as the site and post editor. This would ensure the navigation screen isn't the odd one out.

[jasmussen]

It'd be good to get clarification on this.

Happy to take a stab. Much of this is spread across tickets and chats, so I'll recall as best as I can.

These screens are primarily meant to bring the diversity of blocks (and the benefits of the navigation block) to classic and universal themes. But they are also interfaces dedicated to widget and navigation editing, which comes with its own set of limitations that aren't necessarily present in the post or site editors. In other words, while these are technically block editors, they are different.

The argument then, has been, that using the same interface isn't necessarily beneficial: assumptions about how things work from having used the block editor might simply not apply here. Perhaps most importantly: design explorations for these screens shouldn't need to be be predicated on following block editor principles that might not be relevant.

That's the back-story and context for what exists. It should only inform but not block things from moving forward, and of course if design explorations circle back and intentionally land there again, that's valid too. With the widget screen having shipped with a similar top-bar, there's plenty of reason to suggest the navigation screen could/should have a similar interface.

That said, and in my personal opinion, I'd suggest that if it were to be similar it should be more or less identical to the Widget editor, complete with not being fullscreen, and having an explicit label in the top left corner:

[talldan]

That said, and in my personal opinion, I'd suggest that if it were to be similar it should be more or less identical to the Widget editor, complete with not being fullscreen, and having an explicit label in the top left corner.

Those things seem like a good compromise 👍

[draganescu]

What I like of the direction in @javierarce 's designs (besides the fact they're very nice) is that we're pushing WP Admin closer to Gutenberg. "Contrary" to @jasmussen 's perspective above, I would make the widgets editor more like what's explored here and unify in this direction.

[jasmussen]

As a counter counterpoint (😅) I would argue that the transitional nature of these screens makes it all the more important that it shares more DNA with their previous counterparts.

[javierarce]

I've updated the top bar design with several new elements we've been discussing:

• The global inserter button: Add block inserter to navigation editor #34438
• The list view button: Handle heavily nested items in the Nav Editor screen #23583 (comment)
• The menu switcher inside the dropdown: Navigation Editor Tracking Issue #29102 (comment)
• The "new menu" button: Add ability to create a new navigaition menu with a single click #34227 (comment)
• The options button (see below)

I also think we could remove the "Navigation" title that currently appears in the top bar because there are several other indications that inform users that they are in the navigation editor (like the left and right sidebars or the "new menu" link). If we made this change, we should probably replicate it at the Widgets navigation bar.

I've included an "options" button (the vertical ellipsis at the end of the menu) because we could use it to:

• Show the keyboard shortcuts, a welcome guide (we'll need to design it), and a link to a help section.
• Invoke the options menu, as we do in the Full Site Editor when the top bar is very narrow.

We don't need to implement this options button right away, and in the meantime, we can simply show the settings button.

Figma file

[jameskoster]

I still have some slight reservations about re-using the title/dropdown in this context as a switcher primarily.

In the template editor this affordance reveals details about the template and offers no switching. In the site editor it also reveals details and offers a shortcut to view all templates (and switch) as a secondary function. Ideally global elements like this should exhibit consistent behaviour otherwise they can jeopardise the overall UX.

That's not to say that I don't like switching as a primary feature of this dropdown. It actually feels intuitive to me. So I guess my question is about the intent: if we adopt this approach for the navigation screen, should we do so as a test versus the implementation elsewhere? And if successful migrate it to other locations? Or are we happy to introduce the inconsistency acknowledging the fact that this screen exists somewhere in-between the wp-admin and gutenberg "layers"?

Small sidenote: assuming we run with this as designed, I don't think it's necessary to hide the "Create new menu" button in the dropdown on desktop. If we keep it visible then mobile-first folks will not have to search for that functionality when they're on desktop.

[javierarce]

To me, having a way to switch navigations there feels intuitive, too (and has the side benefit of working well in narrower layouts). And even though the action in the Site Editor is secondary, it still feels consistent to me: users opening the dropdown will probably have the same intent (switching). I also think the introduction of the template mosaic view will also reinforce this behaviour.

So, to answer your questions, I'd say yes to implement this solution and see how well it works.

Small sidenote: assuming we run with this as designed, I don't think it's necessary to hide the "Create new menu" button in the dropdown on desktop. If we keep it visible then mobile-first folks will not have to search for that functionality when they're on desktop.

This sounds good to me 👌

[karmatosed]

I am just finding my feet in navigation and wanted to pop my head into this issue as it seems lively. One flow that caught my eye is potentially a little confusing, at least to me as I find my way was this:


My biggest concern is multiple places for things and a fragmented experience for the same cognitive activity. Navigation has always ended up being more complicated than it should be.

I’d love to get my footing a little with navigation, so I really would appreciate being put on the right path as to what the current direction is, maybe a link to a prototype? I see some flat files, but things like this are always great to see the flow of.

My presumption is the latest design in PR is: #34619 but checking. It doesn't seem to have the work I linked above.

[javierarce]


My biggest concern is multiple places for things and a fragmented experience for the same cognitive activity. Navigation has always ended up being more complicated than it should be.

I agree with you 100%, @karmatosed. However, that idea you mentioned was a super early exploration and wasn't really examined beyond that point.

There isn't really an official and comprehensive prototype. Still, you can find many designs and prototypes inside this Figma file. There's also a tracking issue that outlines and organizes the work towards removing the experimental flag here. And in any case, I'm happy to chat over Slack to solve any doubts.

[karmatosed]

@javierarce, thank you so much for catching me up and having patience as I tried to put the pieces together finding issues - I'll dive into that Figma. I had found that tracking issue, which is how I got here, so I agree it's a great central point. Appreciate the offer of continued discussion - it's always appreciated. I will also bring my thoughts to any issues or conversations as they come up in my exploration.

Quickly looking at the Figma, one thing that strikes me is the complexity of the amount for screens like this:

If you consider what the eye would be doing and where the focus (things demanding attention) would be for the person experiencing it, you get a map like this:

Similarly:

The 'save' is disconnected, and so is the 'create new menu'. The '+' is also going to be very far away. A lot is also the same level of attention-demanding.

Am I missing some context or explorations of this being closer to the expected interface where someone is interacting with the menu? I don't want to presume things or comment without knowing the context fully and can't see it in this issue thread.

[getdave]

My presumption is the latest design in PR is: #34619 but checking. It doesn't seem to have the work I linked above.

That PR is literally just adding the global inserter. Refactoring the entire top bar is out of scope there but happy to look at that next 😄

[jameskoster]

It seems to me that there is more value in positioning the [+] and 'Save' button in a manner that is consistent with other editor views. We don't want to keep 'moving the cheese' 😅

Would it also be fair to say that if you have actively opened the dropdown, then it's likely your focus will inherently be there rather than on other parts of the screen? 🤔

Am I missing some context or explorations of this being closer to the expected interface where someone is interacting with the menu?

I think the purpose of this issue is to simply align the top bar implementation with other editor views. Just as other landmark features (e.g. Inspector) are aligned.

[getdave]

+1 to aligning with other editors.

[karmatosed]

That PR is literally just adding the global inserter. Refactoring the entire top bar is out of scope there but happy to look at that next

Oh, that's super helpful to know what to expect in what PR, thanks @getdave.

I think the purpose of this issue is to simply align the top bar implementation with other editor views. Just as other landmark features (e.g. Inspector) are aligned.

That makes sense in principle. The issue is that whilst you can say if you open the dropdown, your attention is there, with the way the interface is created - that's not the case. There's an overall problem with the current flow. Now, this might be aside from this issue, but it certainly is being made obvious by it, so worth exploring. Navigation has this habit of exposing any hitches.

[Mamaduka]

The menu name/switcher consolidation PR is almost ready for review.

@javierarce, based on this discussion #31241 (comment), I removed the "Create new menu" item from the menu switcher dropdown.

Should we replace it with the "Delete menu" button? This is how "Template Mode" displays the delete action.

[javierarce]

@javierarce, based on this discussion #31241 (comment), I removed the "Create new menu" item from the menu switcher dropdown.

Oh, but we agreed to keep it visible at all times. I think adding a delete button that only appears when in Desktop mode could be confusing.

[Mamaduka]

I thought it was agreed to keep direct action "New menu" visible at all times. Do we need to "Create menu" action buttons?

It's a small change so no problem to bring the Dropdown button back to the screen.

[javierarce]

Let me try to explain the whole thing 😅

My initial idea was to have "New menu" visible in the top bar and hide it if the viewport is very narrow. In that case, we would also show a "Create new menu" button in the dropdown… but James pointed out that we could instead show "Create new menu" at all times in the dropdown, which makes sense to me (and I think it will also make the implementation easier).

This Figma frame contains the updated version of the design.

[Mamaduka]

It makes sense, and thanks for the explanation. I'm going to add "Create new menu" button back 😄

[talldan]

What's left to do on this one?

From what I can see there's no editor 'more' menu, but I think that can come a bit later.

[Mamaduka]

I think that will be part of the #34859.

[talldan]

Could be good to close this if the only task left is now tracked by another issue.

I think #34859 needs prioritisation on the tracking issue and some design feedback. IMO, it's probably not a blocker for removing the experimental flag (the widget editors also had no settings while live in the Gutenberg plugin).

[Mamaduka]

I agree with @talldan that we can close this one. The "Preference" panel issue doesn't need to have high priority.

[getdave]

Ok I"m going to close this one out. @javierarce let us know of any follow ups that you'd class as High.