Navigation Editor and Block Hallway Hangout

Date: October 13, 2021, 10:00 UTC

Format: Zoom (recorded). A link will be shared in the #feature-navigation-block-editor slackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel shortly before the meeting is due to commence.

Length: 60mins.

Goal: Discuss Navigation Editor and 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. goals for 5.9 and beyond.

Details: There are some recent proposed changes to the Navigation Editor and Block that would change some aspects of the project. See the post in slack for more information (https://wordpress.slack.com/archives/C01KDAZJMQ9/p1633512526250600). This hallway hangout will be assembled to discuss how the project should proceed.

Facilitator(s): 

Intended Audience: past and future contributors to the Navigation Editor and Block. Contributors to other related parts of WordPress.

Note Taker: any volunteers to be the official note keeper?

Agenda: 

  • Introduction
    • Facilitator and attendee introductions
    • Brief recap of Navigation Editor and Block projects to date
    • Recap of Navigation Editor goals to date
  • Discussion
    • Discuss the proposals for making the Navigation Block ‘reusable’. What are the block’s requirements for Full Site Editing?
    • How should the Navigation Block work with Classic Menu data for block-based themes (in a Full Site Editing context)?
    • How can the Navigation Editor can be made to work with this future Navigation Block?
      • Discuss the case of classic menu editing in the Navigation Editor for classic themes that do not support block-based menus.
        • Discuss backwards compatibility requirements and potential solutions.
      • Discuss the case of classic themes that could opt-in to showing block-based menus in their theme locations.
    • Have the goals for the Navigation Editor changed?
    • Discuss the proposed roadmap.
  • Summary
    • Briefly discuss next steps
      • Reworking the tracking issues / project board
      • Making WordPress post summarising results

#block-editor, #feature-navigation-block-editor, #gutenberg, #menus

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

Navigation Editor Hallway Hangout: compare/contrast the old and new screens

Date: August 24, 2021, at 09:00 UTC

Format: Zoom (recorded). A link will be shared in the #feature-navigation-block-editor slack channel shortly before the meeting is due to commence.

Length: 45 – 60mins. No more.

Topic: comparing and contrasting the classic menu screen with the experimental 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 screen.

Goal: derive a list of tasks that are required in order for the two screens to have feature parity (from both UXUX User experience and UIUI User interface perspectives).

Facilitator(s): 

Intended Audience: past and future contributors to the navigation editor and block. Contributors to other related parts of WordPress.

Note Taker: any volunteers to be the official note keeper?

Preparation:

Please could participants test drive the old and new screens. Try creating the same menus on both screens.

Then come prepared with features they feel are missing from the block-based Navigation screen that are present in the classic Menu screen, or any bugs encountered.

Image showing both the new and current navigation experiences with text saying "A new navigation editing experience is coming...".

Agenda

Introduction

  • Facilitator introductions.
  • Welcome to attendees.
  • Recap hangout topic and goal.
  • Terminology – block-based vs classic Navigation screens.

Format

  • Explain the format.
  • Facilitator will share screen to demonstrate which parts of the experience are being discussed.
  • Questions to consider about the new screen:
    • Where is it lacking polish?
    • What bugs are in evidence?
    • What steps are harder to achieve?
    • What steps are not possible to achieve?
    • What steps are easier to achieve?
    • What features are entirely missing?

Summary

  • Brief summary of key discussion points from notetaker.
  • Summary of action points including Issues to be created or further explorations required.
  • Next steps.
  • Thanks.

#block-editor, #feature-navigation-block-editor, #gutenberg, #menus

Dev chat summary: January 21, 2021

The CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. team postponed the afternoon dev chat for 24 hours to get past the US presidential inauguration. @metalandcoffee, aka Ebonie Butler, led the meeting on this agenda.

Announcements and highlighted posts

@metalandcoffee brought the group’s attention to these items:

Ebonie also invited the group (and you, too, dear reader!) to stop by a 5.7 test scrub. There’s one every Friday at 13:30 UTC.

Releases

The Core team is busy with one minor and one major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.

WordPress 5.6.1

5.6.1 has a squad and is deciding on a date; here are the tickets for the milestone.

WordPress 5.7

BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 lands on February 2. Here are the tickets in the milestone.

Per @hellofromtonya, aka Tonya Mork, noted there are 66 open features and enhancements that need committing or punting by Beta 1. (Ed. note: Beta 1 imposes a feature freeze on the release. After that, commits are bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. fixes only. RCrelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). 1 imposes a string freeze, so Polyglots can finish translations before final release.)

