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

Navigation Editor Tracking Issue #29102

Closed
46 of 62 tasks
draganescu opened this issue Feb 18, 2021 · 24 comments
Closed
46 of 62 tasks

Navigation Editor Tracking Issue #29102

draganescu opened this issue Feb 18, 2021 · 24 comments
Labels
[Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.

Comments

@draganescu
Copy link
Contributor

draganescu commented Feb 18, 2021

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:

Detrimental to UX

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

Feature parity with the classic navigation screen

Issues required to achieve a feature parity with the existing 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

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

Others


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

@draganescu draganescu changed the title Navigation tracking Navigation Editor Tracking Issue Feb 18, 2021
@draganescu draganescu added [Feature] Navigation Screen [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues labels Feb 18, 2021
@annezazu annezazu mentioned this issue Feb 18, 2021
22 tasks
@draganescu draganescu self-assigned this Feb 19, 2021
@draganescu draganescu added the [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues. label Mar 4, 2021
@draganescu
Copy link
Contributor Author

Updated and deprioritized a couple of issues.

@getdave
Copy link
Contributor

getdave commented Aug 11, 2021

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

getdave commented Aug 11, 2021

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

javierarce commented Aug 13, 2021

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.

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:

@getdave
Copy link
Contributor

getdave commented Aug 25, 2021

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

getdave commented Aug 25, 2021

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

talldan commented Sep 1, 2021

Update - 2021-09-01

Smaller fixes and enhancements

@kellychoffman
Copy link
Contributor

kellychoffman commented Sep 2, 2021

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)

  • "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.
  • 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"
  • No undo button - Is there a way to undo changes?
  • 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 Split control for URL and Text within Link UI #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
Copy link
Contributor

getdave commented Sep 3, 2021

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

talldan commented Sep 3, 2021

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 #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 #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 #31241. This is a quick win, so I've gone ahead and made the change in #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. (#23953, #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 #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
Copy link
Member

Mamaduka commented Sep 6, 2021

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

@javierarce
Copy link
Contributor

javierarce commented Sep 6, 2021

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:

@getdave
Copy link
Contributor

getdave commented Sep 8, 2021

Update - 2021-09-08

@spacedmonkey
Copy link
Member

spacedmonkey commented Sep 8, 2021

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

talldan commented Sep 8, 2021

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

getdave commented Sep 9, 2021

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

I also work like to flag this issue #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 #31551 (comment). I would love some feedback.

@talldan
Copy link
Contributor

talldan commented Sep 15, 2021

Update - 2021-09-15

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

getdave commented Sep 22, 2021

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

getdave commented Sep 29, 2021

Update - 2021-09-29

@getdave
Copy link
Contributor

getdave commented Oct 6, 2021

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

getdave commented Oct 20, 2021

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 draganescu removed their assignment Feb 18, 2022
@draganescu
Copy link
Contributor Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues [Type] Tracking Issue Tactical breakdown of efforts across the codebase and/or tied to Overview issues.
Projects
None yet
Development

No branches or pull requests

7 participants