Iterating the navigation block: distilling and sub-navigation options

[karmatosed]

The current implementation of the navigation block has a number of open issues regarding functionality and how it looks. In order to take a more holistic approach, I decided to start exploring how far back this could be distilled and where potentially sub-navigation could go from here.

These are going to be some initial ideas to share, get feedback on and hopefully fairly rapidly get into a direction to prototype. This is sharing early work, sketches over anything set in stone. The framing is around iterating, there are 2 specific areas of focus:

• Starting state from an empty menu
• Sub-navigation

I will be exploring in another issue adding an option. whether we have a placeholder or not. For this issue, I want to focus in on those 2 areas as they are large in themselves and present some options to get feedback on.

Current state

Distilling down

The initial state when you select to create an empty menu right now could be reduced to this:

A simple '+' would then lead to the opening of the link interface and the text can appear:

There's nothing that new here, it's refining using the iterative styling brought in from the great work done by @pablohoneyhoney and @jasmussen

Distilled further

Taking the distilling a little further, the design could follow this path:

There are a few points to note here:

• Only one + appears at a time.
• To add sub-navigation you have to click the link then the 'sub-navigation' icon.

Beyond distilling: using the navigator for adding links

Visually adding links even if distilling happens is going to hit a critical mass of problems. Eventually, it's going to fall to the hitches of threaded comments and other responsive interfaces. There is an optional interface that doesn't have these issues, the block navigator.

Currently, using this to add links is a better experience and perhaps this raises the issue of should it be the primary method? There are some explorations that follow into how potentially this could, in fact, be the primary. method.

Before I share these, it's worth adding that there are a number of issues to improve the navigator and those are important to have this be a primary interface, specifically:

• Being able to edit the text of links.
• Being able to remove links.

Modals

The following are just a couple of early examples of how this could work:

Prototype

Props to @MichaelArestad for taking these idea seeds into a prototype. Here is what this could look like:

Feedback

There's a lot in this issue, but the points specifically looking for feedback on would be around if the distilling works and whether the navigator as the primary interface is an idea worth taking further. Similarly, if this sparks any ideas or you have some mocks please share them.

It's worth noting that these 2 ideas can be separated from each other, I have joined them in this issue as there is an iteration to sub-navigation even with the simpler interface.

After some feedback on this, I would like to get a plan of how to bring in what is decided. This might be through splitting into smaller issues, or through focusing on this one. However, it would be great to get this in as soon as possible, to soothe some of the hitches to the experience today.

Props to @jasmussen, @MichaelArestad and @mapk for some early idea exploring around this.

[jasmussen]

Nice work!

Personally I increasingly believe that the interface for adding submenu items directly inline is a failed experiment, and that all of it should happen in either a popout menu or a dialog, so all of the "navigator for adding links" thoughts feels the most fruitful to me.

That's not to say the other can't be made to work — given the goal is to make the editor as much like the frontend as possible, then nothing's better than inline. But that also means submenu editing has to look like the frontend, whereas now it's simply a plus button that sits beneath a menu item, where on the frontend you'd never see that.

The initial state when you select to create an empty menu right now could be reduced to this:

One thing to explore here is: what does an empty navigation block look like when unselected? A separate discussion has been about how the placeholder components all look alike when you squint and how they don't scale to narrow contexts, which is especially important for a navigation menu which usually sits in exactly that. Social Links accomplishes this albeit in a contested way by pre-inserting some child blocks. Is there a different approach we can take?

Also just a small note on https://user-images.githubusercontent.com/253067/79747167-24935f80-8303-11ea-8644-3d239fd4bdf0.png — I believe the way we currently indicate "this button opened a menu" is to simply color the icon blue, not do the black background.

[karmatosed]

Also just a small note on https://user-images.githubusercontent.com/253067/79747167-24935f80-8303-11ea-8644-3d239fd4bdf0.png — I believe the way we currently indicate "this button opened a menu" is to simply color the icon blue, not do the black background.

Thanks for context, we do. I was wondering if it could be more prominent but that is rightly a better discussion for another issue, focusing on existing interactions for now here.

[jasmussen]

Agree on both!

[enriquesanchez]

A big +1 to using the block navigator UI to add links. That interface is familiar and easier to interact with.

[mapk]

The modal flow is solid! 😍 Showing the modal right below the subnav icon (and above the menu) ties together better than having it appear below the menu item IMO. It fits the patterns we've been using – the popover appears close to the element that triggered it.

Regarding the submenu popover, once opened, would I be able to add a submenu item under any of the top-level menu items without having to select each one initially? I ask, because in the mockups, I don't see any inserter icons under any of the top-level items. I'm curious how that interaction would be.

I wasn't clear on how I'd add a submenu item to the top-level that I selected based on the mockups, so I tried to visualize this a bit further. Let me know if this is what you're thinking...

So from this popover, I envision being able to click on any top-level item and get the blue outline with a submenu inserter icon. I hope this makes sense.

[karmatosed]

Thanks for your thoughts @mapk. I agree with iterating the block navigator as part of this. Just going to also connect #20748 as that ties nicely into the flow.

With this feedback, let's flag this for development and see about getting a feel for it. There feels like enough agreement to boost there.

[karmatosed]

Just linking in #20807 as hopefully something this eases.

[dwolfe]

Sorry I'm late to the party here, but just to add a couple of thoughts:

the points specifically looking for feedback on would be around if the distilling works and whether the navigator as the primary interface is an idea worth taking further.

As you suggested @karmatosed, I think these are two separate issues and each deserves its own discussion. Having said that, RE: distilling the interface, I think this goes too far:

