Preliminary Roadmap for 6.0 (Gutenberg Phase 2)

Yesterday, WordPress 5.9 Joséphine was released with the help of hundreds of contributors and achieving a big milestone for WordPress. It’s now time to start thinking about next steps and the general scope for 6.0. As before, this is meant to be a high level overview of the different areas of focus, not an exhaustive list.

The overall aim is to consolidate and expand the set of customization tools introduced in 5.9 for creating themes with blocks, with a special focus towards usability and refinement. This new release could be considered a conceptual wrap for 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/: Phase 2. This doesn’t mean the customization phase would be concluded with it, but that its main features would have been established.

Editor

The introduction of the site editor marked a big milestone but also just a first step in the journey. There are various limitations that need to be lifted and features that didn’t make the cut that need to be revisited. We are also going to be learning a tremendous amount from users now that the initial work is out in the world to be experienced.

  • Refine the information architecture and template browsing experience. There’s work to be done to better organize the experience of interacting with the site editor, global styles, templates, and navigation as a whole. (36667)
  • Improve template creation (aiming at never showing disconcerting empty states) and allow the easy creation of more specific templates (i.e: category-$slug). The selection of new templates is artificially constrained right now in the interface. Opening that up should better express the power of the site editor as a web creation tool. (37407)
  • Expose site structure as “navigation” outside the navigation 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.. This is an important aspect to not limit site navigation editing exclusively to the site canvas, which for many reasons can be initially hidden from view. (36667)
  • Introduce browse mode to be able to conveniently follow links to different parts of the site. Conversely, the template editor that spawns when editing posts or pages also needs to establish better flows with the site editor. There’s a larger theme of connecting pages and templates to be explored. (23328)
  • Embrace style alternates driven by jsonJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. variations. This was teased in various videos around the new default theme and should be fully unveiled and presented in 6.0. One of the parallel goals is to create a few distinct variations of TT2 made just with styles. (35619)
  • Improve post settings design and organization. The sidebarSidebar A sidebar in WordPress is referred to a widget-ready area used by WordPress themes to display information that is not a part of the main content. It is not always a vertical column on the side. It can be a horizontal rectangle below or above the content area, footer, header, or any where in the theme. has gone without many updates for a while and could use improvements in clarity and design.
  • Complete the scope of global styles. Introduce easy export & import; support for revisionsRevisions The WordPress revisions system stores a record of each saved draft or published update. The revision system allows you to see what changes were made in each revision by dragging a slider (or using the Next/Previous buttons). The display indicates what has changed in each revision.; etc. (27941
  • Remove coupling of templates to specific themes. This is crucial for properly embracing the power of block templates. Switching themes should not cause the disappearance of your modified templates. This is also fundamental for offering more granular combinations instead of complete theme swaps, the ability to add new set of templates (relevant for plugins that introduce new templates), or changing individual parts of a site. (See also.)
  • Explore more advanced drafting and scheduling for the site editor. Some of this work is meant to happen more in depth during Phase 3, which will include more focus on editorial flows, but there’s still some paving steps to implement. (29575, 29388, 31456)
  • There should also be some room for some minor back to basics around the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. writing experience and further improvements to performance and usability. Areas to keep an eye on are the reliability of undo/redo, keyboard interactions, multi-selection, etc.

Patterns

It’s also time to expand the usability of patterns as a main ingredient when it comes to building pages and sites, now that most of the infrastructure has been established.

  • Prioritize pattern insertion on template building. This is a proposal to make patterns more central to the experience of creating theme templates and pages. (31153)
  • Simplify registration of patterns for themes. This might take the shape of a patterns folder with file headers that are automatically registered. All in all, it should be super easy for themes to provide a collection of patterns or to specify starter content as patterns. (36751)
  • Introduce page patterns for page creation. This has been on the horizon for a while and we should have enough building blocks to tackle it properly. It’s also an occasion to improve upon and align with the new “explore” modal that connects with the patterns directory.
  • Use patterns as possible transforms for offering “layout” options. Inserting new patterns is just a start, but often you want to change existing content or shapes into new ones. Patterns have some of those mechanisms but they need to be better presented and embraced. (27575)

Blocks

  • Finalize scope of navigation block and its overlay rendering. The navigation block introduced in 5.9 contains a whole world of customization and opportunities that needs to continue to expand and improve. In addition to the block itself, several flows need to be refined around transporting and initializing block menu data.
  • Introduce various new blocks to power the display of comments on themes. (34994, 38107)
  • Allow the featured imageFeatured image A featured image is the main image used on your blog archive page and is pulled when the post or page is shared on social media. The image can be used to display in widget areas on your site or in a summary list of posts. to be an attribute of other blocks (like Cover, Media & Text, etc) to expand what designs can be achieved.
  • Allow Quotes and Lists to have child blocks. Some of the current limitations of the writing experience arise from this constraint. (25892)
  • Improve the Table block. There’s a good design direction to finally implement. (32400)
  • Explore the viability of inline tokens. This has come up repeatedly in the context of rendering dynamic strings (such as current date) in rich text blocks.
  • Migrate default block styles into proper style attributes. Continue the work put into global styles by making all systems understand each other.
  • Pick up the work done for a Table of Contents block.

Design Tools (33447)

A lot of progress was made in 5.9 around consolidating the set of design tools and introducing new ones to address major gaps in the experience and providing block authors with simpler ways to register them. For 6.0 there’d be a concerted effort around tightening consistency, introducing more responsive capabilities, and expanding the Supports & Elements APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. Another important goal is to continue to make it easier for third-party blocks to adopt these tools.

  • Layout:
    • Address confusions and shortcomings of layout features (including mindbenders like “inherit layout”). (28356)
    • Explore more convenient direct manipulation for height and width (alignment distribution) of blocks.
    • Incorporate more definitive responsive handling (min/max containers) into the current flex-based tools. (34641)
  • Typography:
    • Introduce responsive fonts with good defaults. (33543)
    • Add a Web Fonts API connected with global styles. (37140)
    • Explore paragraphs with indents and justification with hyphenation as global styles settings.
  • Elements:
    • Introduce support for customizing block Captions.
    • Investigate hover / focus effects and related problems.

Gradual Adoption

Full block themes are at the avant-garde of the WordPress evolution, but work continues to happen to improve how all themes can interact with blocks and make use of the new tools gradually and at their own pace.

  • Continue to adopt theme.json configuration for non-block themes as it aims to simplify and consolidate support for block properties and their capabilities.
  • With the “focused template part” editor established there are new opportunities for non-block themes to start incorporating specific areas for blocks using the site editor interface in a more gradual way, when ready to do so. (37943)
  • Utilize what we have implemented for the navigation block and site structure as the interface to eventually replace the navigation screen.
  • Explore the flows for creating some dynamic templates with blocks (for example, just the archive), similar to the custom page templates support in classic themes.

Please, help define the work to be done by joining the conversations listed in the issues above or giving feedback!

#6-0, #gutenberg, #gutenberg-next

Proposed improvements to the Core Editor chat agenda and format

This post was coauthored with (some of) the facilitators of the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Editor chat – @zieladam, @annezazu, @bph, @fabiankaegy, @paaljoachim.

The Core Editor chats are a useful opportunity for contributors to gather, stay updated and share ideas on how to improve 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. editor.

Recently, the meeting facilitators (named above) have been discussing making some changes to the format of the chat with the goal of reducing the quantity of status updates in favour of more informal discussion and collaboration. This will involve removing some sections entirely and reducing others in order to make best use of the available meeting time.

To allow for feedback, we are proposing that these changes come into effect as of the Core Editor on 2nd February 2022.

Why are these changes needed?

Regularly chat attendees will know that the most valuable Core Editor chats are those which contain good dialogue and discussion between contributors.

This is particularly true when 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/ Core team members are in attendance, as they are able to provide a unique level of insight and expertise based on their understanding of the foundation of the editor itself.

In the past, such discussions have proven to be very useful for contributors seeking help with technical questions and/or to those submitting new proposals for consideration by the community.

As facilitators, we have noticed that this type of dialogue occurs most frequently during the “Open Floor” section of the meeting where attendees are encouraged to submit questions for discussion by those present.

We want to do our best to encourage and facilitate such opportunities on a more regular basis.

What will change?

As a result of these conclusions, we are proposing the following high level changes to the Core Editor chat format:

  • General status updates to be reduced to a minimum.
  • Key project updates to become “async”.
  • An extension of the current Open Floor section.

Let’s visit these in a little more detail.

General status updates to be kept to a minimum

The facilitator will endeavour to cover only the most critical status updates. Currently these are typically:

  • latest Gutenberg release
  • current WordPress release cycle news.

The length of these segments will be considerably reduced in favour of signposting towards external information to be consumed by attendees at their own leisure.

Any important announcements can and should still be made (e.g. release cut off dates .etc).

Key project updates to become async

WordPress contributors are inherently distributed. Therefore, instead of requesting synchronous updates on key Gutenberg projects, contributors will instead be strongly encouraged to provide these status updates async via GithubGitHub GitHub is a website that offers online implementation of git repositories that 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/.

The meeting facilitator will then signpost attendees to these updates for consumption at their leisure thereby freeing up a considerable portion of the allotted meeting time.

Many of the key Gutenberg projects already sustain a regular cadence of updates on their tracking issues and we therefore hope that it will be possible for Core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org. to keep their respective projects updated.

Extension of the Open Floor section

As outlined above, we intend to dedicate the majority of the meeting time to discussion and collaboration. In practice this means that we intend to extend the Open Floor section to encompass more of the allotted meeting time.

This section will retain the existing format; namely:

  • facilitator will determine ordering of discussions.
  • attendees can provide topics in advance via the Core Editor agenda comments.
  • attendees can suggest additional topics in real time during the meeting.

This will remain a moderated session with the facilitator deciding when it is appropriate to move between topics to ensure a varied discussion.

Let us know what you think

We as facilitators look forward to your feedback on the proposal above and we hope you will agree these changes will have a positive impact on the Core Editor chat.

If you have any feedback please leave it as a comment or feel free to raise it during the Core Editor chat on Wednesday 26th Jan 2022 (note that meeting will retain the current format).


Thanks to @audrasjb and @priethor for reviewing this post.

#core-editor