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

Replace nav-menus.php with interface based on Navigation block #19170

Open
noisysocks opened this issue Dec 16, 2019 · 24 comments
Open

Replace nav-menus.php with interface based on Navigation block #19170

noisysocks opened this issue Dec 16, 2019 · 24 comments

Comments

@noisysocks
Copy link
Member

@noisysocks noisysocks commented Dec 16, 2019

With Full Site Editing and the Navigation block, users will have a very intuitive interface for creating and editing menus. Not everyone will be able to access this, however, because some may not want to or may not be able to install a theme that supports Full Site Editing.

We should therefore investigate replacing the menu interface in nav-menus.php with a new interface built using the same components that the Navigation block uses.

This is closely related to the work in upgrading widgets.php to support blocks.

Consideration should also be given to replacing the menu interface in customize.php.


nav-menus.php screen:

Screen Shot 2019-12-16 at 14 35 49

Navigation block:

Screen Shot 2019-12-16 at 14 47 06

cc. @mtias

@shaunandrews

This comment has been minimized.

Copy link

@shaunandrews shaunandrews commented Dec 16, 2019

Would we want to display something very similar (if not exactly the same) as the Site Navigation block's UI? Or would we consider adding additional or different UI to this screen?

@mtias

This comment has been minimized.

Copy link
Contributor

@mtias mtias commented Dec 17, 2019

Would we want to display something very similar (if not exactly the same) as the Site Navigation block's UI?

Yes, that's the idea. The main addition would be the aspect of locations, which should only be handled in this screen.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 17, 2019

I wanted to clarify a few things in sketches before moving into mocks. Right now there are a few things going on within this screen:

  • Creating a menu
  • Assigning menus to locations

The assignment comes in a few places:

  • Tab section for locations.
  • Assigning based on each menu itself.

I would like to propose going to a 2 screen format and have a couple of considerations for this in sketch format (neither I think is there yet but good to consider what would is ok to move around):

  1. This removes the location tab completely and has the only allocation on existing menus. Each menu would be listed once made at the side with opening to allocate:

image

  1. Over specific menus and going in to add location, this version has locations listed at side you then select the menus.

image

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Dec 17, 2019

What's it gonna take to deprecate menu locations?

(edit: I say this aspirationally as someone with no authority on the matter)

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 17, 2019

I am not suggesting we deprecate as much as pick one way to add locations. I might be missing a reason but having 2 ways to do this feels excessive. The same duplication is also in the customizer:

image

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 17, 2019

There is potentially a sensible flow here where once you've made menu, choosing location makes a lot of sense. However, what I am not convinced of is that you need a totally different screen or place to then change locations.

@MichaelArestad MichaelArestad added this to Needs design in Full site editing Dec 17, 2019
@karmatosed karmatosed self-assigned this Dec 17, 2019
@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Dec 17, 2019

Having menus and locations separate is one of the single most confusing aspects of working with menus in WordPress. I've seen this in usability testing, and heard this from support folks. It's super common for someone to create an entirely new menu when they mean to add a page to an existing menu. The difference isn't at all clear. Regardless of how we tackle this issue, it needs to be fixed in any future iteration of menus, IMO.

@MichaelArestad MichaelArestad moved this from Needs design to Needs design feedback in Full site editing Dec 17, 2019
@karmatosed karmatosed moved this from 🗂 To do to 💻 Issues in progress in Navigation block Dec 18, 2019
@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 20, 2019

I spent some time with this and started at the work that's been done to bring widget into wp-admin by @mapk in #3204 after he recommended unifying with that. It's worth noting these are still early ideas and not full mocks or prototypes yet. Once feedback is given I will work into a prototype each section as there are flows that need visualising.

image 7

Version 1

My first point was to take a more literal approach, taking what was in the widgets screens and applying the navigation block.

version-one-likewidgets

v1-2

