Make link navigation responsive

[adamziel]

Is your feature request related to a problem? Please describe.

With a few levels of nesting and long labels, this is what we get on the experimental navigation screen:

Let's discuss how we could make it better.

[karmatosed]

I am going to tackle this in 2 design explorations. The first is going to be iterating on the block navigator to make it adapt easier and have lighter experience. The second will be looking at some little adjustments to make the sub-navigation experience on the navigation block refined.

First, props to @mtias for pointing me towards Squarespace for inspiration here. In stepping through their navigation experience a few things struck me as iterations we could bring in:

• A lighter interface
• Having sub-navigation show and hide over be 'always on'

There are a lot of other possibilities, but for this issue, I am focusing on what could soothe right now. I will be adding some more mocks for other aspects.

I also reviewed existing components and took a wider screen that we use now for the library. This would technically mean increasing on this screen so it's a point to note in decisions as I look for feedback.

Before I dive in, I would love to know what is desirable for v1 and what we can work towards. I think quite a bit of what I am suggesting falls into iterations over adding new functionality, however, I would love to check on what we pull into actions.

Iteration 1: A lighter interface

The first iterations shows a few things:

• '+' for top-level link adding goes by title.
• Unless sub-navigation no lines show.
• Remove repeating icons.
• Movers go to left side in a wider gutter.
• Ellipsis goes to the right side in the same wider gutter.
• Sub-navigation is indicated with a smaller tree, with a lighter shade.

Now, this does have a minimal '+' at top, we might want to bring in the darker one, that could look like this:

Adding sub-navigation is done via a link from ellipsis in this version.

What does this look like on the above screen? Here is a very rough mock with the narrow width still, just to show how it could fit (although I do advise we go wider).

Of note, in my prototypes it doesn't highlight the current item like we do using a darker background, that could be added however in the examples I was working from this wasn't something implemented so I decided to see how light I could go.

Iteration 2: + by sub-navigation

This takes sub-navigation adding out of the ellipsis and brings to the bottom of the tree view.

Iteration 3: inside ellipsis

One final iteration brings the ellipsis into the inside of sub-navigation indication.

Hitches and hurdles: nesting sub-nav

There is still an outstanding problem with nesting sub-navigation. With this iteration and lighter interface we can get comfortably far more nesting. However, the problem at some point will raise its head. There are a few potential options:

• Bring in horizontal scrolling.
• Over a certain number of sub-navigation nesting don't show tree or indenting. This would be similar to nested comments.

My own feelings are that limiting over a certain number is acceptable behaviour within WordPress, however, I would love other insights.

Feedback

I would like some specific feedback on a few things, more general thoughts and input is of course welcome.

• What tasks should be pulled out from this to move into development?
• What are things, for now, to put aside and focus on later?
• What doesn't work and shouldn't be implemented?
• Which iteration out of any do you feel is the one to pursue?
• Which sub-navigation nesting route would you prefer?
• Should the first levels of sub-navigation be closed or open by default?
• Is making the navigator wider a possibility within the nav-menus.php screen or is there a technical limitation there we need to keep it narrow for?

[karmatosed]

Along with some iterations to the block navigator I think a few small adjustments can be done to the navigation block itself to lighten up the interface.

• Consider bringing the same arrow treatment in for sub-navigation in block navigator.
• Remove gap of sub-navigation.
• Reduce spacing around menus.
• Align sub-navigation more closely with parent.

This is a small visual improvement but could link the two together more in experience through using same showing arrows and also allow for less visual density.

The same 'limit' on nesting might be something we want to consider as a visual here, but that's a point to decided in block navigator and see where we go here.

Feedback

Really these changes are pretty minor so I would ask for general feedback, along with these points:

• Is uniting the arrows a good step or step too far?
• What other things could be done to ease this screen as it grows in nesting of sub-navigation?

When thinking of other things, consider this an iteration and how can we within the existing interface ease this experience.

