draganescu commented 3 years ago

Last updated Aug 23, 2021

Extends #24551, preliminary for milestone 7 This is an overview issue that we'll maintain going forward into WP 5.7 and 5.8 milestones. It attempts to track discussions and resulting actions about the Navigation Editor.

This overview tries not to track bugs of the Navigation Editor - for that you should filter open issues using the labels:

[Feature] Navigation Screen
[Type] Bug.

🏷 High

This high priority label designates what is required before we can remove the "experimental" flag in Gutenberg from the Nav Editor screen. The prerequisite for doing this is: UI/UX feature parity with the existing Menus screen (nav-menus.php).

UI/Visual Issues

Issues that are important to ensure the quality of the use experience is at an acceptable baseline:

[ ] https://github.com/WordPress/gutenberg/issues/29747 - fix the current UI styling inconsistencies.
[x] #34035
[x] #34036
[x] #34032
[x] #31182
[x] #31100
[x] #31241

Detrimental to UX

Issues deemed critical that severely impair the user experience of the new screen:

[x] https://github.com/WordPress/gutenberg/issues/23583#issuecomment-903766350 - need to be able to click to expand all levels of nesting via some means. Possibly requires a dedicated Issue.
[x] https://github.com/WordPress/gutenberg/issues/34223
[x] https://github.com/WordPress/gutenberg/issues/34265
[x] https://github.com/WordPress/gutenberg/issues/23953
[x] #34225
[ ] https://github.com/WordPress/gutenberg/issues/34234
[ ] https://github.com/WordPress/gutenberg/issues/34268
[x] https://github.com/WordPress/gutenberg/issues/34283
[x] https://github.com/WordPress/gutenberg/issues/34438

Feature parity with the classic navigation screen

Issues required to achieve a feature parity with the existing screen:

🏷 Normal

User experience

Visual/UI

[ ] https://github.com/WordPress/gutenberg/issues/29100

Improved interaction mode

[x] #31074
[x] #30659
[x] #31276
[x] #31813
[x] #33271
[x] #33272

Feature parity with the classic navigation screen

[x] #22623
[ ] https://github.com/WordPress/gutenberg/issues/34233
[ ] https://github.com/WordPress/gutenberg/issues/34232

Compatibility with the Navigation block

[x] #30007
[x] Decide if it's better to switch to a Legacy Menu block (TL;DR - decision was it's best to evolve the existing Nav Block to suite the needs of the editor).
[x] #23953
[x] #24029
[x] #23583
[x] #26141
[ ] https://github.com/WordPress/gutenberg/issues/30006

Required REST API updates

[x] #24907
[x] #25093
[x] #25094
[x] #25095
[x] #24642
[x] #28701
[x] #35047
[x] #35046
[x] #35045
[x] #34999

Upgrading WordPress menus to allow blocks

[x] #24638
[x] #29101
[x] #29101
[x] #24639

Customizer support

This may evolve into a lot more once we have the foundation for embedding a block editor in the customizer.

[x] #24844

Others

[x] #35037

🏗 Architecture

This section is reserved for Issues that are related to overall architectural discussions. Any concrete tasks should be added to the relevant section above.

Known/Potential backwards compatibility problems

This section is reserved to list any potential or known backwards compatibility issues with the existing Menus screen that cannot (or will not) be solved in time for removal of the Experimental status from the Nav Editor. It is expected that we will communicate early about these problems in order that developers have sufficient time to adapt their code.

https://github.com/WordPress/gutenberg/issues/31551

draganescu commented 3 years ago

Updated and deprioritized a couple of issues.

javierarce commented 3 years ago

I'm reviewing the navigation issues & enhancements, and here are some tickets that don't appear in the list above:

30006
31100
31182
31276
31667
31813
33271
33272

getdave commented 3 years ago

I've moved all the items from @javierarce's list that are not Type: Bug into the most appropriate places I could find.

Note this Issue's tasks are going to be re-prioritised in the near future. I will update here regarding when and where that will happen.

getdave commented 3 years ago

Update - 2021-08-11

Work has continued on bug fixes and stability.
Looking to define what is required to bring the Nav Editor out of "experimental".
To this end, the team is looking to arrange a hallway hangout (or similarly public forum) to compare/contrast the classic navigation screen with the block-based navigation screen.
We're also looking to filter out or break down any "Epic" Issues into more actionable tasks (where possible).
@javierarce has also been looking into and documenting the need to add some "polish" to the Nav Editor screen in order that UX bugs/issues don't spoil the overall experience. I believe he will look to add these as Bugs to the repo soon.
From this we will then look to reprioritise the task list in this tracking Issue around achieving feature parity at a user interface level (developer APIs will follow).