This doesn't work because the navigation block needs a bigger space to interact with; it doesn't reduce well. Similarly, there are additional flows to the widget screen in navigation on top of adding to a location.

  • Creating a navigation block (you don't create a widget).
  • Editing navigation (you don't edit a widget).

Version 2

The wider canvas to the side solves the space issue so I moved into that for the second version. This version keeps the '+' though and has the problem of multiple versions of those still that the widgets screen has. It does divide actions more into 'editing/creating/locating'.

versiontwo-middlepoint-icons

Version 3

Taking the past version, I iterated a little. Worth noting here is to create and edit there is a moving of the navigation block and arrow indicator to connect to the side panel. I also forced adding only in the one place so there are clear, distinct flows.

versiontwo-lessicons

With a frame:

Frame 11

Version 4

This version takes it all back a little to what is there currently, the text brings in menus and there is a button over the '+'.

versionthree-buttons

It's worth noting this also brings back 'live preview' which I am not at all sure we need anymore but we might if looping back to Customizer. Here is what that looks like not there. I also made it a link over a button, which might be something to discuss.

versionthree-buttons-nolive

Next Steps

There are a few options. I would love some feedback but if we can keep it to the context of:

  • This screen has to be done.
  • What can we create as a minimum here and build up from? This screen might go over time and is needed sooner over later.
  • What existing patterns can we use?
  • How much can we soothe this experience over create a jarring new one?
  • Whilst everything is 'open' in these screens could there be a more locked down flow? Would that cause issues or would that be easier?

My feelings are that version 3 or 4 are the ones we should look at deciding between.

@noisysocks

This comment has been minimized.

Copy link
Member Author

@noisysocks noisysocks commented Dec 20, 2019

What existing patterns can we use?

Is it a common occurrence that one menu is re-used in multiple locations?

If no: Perhaps we could re-use the existing Block Areas pattern and simplify this screen to show a Block Area containing a Navigation block per location, e.g:

One Navigation block per location

If yes: Perhaps we could riff off the Block Areas pattern and show one Block Area per Navigation block along with checkboxes that associate the Navigation block to one or more locations, e.g:

Multiple locations per Navigation block

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 20, 2019

Is it a common occurrence that one menu is re-used in multiple locations?

I think this really depends on what use a site is for. Typically I think we might be able to say no.

Your mocks are interesting, a more literal take and stepping even further from what there is now.

I do wonder though if those using this screen aren't expecting an experience that's more building? I also notice seeing multiple navigation blocks is causing me to have quite a reaction against it. Similarly, a giant '+' space is.

Copy wise deciding on what language we use here is key, I went for navigation but we could in this case use menu.

@noisysocks

This comment has been minimized.

Copy link
Member Author

@noisysocks noisysocks commented Dec 20, 2019

Copy wise deciding on what language we use here is key, I went for navigation but we could in this case use menu.

It probably makes sense to move away from the word menu as it has so many meanings. Those poor restaurant owners who are using WordPress! 🤯

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Dec 20, 2019

Not at all a final version but iterating on from your visuals @noisysocks:

01

2

If we had them 'inside' then lengthening the menu locations makes sense:

3

@melchoyce

This comment has been minimized.

Copy link
Contributor

@melchoyce melchoyce commented Dec 20, 2019

What if all new menus became reusable by default? If you want to reuse a menu in a different location, you could have the open of selecting an existing menu within the placeholder.

Side note: I don't think "a Navigation" works, grammatically — I think "Navigation Menu" would be more clear.

@shaunandrews

This comment has been minimized.

Copy link

@shaunandrews shaunandrews commented Jan 8, 2020

Spent some time exploring, and wound up with this:

Gutenberg Menus Take 2

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 8, 2020

Interesting exploration @shaunandrews. I have a few thoughts about it so going to just list those.

  • What are the cog and ellipses for if this is in wp-admin?
  • How would you add a new menu? I have a feeling the above might lead me to knowing that....

I feel that we need to be careful in wp-admin based on conversations and feedback so far to not remove existing functionality, which means a balance. I am also not sure this looking like an editor works, that might be because I need to think about this mental model though.

There are also going to have to be some technical thoughts around how we bring styling in here.

Overall I feel the zoom in to focus is a little jarring as an experience. Perhaps that's a case of iterating the animation though.

As the original v1 of this was to bring in close alignment to widgets, its worth consider do we then iterate widgets if we go in a different direction - we just might.

@shaunandrews

This comment has been minimized.

Copy link

@shaunandrews shaunandrews commented Jan 8, 2020

What are the cog and ellipses for if this is in wp-admin?

It reuses patterns from the editor. The cog opens the sidebar inspector pane, with options (shown below) for the currently selected Navigation block or the Navigation Area settings (not shown/designed). I haven't given too much thought to the ellipsis icon, but I imagine it could expose similar options as the editor's more menu, like full screen mode, help and others.

image

How would you add a new menu?

In an effort to simplify, I decided to try working around the need to create a menu in isolation. Instead, you'd create a new menu but selecting an empty Navigation Area (showing the normal Navigation block setup state), or when changing a menu assigned to an Area.

image

@draganescu

This comment has been minimized.

Copy link
Contributor

@draganescu draganescu commented Jan 9, 2020

I wonder if it would make for an easy start to simply replace all the drag and drop things with the new navigator which shows us navigation hierarchy:

Screenshot 2020-01-09 at 15 55 34

This will not be a permanent solution, as the point is closer to what @shaunandrews explored above where we'd get nice previews of "locations", but instead a nice intermediary step.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 9, 2020

@draganescu as we are close to a design solution I wouldn't suggest that approach right now. It is a bit of a complicated mixture of interfaces in your screenshot, whilst I understand the motivation this would cause some experience issues. I think we can come up with something and just follow that over have this step which I don't think is of a benefit in this case for usability.

Now, if you would have to code it anyway, then you can, of course, begin that, but having it exposed to anyone to interact with would be something I'd advise against.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 9, 2020

I wanted to raise this thought... 🤔

Do the Gutenberg Widgets screen and the Gutenberg Menu screen need to be different at all? It's really just adding blocks to block areas that the theme has registered.

Why not just call the experimental widgets screen that currently exists in the plugin: "Block Areas" (as it's titled in the page) and utilize that for adding any block to any other part of the website that is not currently registered in the Editor?

PROS:

  • Saves us major development time on screens that will deprecate in the future anyways.
  • Already got the Widgets screen designed.
  • Covers most areas that a Navigation block may need to exist (ie. Footer, Sidebar)

CONS:

  • The current Widgets experimental screen does not cover the Header so we'd most likely need to add that.
  • Same Nav block in multiple areas can get a little tricky.

Example of adding a Navigation block to a Block Area

nav-menu 2020-01-09 12_46_30

The color is pretty washed out, but I think it still gets the point across.

If I've missed any of this in the discussion, please forgive me. I just wanted to share this thought while it was ripe. 🥝 There may be additional factors I've not anticipated with this solution causing it to become moot.

@karmatosed

This comment has been minimized.

Copy link
Member

@karmatosed karmatosed commented Jan 9, 2020

This is just some feeling feedback right now but I think the more these look like editors the more awkward I feel. That's possibly fixable by some distilling back but worth considering as we work on this.

Do the Gutenberg Widgets screen and the Gutenberg Menu screen need to be different at all? It's really just adding blocks to block areas that the theme has registered.

This isn't an easy question to answer and might come down to mental models. For example, there might need to be a middle point where people get to still do both. A good conversation to have though as this is explored and get feedback on.

I do think the current widgets have a few repeating UI elements the recent explorations are distilling away from, which is great. Whilst I know it has a design, I think we could simmer that a little, which is of course easier than starting from zero.

@shaunandrews

This comment has been minimized.

Copy link

@shaunandrews shaunandrews commented Jan 10, 2020

Why not just call the experimental widgets screen that currently exists in the plugin: "Block Areas"

I think we're on the same page here. Whatever UI we come up with should be able to handle Widget and Menu area — which are really just "Block Areas". My biggest concern there is that we need a better way to list all the areas.

Also, I don't think its going to be feasible to let people update/save multiple areas at once. At least, not from a UX standpoint — I really worry about multiple entity saving and how we expose that in the UI. The designs I posted above separate the two actions; Listing areas and editing an individual area. I have more thoughts/work to share on this soon.

@draganescu

This comment has been minimized.

Copy link
Contributor

@draganescu draganescu commented Jan 11, 2020

I think @karmatosed has a point with mental models as this separation between menus, widgets and "content" has been central to how WP organizes content.

It is also true that menus are basically a particular widget in a sea of widgets, so @mapk 's idea of having one place to manage both makes a lot of sense:

Screenshot 2020-01-11 at 14 55 12

Also with FSE widgets will have an uncertain use, while menus will remain central to making a website no matter what.

I personally like @shaunandrews 's take on editing one area at a time and adding the sidebar to the mix helps with one problem I have, that when I am building a website's menu it doesn't feel like a visual activity, more like a structuring process so I would love an easy way to use the new navigator and see the full tree of the menu.

@mapk

This comment has been minimized.

Copy link
Contributor

@mapk mapk commented Jan 13, 2020

I think the mental models argument is a total valid. It's been brought up here more than once. And for that reason, I think it's safe to say that the legacy widget and menu screens won't be going away anytime soon.

But then we have Gutenberg full-site editing that brings much of this together into a unified interface where the mental model may not change in context to screen changes. Maybe the screen changes to show a particular Template Part separately, but it doesn't have to.

So looking at this as a way to bridge that gap, we can align with the Gutenberg principal, all blocks are created equal, and structure this one screen as a way to add any and all blocks to other areas of a site that aren't yet supported in the Block Editor.

@noisysocks

This comment has been minimized.

Copy link
Member Author

@noisysocks noisysocks commented Jan 16, 2020

What I like about a lot of these mockups so far is that we're trying to de-emphasise the really unintuitive UI where one has to assign a menu to a location 🙂

Do the Gutenberg Widgets screen and the Gutenberg Menu screen need to be different at all?

I like this line of thinking but it will require some technical exploration to see what's possible. My concern is that existing themes have been built in a way that assumes that only menu markup will ever appear in navigation areas. We may need to restrict "navigation block areas" so that only the Navigation block can be added to them.

  • Saves us major development time on screens that will deprecate in the future anyways.

I don't think the second part of this is true. I anticipate these screens will stick around forever because it is how sites that run older themes that don't support Full Site Editing will access the benefits of using blocks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Navigation block
  
💻 Issues in progress
Full site editing
Needs design feedback
7 participants
You can’t perform that action at this time.