[karmatosed]

Adding a second iteration to block navigator work after some feedback and surfacing of the hit areas for icons that @jasmussen noted in ellipsis issue. Props to @mtias for feedback.

A few points to this iteration:

• Brings back icons which will be important as have different block types (future). I do wonder if we could indicate if post or page (later iteration).
• Brings sub-navigation opening to the menu itself.

Increasing the size of hit area on movers

Here are a few variations on increasing spacing to increase the hit area. This will need tieing into the work there.

@jasmussen going to loop you in for feedback on spacing, movers and what iteration/line spacing works best based on the current direction. I think it's important it aligns.

Another option is side by side, but this is confusing with the arrow for sub-navigation. Perhaps this is really a case of in the movers issue having that decided and then iterating here?

[talldan]

One thing I've wondered is whether we need the connecting lines. There are some examples of tree like structures that are expandable don't have the connecting lines between parents and children and instead have the expand/collapse icon in that position.

e.g. Figma:

I still think the hierarchy is clear in that screenshot without the connecting lines.

Usually it's down facing arrow for expanded and right facing arrow for collapsed. I know that's different to other WordPress UI (like panels), but maybe that's acceptable here.

I quite like the highlighting of the selected item and its children (in a lighter tone) in the screenshot above as well. That makes sense to me, particularly in respect of duplicating/moving/removing, as it makes it clear those actions on the parent affect all children as well.

[jasmussen]

The reduction overall is very helpful. In that vein, @talldan, I think your instinct is right and it would be interesting to remove the lines entirely, and put the chevron on the left of items that have submenus, but otherwise rely only on the indentation to indicate the hierarchy.

I'd also use the same behavior — right facing chevron or arrow when collapsed, down-facing when open.

I think we should avoid up/down movers side by side. It takes up precious horizontal space, and it removes the connection it has to the block movers. I think it's okay to use a full 48px for each item, it sticks to the grid and affords some simplicity and space.

I'd also put the ellipsis right-most. This is a pet peeve of mine, that "more" always comes at the end.

[karmatosed]

I took a little moment to try and mock this up to see if I am understanding clearly. @jasmussen and @talldan does this fit your ideas?

[talldan]

@karmatosed Yep, that looks very much like what I had in mind. What do you think?

[karmatosed]

Just going to post some iterations that @jasmussen worked on and I gave some feedback. This is taking the current work and iterating.

[mapk]

Things are coming together here! Thanks for iterating.

I could go either way with the tree connecting lines. I like them, but also understand that this little Navigator is getting cramped with UI elements. So if removing them helps keep things light, let's do it.

I'd like to see another iteration around those mover arrows. The balance of spacing in between them as compared to the spacing above or below them is awkward. They feel much too close to the edge and very far apart from each other. Using the smaller arrows in this case may help this.

I think the images are just not zoomed at 100%, but nevertheless wanted to point out that the font size is extremely small. My guess is that zoom is the problem, not the actual font size. :)

The order of UI elements is strong. The smaller carrot on the left side and the movers and ellipses on the right side make for a good balanced layout.

I'm also glad to see the black + icon back in there because it's consistent with the Inserter icon elsewhere.

[jasmussen]

Great thoughts, Mark, thank you.

The mover PR is fast coming along, and is working reasonably well with the icons from the icon component, it might be worth trying to use the same icons there first, and if we decide they're too big in both places after trying it out, we can update both of them at the same time. I volunteer as tribute ✋

In the mean time, I can't believe I missed the off balance of those arrow — great eye. I adjusted them to match exactly the configuration of the new mover control you see above:

What do you think? I think it strikes a good balance, and buttons remain 24x24!

[karmatosed]

I like those iterations @jasmussen and would like to get them in so can experience.

[adamziel]

I'll have a PR for that today :-)

[adamziel]

Very first attempt available in #22796

[draganescu]

Closed by #22796