Iterations to the manage locations screen for menus

[karmatosed]

This is using the experimental screen, latest trunk build, so I am aware that things might be in a state of flux. With that in mind, I think several improvements can be made to the manage locations screen to make it easier to handle. For context, here is what this screen looks like with just 2 menus locations:

There are some issues first off that strike me useful to iterate:

• Avoiding having to repeat 'edit.'
• The placement of the edit buttons against the primary update

Overall this modal once clicked, and the fact that you have a secondary and delete secondary button in the sidebar, it all feels a little much. Perhaps the solution could be no modal?

I share this as a suggestion to get feedback on and consider what could be done here and know what is planned - because I am aware this screen and feature are in progress. Maybe going even further than the screen above and removing the delete from below (you have to scroll a lot to get there)... my point is there feels like a lot of space to explore that could avoid more modals, so I'm curious what others think.

[talldan]

This was indeed something iterated on very recently (the update button was added just yesterday).

There was a brief discussion on the tracking issue (#29102 (comment)) about moving this UI elsewhere. I'm not sure if there are still plans to do this (cc @javierarce @kellychoffman)

My thought is that the main UI of the editor (everything below the topbar) and particularly those sidebar settings are aimed at editing a single menu. By contrast the Manage Locations UI is for managing multiple menus at once, and so is really a higher-level interaction. In terms of a user's flow when editing, managing all menus or locations is very likely to be a separate interaction to editing a single menu. It happens after that process or as a completely separate interaction. I think the current UI does make sense, being able to manage all menus is a convenience from the very similar UI of managing the location of the current menu.

I also agree with @kellychoffman's point of view that this should also be a higher-level interface since a user might want to update menu locations without editing the contents of their menus at all.

I'm not sure where it would live though—I think we're at risk of making the editor very busy.

[karmatosed]

Thanks for the update @talldan and that context is super helpful.

My thought is that the main UI of the editor (everything below the topbar) and particularly those sidebar settings are aimed at editing a single menu

That is a solid sense, with that logic I would advise moving those buttons out as until then it's still a combination. I actually like the idea of moving them out of the sidebar, but as so much was still there it felt better to add them as a section over another modal. Yet more modals to me aren't the best option.

I think the current UI does make sense, being able to manage all menus is a convenience from the very similar UI of managing the location of the current menu.

I'm not super convinced it does make sense or at least I think it needs some work around it to make it easier.

@javierarce and @kellychoffman it would be great to surface the plans for what is going into the MVP here as it's hard to not judge what we have now based on what see merged without seeing them in an issue.

[kellychoffman]

what is going into the MVP

Hey @karmatosed! I did a UX review on the current status over in Issue #29102 (comment) and noted which items should be addressed before this feature can be considered out of experimental mode - MVP is probably a better term for that. Curious to hear your thoughts as well and if there's anything missing.

[karmatosed]

@kellychoffman cool, I saw that. I would probably recommend pulling them out into individual issues to make it a little easier to follow perhaps over be deep inside a long thread? It might just be myself but I find those checklists really hard to follow in those deep threads, over using the project boards with tasks - it's a bit easier to see MVPs that way.

That said, I think a lot of the issues I am noting are also important to ensure that the iterated version is also just as usable as the existing one.

For example, this one and:

• Indicate to users when menus are saving #35003
• Only show one + at a time on link adding #34962 (which I realise is link interface but they are closely tied)
• Consider moving the new menu link in screen #34933
• Link with one line looks out of line in interface on navigation #34779 (again realise link interface)

[kellychoffman]

Took a look at your list and agree all should be addressed as part of an MVP.

[karmatosed]

@kellychoffman awesome 🙌🏻 The good news is all the little bugs have been fixed along the way, that list was a lot longer but has been closed one by one ✨

[kellychoffman]

Also - noted on a big checklist within another issue being hard to track. I kept it within the overall tracking issue only because I worry when the UX of a feature is seen as separate from the overall list of things to do within said feature. I think there's a way to do both tho, like you said.

[spacedmonkey]

I am wonder we should include menu location selection to the create menu dialog.

Consider the create menu interface in the customizer.

We could add menu locations to this dialog.

[kathrynwp]

Closing this issue due to the Navigation Screen project being moved to an inactive status on the feature projects page in coordination with the project leads. (The developer documentation in the initial post are no longer accessible)

If this work is picked back up, issues can be revisited and reopened as needed. Thanks for pitching in on this early feature so the wider WordPress project could benefit from the lessons learned!