Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make link navigation responsive #22497

Closed
adamziel opened this issue May 20, 2020 · 14 comments
Closed

Make link navigation responsive #22497

adamziel opened this issue May 20, 2020 · 14 comments
Assignees
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Decision Needs a decision to be actionable or relevant

Comments

@adamziel
Copy link
Contributor

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:

Zrzut ekranu 2020-05-20 o 15 45 17

Let's discuss how we could make it better.

@adamziel adamziel added Needs Design Needs design efforts. [Feature] List View Menu item in the top toolbar to select blocks from a list of links. labels May 20, 2020
@karmatosed karmatosed self-assigned this May 20, 2020
@karmatosed
Copy link
Member

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.

More Menu

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

More Menu

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).

Frame 1

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.

More Menu

Iteration 3: inside ellipsis

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

More Menu

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
Copy link
Member

karmatosed commented May 22, 2020

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.

subnav

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 karmatosed added Needs Design Feedback Needs general design feedback. and removed Needs Design Needs design efforts. labels May 22, 2020
@karmatosed
Copy link
Member

karmatosed commented May 22, 2020

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.

icons

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.

Frame 2

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?

More Menu

@talldan
Copy link
Contributor

talldan commented May 25, 2020

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:
Screenshot 2020-05-25 at 4 22 33 pm

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
Copy link
Contributor

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
Copy link
Member

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?

More Menu

@talldan
Copy link
Contributor

talldan commented May 27, 2020

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

@karmatosed
Copy link
Member

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

Navigation

@karmatosed karmatosed added Needs Decision Needs a decision to be actionable or relevant and removed Needs Design Feedback Needs general design feedback. labels May 27, 2020
@mapk
Copy link
Contributor

mapk commented May 28, 2020

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
Copy link
Contributor

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 ✋

Screenshot 2020-05-29 at 08 32 27

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:

Navigation

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

@karmatosed
Copy link
Member

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

@adamziel
Copy link
Contributor Author

adamziel commented Jun 1, 2020

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

@adamziel
Copy link
Contributor Author

adamziel commented Jun 1, 2020

Very first attempt available in #22796

@draganescu
Copy link
Contributor

Closed by #22796

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] List View Menu item in the top toolbar to select blocks from a list of links. Needs Decision Needs a decision to be actionable or relevant
Projects
None yet
Development

No branches or pull requests

6 participants