Without getting into the wider discussion about empty states, what's the value of an empty Navigation Block, specifically? Especially when a user clicks to add a Navigation Block, I think we should assume that they intend to fill it with Navigation Links, and requiring an extra click to start creating the first link seems like unnecessary friction.

A big +1 to using the block navigator UI to add links. That interface is familiar and easier to interact with.

I'll contribute more thoughts on other issues dedicated to the block navigator, but I'll just add my voice to the +1 chorus here.

[talldan]

I definitely think the flow presented in this design makes nested menus a lot easier to manage for a user:

But I think there are quite a few more challenges to solve if this is the primary way to edit menus:

• How does a user add formatting to link text and what does it look like?
• How does a user add or edit the link's destination?
• How does it look once block movers are added in (Reordering of blocks inside block navigation #11408) and possibly also support for nesting/unnesting (Moving nested blocks out of their block container is not possible with keyboard only #21960)
• How does a user remove or duplicate one of the nested blocks.

Then I also wonder how this aligns with the navigator in the post editor which exists specifically for selecting blocks in a post at the moment, which is something this doesn't do at all since the items in the list are the blocks now. It feels like a very different interface.

So I definitely have a lot of questions! 😄

[karmatosed]

@talldan Thanks for the questions, I am going to go and create a prototype hopefully to answer all those in one flow. Will post once have that here. I think a visual will help explain easier.

[talldan]

Thanks @karmatosed, look forward to seeing the prototype!

[karmatosed]

After collaborating with a few people and bouncing some ideas around, I now have a walkthrough to show what happens adding a sub-nav. This is an evolution of the ideas shared previously, so continuing here over starting a new issue.

The root of this is bringing adding, editing and deleting of links into the block navigator interface. This makes it a 'one-stop' for managing links. To do this, falling back on mobile interfaces and thinking of the sliding in of screens makes a lot of sense. What if the block navigator had 2 screens?

1. The tree view: where you can delete, copy and reorder.
2. The add link interface: where you can edit, add a link, pick from a list of links, set link actions like opening in new tab.

There are a few new screens here, I am going to call them out so can use them in the later text below:

New link adding interface

Block navigator iterations

This includes the new movers from #21935 and also has an ellipsis which can delete and copy a navigation link.

Stepping through the flows

Let's walk through in-text some flows for clarity:

• If you want to add top-level navigation you click the '+' and the new (shown in the flow) link adding interface appears.
• If you want to add a sub-navigation you click the link where you would like to be under, for example, 'dogs', then click in toolbar 'sub-navigation'. Then the link adding interface appears.
• If you would like to add under an existing sub-navigation you would click into that group through the arrows and then add using the link adding interface by clicking 'sub-navigation' icon.
• If you want to delete a navigation link when in the block navigator you would do so from the ellipsis.
• To edit an existing link you click it and then the link interface appears (no need to go within the block navigator for this). This is unchanged from existing behaviour.
• To edit an existing link within the block navigator you would click and the new link adding interface would appear.

Things to consider

There are a number of points to consider as this work moves into code. I would note, that I think this should be worked out in prototype though over stall that happening:

• What happens with keyboard navigation, specifically moving in and out of sub-navigation groups? cc @tellthemachines for some insights.
• Does a '+' icon need to be added to the sub-navigation or is clicking the icon enough?

Along with the above, there is likely more to come in feedback. There is also a consideration over the block navigator in the sidebar, this would also evolve to have this functionality. This would then need to be iterated and explored what the experience of having this 'adding link' interface is like there, over a toolbar.

Feedback

Specifically, I would love feedback on how to move this forward. These steps are a starting point and if anything else needs clarifying let's discuss it and see if we need more walkthroughs.

Technical wise, I would love @talldan and others to give insights there to any issues they feel this iterated flow creates.

As a final note, props and thanks to @MichaelArestad. @enriquesanchez. @jasmussen and @mapk for the feedback working through this. Thanks to @talldan for the awesome feedback that saw this idea spring from.

[mtias]

Please, let's try not to couple everything together just yet. We should continue to make the navigator work for adding, manipulating, and reordering elements, but let's not replace the in-canvas interactions which are crucial to continue to improve the block API and its UX. Both should remain possible as each have their own set of tradeoffs.

It would be super weird if clicking the "add submenu" int he block toolbar would conjure a floating dropdown menu with a duplicated navigator:

Let's keep the navigator as a side interface so we can improve upon both set of interactions. There are still a lot of missing gaps that should be addressed first:

• The action to add a sub-menu should be available in the corresponding navigator item (either in the ellipsis menu or as its own button).
• The ellipsis menu in the navigator UI should replicate the block ellipsis menu (duplicate, remove, etc).
• Child block appender should have a label: Inner Blocks inserter on single-child blocks #20728
• The sub-menu dropdown should have a background set (seems to be lacking it in master).
• We need to add to drag and drop from the block itself (not the toolbar), at least in "selection" mode.
• We should try to list the currently set link on the block toolbar for extra clarity.

[karmatosed]

Thanks for the feedback @mtias. Let's then leave this as future potential and get a refocus back on iterating. I will check there are issues for anything needs iterating there, including the block navigator ellipsis menu (there's only one for movers as far as know).

[noisysocks]

What's left to do for this issue? I see that some of the items in #21727 (comment) have been addressed in master.

[karmatosed]

@noisysocks this probably should go into future consideration over be actioned now. I am happy to close, but it could be nice to leave open as an iterative idea to come back to, but low priority.

[draganescu]

I would like to close this for now as the direction has been slowly shifting. It will still be a good reference, but better off closed as an issue. Thanks @karmatosed and @mtias, a lot of issues spun off this thread :)