javierarce commented 3 years ago

Here are the last three issues I've recently created related to the editor. The first one is the most important and probably key to have a nice experience creating menus.

34035
34036
34032

I've added them (plus others from my previous message) to the original post on top. The only issue I see that is not categorized is:

30006

getdave commented 3 years ago

I've added / moved all of the visual items raised by @javierarce to the High priority section. These are the minimum baseline visual inconsistencies that need to be resolved prior to the screen coming out of "experimental".

The only issue I see that is not categorized is #30006.

This is the issue regarding supporting future block types. I'd say that's beyond the scope of what is required to get the Nav Editor out of "experimental". However I will add to one of the lower priority sections.

getdave commented 3 years ago

Update - 2021-08-25

The team have been focused on reforming the project around the goal of removing the "experimental" status of the feature within the Gutenberg Plugin (only).
Held a Hallway Hangout on Tuesday to compare and contrast Navigation screens and determine next steps.
~A summary will be posted shortly~ A summary of the meeting and decisions made is available.
Tracking issue is being updated to focus on the tasks required to remove "experimental".
Work is continuing on exploring wider architectural issues such as how to best make use of the Navigation block whilst retaining stability.
We've continued with small UI/UX fixes.

talldan commented 3 years ago

Update - 2021-09-01

A plan has been formed for migrating from the customize API to the REST API in the navigation editor. The editor has been temporarily using the customize API for saving menus while some REST API design issues were resolved (see: https://github.com/WordPress/gutenberg/issues/25093)
The navigation editor header has been refreshed to more closely match the styles used by other editors (see: https://github.com/WordPress/gutenberg/pull/34166).
Some early discussions have taken place in the #feature-navigation-block-editor slack channel about extensibility in the navigation screen. Join the discussion if that's a topic you're interested in (see: https://wordpress.slack.com/archives/C01KDAZJMQ9/p1630160027012100).

Smaller fixes and enhancements

The navigation block is due to support a new block type, the 'Submenu' block, and work has been undertaken to ensure the navigation editor supports this (see: https://github.com/WordPress/gutenberg/pull/34281).
The above change also fixes many of the block styling issues in the navigation editor.
A fix for the entities being shown in menu names was merged (see https://github.com/WordPress/gutenberg/pull/34263)
Loading of the navigation screen has been optimized by preloading API requests (see https://github.com/WordPress/gutenberg/pull/34364)

kellychoffman commented 3 years ago

I did a review and noted UX items that should be addressed before we can move this out of experimental phase: (Will link them all up to issues)

[x] "Switch menu" location is out of context from the current menu you are editing. We have solved this similar issue in template editor with a dropdown next to the name of the template you are on - we should reuse this UX.
[x] Once you add a menu, the state of the block shows placeholder bars and you are blocked as to what to do next. Ideally, we skip this step and go right to add Existing Page, Add All Pages, Start Empty. (This layout is also currently broken and needs a bit of a refresh.)
[ ] “Add new page” label is unclear - the key word to this setting is "Automatically" and that is only shown in the descriptor text. Let's move it to the label so it reads: "Add new pages automatically"
[x] No undo button - Is there a way to undo changes?
[x] When adding all links I have to know to "Convert to links". This should either be automatic or more obvious.
[ ] Manage locations button placement - is confusing in context and should be separated from the task of applying this menu to certain locations provided by the theme. (Current implementation has it hidden behind a tab.)
[ ] Adding pages, whether one at a time or several at once needs some further iteration https://github.com/WordPress/gutenberg/pull/33849
[ ] How can I see how this looks? Or apply different layouts/styles? ('View theme styles' similar to Widgets could be an MVP of this)
[ ] Usage of "Menu" vs. "Navigation" terms feel a bit confusing. Not clear why we are using them + where.

cc @javierarce

getdave commented 3 years ago

Thanks @kellychoffman. Great to have some additional eyes on this ✨

For the purposes of ensuring the list of "Todo" items is actionable, it would be super helpful if we can:

ensure all the Issues raised are specific / immediately actionable.
dedupe them against existing Issues.
add them to the appropriate place under the High section.

that should be addressed before we can move this out of experimental phase

As I'm sure you're aware, it's very easy for this list of "priority" items to grow indefinitely so I'm hopeful we can prune these back to the items that are absolutely essential for removing the "experimental" flag 🙏.

For context, the general agreement in the Hallway Hangout was that we would focus on items that are clearly and obviously detrimental to the UX in terms of being able to create a basic menu. Optimisations and ideal flows will be addressed in follow up phases.

Open to discussion however - how do others feel?

Thanks again @kellychoffman 🙇‍♂️

talldan commented 3 years ago

A lot of these are I think covered already, but maybe some things are missing from the tracking issue:

"Switch menu" location is out of context from the current menu you are editing. We have solved this similar issue in template editor with a dropdown next to the name of the template you are on - we should reuse this UX.

Covered in https://github.com/WordPress/gutenberg/issues/31241, but this isn't part of the tracking issue.

Once you add a menu, the state of the block shows placeholder bars and you are blocked as to what to do next. Ideally, we skip this step and go right to add Existing Page, Add All Pages, Start Empty. (This layout is also currently broken and needs a bit of a refresh.)

Covered in https://github.com/WordPress/gutenberg/issues/23953, already high priority

“Add new page” label is unclear - the key word to this setting is "Automatically" and that is only shown in the descriptor text. Let's move it to the label so it reads: "Add new pages automatically"

Good feedback, lets address this. Could be a Good First Issue.

No undo button - Is there a way to undo changes?

Also part of https://github.com/WordPress/gutenberg/issues/31241. This is a quick win, so I've gone ahead and made the change in https://github.com/WordPress/gutenberg/pull/34533

When adding all links I have to know to "Convert to links". This should either be automatic or more obvious.

This 'Convert to links' UI will be removed, the current behavior is a bug introduced from the nav block. (https://github.com/WordPress/gutenberg/issues/23953, https://github.com/WordPress/gutenberg/issues/33999)

Manage locations button placement - is confusing in context and should be separated from the task of applying this menu to certain locations provided by the theme. (Current implementation has it hidden behind a tab.)

There's some related discussion on https://github.com/WordPress/gutenberg/issues/33815, where I've mentioned this. Would be great to see some options for improving this.

Adding pages, whether one at a time or several at once needs some further iteration Split control for URL and Text within Link UI #33849

Seems to already be in progress, but not part of the tracking issue. At the moment there are a few issues around adding items, so I do agree the process could be revisited, but not sure I agree it's a blocker for opening up the editor in the plugin, but definitely something to address before this lands in WordPress core.

How can I see how this looks? Or apply different layouts/styles? ('View theme styles' similar to Widgets could be an MVP of this)

This isn't possible right now, it will most likely be a longer term goal as part of integrating the customizer. The widgets screen has the same issue, but was still launched, so I don't think this is a blocker to removing the experimental flag.

Usage of "Menu" vs. "Navigation" terms feel a bit confusing. Not clear why we are using them + where.

Agree, it'd be good to have an issue for this and some guidance. I think this has come about because the navigation block is being used to edit classic menus.

Mamaduka commented 3 years ago

The #34224 issue is listed in both High and Normal priority lists.

javierarce commented 3 years ago

Thanks for the review, @kellychoffman!

Regarding "How can I see how this looks? Or apply different layouts/styles?", I'd like to point out this exploration I did some time ago:

31074

getdave commented 3 years ago

Update - 2021-09-08

Everyone is focused on addressing the High priority issues on the Tracking Issue (see above).
Work has continued on the Submenu block and preparing it ready for use in the Nav Editor.
The navigation editor header has gained more tools to better match other editors - props to @talldan for all his work here.
Work is underway to add a global inserter to the screen.
The creation flow for navigation menus was improved with a new block placeholder
Improvements to List View drag and drop should have beneficial knock-on effects for the Nav Editor - props to @gwwar for her work here.
We could do with the ability to (multi) select non-consecutive blocks. This PR from @swissspidy looks promising but additional help much appreciated.

spacedmonkey commented 3 years ago

I created a number of issues related to menus.

Adding support from custom post types / taxonomies should be a blocker for getting this out of experiment, as it would make the menu screen unusable for those with CPT / CT.

talldan commented 3 years ago

The #34224 issue is listed in both High and Normal priority lists.

34232 was also in both, so I've removed it from high priority. I feel like we even said it was low priority in the hallway hangout, but can't remember for sure.

getdave commented 3 years ago

Thanks for creating these! 👍

I created a number of issues related to menus.

~@spacedmonkey Have you added these to the relevant sections above? If not then we'll need to look at that. I'll check now.~

Update: I marked ✅ next to all your items which I've added to the relevant sections. One is remaining as I'm genuinely not sure about it and would like to discuss and learn more from you.

Adding support from custom post types / taxonomies should be a blocker for getting this out of experiment, as it would make the menu screen unusable for those with CPT / CT.

Anything that makes the screen unusable feels like a blocker. Let's investigate this one further. Adding to High list.

spacedmonkey commented 3 years ago

I also work like to flag this issue https://github.com/WordPress/gutenberg/issues/31551 . It is important that we maintain backwards compatibility and solve backwards compat for ACF, we likely cover lots of other use cases of users that have extended the current menu screens. i have posted my idea of compatibility https://github.com/WordPress/gutenberg/issues/31551#issuecomment-915886641. I would love some feedback.

talldan commented 3 years ago

Update - 2021-09-15

Work is still progressing on migrating the navigation editor fully over to the REST API. The REST API changes have been merged, and now the front end code is being updated.
Lots of UI changes this week with the editor top bar being updated, the main block inserter added, and fixes to the block's styles
Good discussion underway on how to provide backwards compatibility for custom fields on the existing Menus screen.
Up next: We're looking into bulk adding links, and using theme.json to control aspects of the navigation block.

We're always looking for contributors to help work on the Nav Editor and block - it you're interested please head over to the #feature-navigation-block-editor Slack channel. Look forward to seeing you there.

getdave commented 3 years ago

Update - 2021-09-22

Lots of working happening on High priority items. Thanks for everyone who is contributing so much work 🙌
REST API interactions have been improved and more issues identified.
A tonne of bugs got fixed 🐛
Started looking at ways to add links in Bulk.
Using Theme JSON to control the block in the editor has been ruled out 😞
Another Hallway Hangout is on the cards - dates/times to be confirmed.

getdave commented 3 years ago

Update - 2021-09-29

Discussion is ongoing on the best way to ensure interoperability and compatibility between Nav block and Nav Editor.
Proposal to utilise a new classic Menu block in the Nav Editor is ongoing. Any feedback welcomed.
Folks (particularly @spacedmonkey) have been working hard on backwards compatibility. Any more feedback on this Issue would be a great help.
Lots of bug fixes continue to roll in for the Editor. Great work by everyone involved.

getdave commented 3 years ago

Update - 2021-10-06

Discussion is still continuing on the best way to ensure interoperability and compatibility between Nav block and Nav Editor.
Looks like there will be a Hallway Hangout on Wednesday 13th October (TBC). Agenda will be posted to Make Blog.
@talldan posted a nice summary of current state of things in Slack. There's a lot of great energy in the team right now and we are looking to coalesce around a shared set of objectives.

getdave commented 3 years ago

Update - 2021-10-20

The Nav Editor will not be included in WordPress 5.9 - this is because:
- changes to the block are required for the editor to be a success (see below).
- we need to allow sufficient time to test the editor before any major release and allow for community feedback.
Following the Hallway Hangout a summary was posted. The outcome was:
- in the short term, contributor efforts will switch to the Nav block in order to resolve some of the underlying architectural issues
- specifically separating the navigation's presentation from its data in order to make navigations reusable. This serves both the Nav Editor project and the WordPress 5.9 release in general.
- The Navigation Editor will ultimately focus on manipulating the data of a navigation which is why the above work is a prerequisite for the project's success.
- Work on the Nav Editor will resume after WordPress 5.9. We will continue to focus on backwards compatibility whilst looking ahead to the world of blocks.
- It's unlikely that we will pursue a new "Classic Menu" block. Rather focusing on the Navigation block (or its data).
To this end @talldan has two important Nav block PRs which everyone is encouraged to test and provide feedback on.

draganescu commented 2 years ago

I will close this tracking issue for the time being. The work continues on the navigation block.

WordPress / gutenberg

Navigation Editor Tracking Issue #29102

🏷 High

UI/Visual Issues

Detrimental to UX

Feature parity with the classic navigation screen

🏷 Normal

User experience

Visual/UI

Improved interaction mode

Feature parity with the classic navigation screen

Compatibility with the Navigation block

Required REST API updates

Upgrading WordPress menus to allow blocks

Customizer support

Others

🏗 Architecture

Known/Potential backwards compatibility problems

30006

31100

31182

31276

31667

31813

33271

33272

Update - 2021-08-11

34035

34036

34032

30006

Update - 2021-08-25

Update - 2021-09-01

Smaller fixes and enhancements

31074

Update - 2021-09-08

34232 was also in both, so I've removed it from high priority. I feel like we even said it was low priority in the hallway hangout, but can't remember for sure.

Update - 2021-09-15

Update - 2021-09-22

Update - 2021-09-29

Update - 2021-10-06

Update - 2021-10-20