Hallway hangout summary: managing blocks in the Customizer

The meeting started with a generic goal presentation for the project and how this goal relates to the full site editing efforts.

Project goal

The goal of blocks in widgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. areas is to bring blocks closer to users, especially the users who, for various reasons, will continue having their website using classic themes, not 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 themes. 

This ties into the Full Site Editing project (FSE) efforts as, so far, the full site editing project has been advancing in a direction where it only edits websites that are using block-based themes. Block-based themes are a new kind of theme, which is built exclusively out of blocks. For instance, templates are blocks themselves. 

What we’re doing here is to offer blocks to those who will still use classic themes and have sidebars and widgets. 

Trade-offs of our current goal

A problem was highlighted that when a user will switch between the two kinds of themes they’ll lose access to their normal editing environment (the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. for classic themes and the Site editor for block themes). Particularly for new users trying themes this could be a jarring experience. However, today, this is a good compromise that enables the most elegant and backward compatible introduction of a completely new system to build a website.

Managing blocks in the Customizer – user experience

The meeting continued with Rob doing a screen sharing session where we discussed each of the mockups from the “Managing blocks in the Customizer” GitHub issue.

Full screen: Block editor replaces the Customizer preview with auxiliary UIUI User interface in the side panel

Benefits:

• The modal nature of the full screen editor solves many of the conflicts between how the block editor and the customizer fundamentally treat user interaction, leaving each to its own approach.
• Largest viewport on desktops for editing blocks and widgets.
• It opens the path to removing the separate Widgets editor as having it as a standalone modal experience in the Customizer, but using the live site previewing, effectively makes the former useless. 

Challenges:

• It breaks a user’s expectations as to what the customizer does by default, which is showing the preview on the right hand side.
• A preview option would need to be added, and the transition to it would need to be very smooth
• The preview hides the block editor, what happens to the side panel?
• The preview should scroll to the edited widget area. What if multiple areas are edited and then the preview is shown?

Screen share: the block editor is placed in the side panel of the Customizer

Benefits:

• It feels more fluid as an interaction compared to the full screen option.
• The experience respects the behaviour of the rest of the Customizer’s sections: the relationship between what you edit and what you preview is clearer as you have them side by side.
• We can leverage the pencil editing icons in the preview
• We can leverage the side panel’s drawer behaviour (like it shows up when currently adding a new widget) to show the inserter and the inspector.

Challenges:

• The mobile editing experience is not great when using a desktop. That can be handled well by allowing 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. to be resized by the user. Many ideas on how to achieve this.
• Hard to reorganise widgets as the tall side panel will make block content stack vertically.
• We need a way to move widgets and blocks between widget areas.

Embedded: the block editor is embedded in the Customizer, the widgets and blocks are editable from the preview and the side panel is used for auxiliary UI

Benefits:

• It is the most consistent upgrade in user experience.
• Inline selecting and editing of attributes is the most fluid and intuitive approach, but only if the challenges have solid solutions.
• It offers the most WYSIWYGWhat You See Is What You Get What You See Is What You Get. Most commonly used in relation to editors, where changes made in edit mode reflect exactly as they will translate to the published page. experience, something that the Customizer aimed for from the beginning.

Challenges:

• Technically challenging due to the wild differences of how the two systems are built. CSSCSS Cascading Style Sheets. bleeding, markup conflicts, multiple editors with a common inspector and inserter, are only some of the things that raise the bar for this idea’s complexity. It’s hard to estimate but it’s obviously the most complex of the three explored paths.
• Some of limits we may impose will seem arbitrary to users: why cant I edit any part of the customizer by clicking it in the preview? How will the user know which widget area is currently being edited?
• Drag and drop for blocks and widgets may have to be disabled in the context of the live preview.

Final thoughts

• The solution should not require themes to be updated, ideally no opt-in is needed. If themes will have to be updated it generally obscures the goal of the project.
• The separate widgets screen, if disabled, may break some flows, but on the other hand it will remove a redundant screen. The main problem the current widgets screen has compared to the Customizer is that a user changes the live site directly. Adding blocks which are more free form and have a considerable number layout breaking options, this is even more problematic.
• The participants also covered a theoretical technical implementation of a communication layer between the block editor and the Customizer via the change set 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..

Join in on this effort to modernize WordPress! You can participate in the #feature-widgets-block-editor coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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, or chime in on GitHub or Trac.