Tonya had more to share about the milestone tickets. See the full discussion and consider pitching in on some tickets, especially, as @metalandcoffee pointed out, if there’s something you really want to see in the release.

Updates from component maintainers

@sergeybiryukov kicked off the updates with a general announcement that as of January 21, WordPress Core has more than 50,000 commits and thanked every past, present and future contributor.

Sergey also reported in for Polyglots, which added support for Austria to remove_accents() in #49967.

@audrasjb reported in that Menus has two tickets ready for commit. In Upgrade/Install, JB recognized @dd32, aka Dion Hulse, for his helpful insights on rollbacks.

In Design, @estelaris, aka Estela Rueda, asked for testing to review this Core color-change pull request, based on a discussion in the Design channel that was happening at the same time as devchat.

@xkon reported in from Privacy, saying he’s pretty sure they’ll be punting some tickets from 5.7 that need more iteration. The team also expects inputs from other teams, which happens a lot with privacy.

Agenda comments

jQuery UIUI User interface and #52163

Between standard reports and Open Floor, devchat takes up items people add to the comments on the Agenda post—and other items people specifically add.

That happened with a question @hellofromtonya had on ticketticket Created for both bug reports and feature development on the bug tracker. #52163, which is about updating jQuery UI and removing jQuery migrate. All of that is getting punted to 5.8, but at the moment there’s no firm timeline for the new jQuery UI release. Follow the discussion as it happened here.

Consolidating instructions for local dev environments

Across the WordPress Project you can find several sets of instructions that will walk you through setting up a local development environment for building WordPress sites, themes, and plugins; contributing to all of those things plus Core; and doing lots of different kinds of testing.

Those local-environment instructions vary widely in age, approach and tooling.

@paaljoachim has started a Meta ticket (as opposed to a normal ticket) to discuss consolidating those instructions and would very much like feedback, comments and people to brainstorm with.

So far, @desrosj and @hellofromtonya have offered help. But this is a big, complicated thing — so please pitch in!

WordPress Importers

@pento offers this proposal to modernize the WordPress Importers, complete with a slew of links.

As he told the group, “

There’s a lot to read, but I’d appreciate folks taking the time to go through it. :slightly_smiling_face:2:44Much of it is fairly sensible, but the last post in the series does contain a proposal for writing exporters for CMSes that don’t provide an export option, which is a departure from our usual approach.”

See the real-time discussion here.

Visual regressionregression A software bug that breaks or degrades something that previously worked. Regressions are often treated as critical bugs or blockers. Recent regressions may be given higher priorities. A "3.6 regression" would be a bug in 3.6 that worked as intended in 3.5. tests

@isabel_brison has a pull request that sets up visual regression testing in Core. The TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. ticket is #49606.

@francina raised the point that some hosts are starting to do visual regression. See that discussion here.

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

@metalandcoffee: “Daniel Richards wanted to let everyone know that work on the block-based Navigation screen has picked up again, and there’s a new channel for [it] ” — #feature-navigation-block-editor.

Here’s the GitHub project.

Thoughts on browser versions?

@desrosj would like some feedback on #52331: Consider using more precise browser versions for `browserslist`.

Open Floor

@sergeybiryukov reminded the group that Beta and RC releases used to come with a haiku. He wrote one for the 50,000th commit and would like Core to restart the tradition.

@metalandcoffee volunteered to do a haiku for Beta 1 and closed the chat.

#5-6-1, #5-7, #core, #dev-chat, #summary