Hallway Hangout Summary: “compare and contrast” the Navigation screens

This post summarises the Navigation screen Hallway Hangout held on 2021-08-24 09:00 UTC in Zoom facilitated by @get_dave, @talldanwp and @javier.

The blockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience.-based Navigation editor screen has been behind an “experimental” feature flag within the GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party for some time. The purpose of the call was to outline the work required in order to remove the “experimental” status from the screen in order that the editor is active by default in the Gutenberg plugin.

The team working on the feature feel this is valuable in order to increase the visibility of the feature and therefore improve the quantity of feedback we receive.

Meeting Recording

If you’d like to watch the full recording of the session you can do so below:

Key points agreed

It was agreed that the prerequisite for removing “experimental” was: UIUI User interface/UXUX User experience feature parity with the existing Navigation screen (nav-menus.php) in CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress..

We also acknowledged that:

  • We wouldn’t commit to feature parity of developer focused APIs at this stage.
  • Removing “experimental” in the Gutenberg plugin, would not automatically make the feature ready for merging into Core (that won’t happen until WordPress 5.9 at the earliest).

What was discussed?

The format of the hangout was an open discussion comparing and contrasting the classic menu screen with the experimental block-based navigation screen.

To this end attendees were asked to test drive both screens and note down their findings prior to the call.

The meeting facilitators also prepared a list of items as discussion points which were worked through during the call.

Each item was demonstrated, discussed and then assigned a loose priority of High/Medium/Low based on how critical the group felt the issue was to achieving feature parity.

Outcomes

The key outcomes of the call were:

Next Steps

Contributors working on the Nav Editor will now look to reorganise and reprioritse the tracking issue around the problems identified during the call.

  • All items will be added to the tracking issue (with the possible exception of bugs).
  • The High priority section of the tracking issue will be reformed and refocused around the goal of “removing the experimental status from the Navigation Editor”. Only tasks directly related to this goal will be considered for inclusion in the “High” priority section.
  • Tasks identified during the call that were marked as Medium or High till be added to the aforementioned High priority section of the tracking issue.
  • Contributors will focus on tackling High priority tasks in order to realise the goal of removing the “experimental” status.

All contributors are encouraged to become involved in prioritisation. Everyone is welcome and we’d very much value your feedback. If you feel a priority is wrong or missing then please let your fellow contributors know.

Thanks to everyone who attended the hangout and we look forward to moving the Navigation Editor forward together.

#feature-navigation-block-editor, #hallwayhangout, #navigation, #summary, #video

Hallway Hangout: Fool me once — Writing end-to-end tests against regressions

On Thursday, I hosted a little walkthrough on how to write a simple end-to-end test to make sure a specific piece of editor functionality that had broken in the past wouldn’t break again.

As GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/ grows, the project sometimes experiences regressions: Features that used to work suddenly don’t anymore. In order to prevent these regressions from happening, contributors can write end-to-end (e2e) tests that cover a given piece of functionality and alert us when that functionality is broken. Combined with a Continuous Integration system such as GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ Actions, this is a very powerful tool, since it can notify a PR author that their PR might break something before they even merge that PR.

I’ve recently tried to keep more track of such regressions, and have started filing issues requesting e2e tests to cover them. In the hangout, I’ve picked one of these issues and demonstrated how to write an e2e test for it.

Continue reading

#core-editor, #e2e-tests, #end-to-end-tests, #gutenberg, #hallwayhangout