Porting widgets to blocks: Standards

[melchoyce]

@jasmussen and I have been chatting about turning all of the core widgets into blocks recently. You can check out his first exploration here.

I've also been exploring what that could look like, and have some general questions to pose:

• Several widgets have default titles that show, which can be overridden by adding a title manually. This can be confusing for people who don't know where that title is coming from, or how to get rid of it. (Relevant trac ticket from @karmatosed). We have an opportunity to change this behavior in blocks, either by...
  • Showing the placeholder title, as suggested in the ticket and in Joen's mockups.
  • Or, getting rid of the title entirely, and having people add their own title using a header block if they want one.
• Should we show any interface options within the block itself (like in Joen's mockups), or limit interface options to the toolbar and inspector? So, rather than showing the block name inside the block, and a title field, and then the preview, just displaying the preview like the other "live" blocks. This would keep it more accurately previewing the block, and would remove any interface clutter.
• Can... we deprecate some widgets? :) Specifically thinking the meta widget and the pages widget, which IMO can be replaced by custom menu (which I also plan on redesigning as a block).

I'm sure as we continue to experiment, more questions will arise.

[mtias]

I think we should go as "final view" as possible here (show the list of recent posts as they would be rendered in the front end). If we have titles, it could work exactly the same as captions or sources in quotes (directly editable but don't look like input fields).

[melchoyce]

So maybe...

Should the title be filled in by default, when you drop in the block?

[westonruter]

Should the title be filled in by default, when you drop in the block?

See also https://core.trac.wordpress.org/ticket/39909

(I see now this is referenced in the description 😊)

[westonruter]

I think it's important to think also about how these blockified widgets would then be used on the widgets admin screen and the customizer…

Should we show any interface options within the block itself (like in Joen's mockups), or limit interface options to the toolbar and inspector? So, rather than showing the block name inside the block, and a title field, and then the preview, just displaying the preview like the other "live" blocks. This would keep it more accurately previewing the block, and would remove any interface clutter.

In that regard, I may make it somewhat simpler to relegate the editing interface to the inspector (except perhaps a title, as mocked in #870 (comment)) and leave the abstracted live preview without any editable components. That would allow the same editing interface in the inspector could then be used in on the widgets admin screen and in the customizer pretty much the same they appear now. This would also facilitate a bridge that ports legacy widgets to be used as blocks, where the block in the editor could just show the server-rendered output.

Otherwise, if the editing interface is mixed in with the abstracted live preview… how would this then work in the context of the customizer and the widgets admin screen? I suppose for the admin screen having the abstracted live preview would be very nice since there is no preview there at all presently, but at the same time there is also no inspector panel. In the customizer, there wouldn't be a need for an abstract live preview because the actual rendered output would be seen… but then would the widget control show the abstracted live preview? Or rather upon editing a widget in the customizer should the widget in the preview window change to be the abstract preview with any additional edit interface shown in the controls pane? Or would the abstracted live preview and any additional fields both show inside of where a widget control is currently displayed?

I just wanted to call out how we anticipate blocks to live on contexts outside Gutenberg, when there are different interface environments, so that we can avoid having to implement multiple interfaces depending on where the block is showing up. I also understand that the other environments will likely be getting redesigned to a degree as well.

[grantpalin]

• the pages widget does seem redundant in light of having the custom menu widget; the former offers very little control while the custom menu option is very customizable

• I feel the widget title should remain part of the widget itself, because it pertains to the widget contents; a placeholder title as suggested looks good and is functional if needed; having a title be added as a separate block makes it distinct from the widget block

[mtias]

That would allow the same editing interface in the inspector could then be used in on the widgets admin screen and in the customizer pretty much the same they appear now.

Wouldn't this be imposing unnecessary legacy constrains over the new blocks? I think we should focus on how blocks can provide a better experience for setting and manipulating widget-like modules on the page.

As you mention in the end, this will be pushing all the interfaces to align under the expectations of block editing, and how those look is what should be explored in the next few months. For the editor specifically, I think we'll be porting the functionality widgets are covering today, not necessarily the widgets themselves.

[melchoyce]

Taking a look at some of the widgets that don't require a lot of input or configuration:

[kevinwhoffman]

I am also thinking similar to @westonruter that configuring widgets as blocks may be best handled in the inspector (without editable components in the live preview). My reasoning is that all but the simplest widgets would require configuration in two different places. I worry that mixing editable and non-editable content in the live preview will create confusion as to how different elements of the widget should be configured.

In the archive block example, it appears that the user sets the title in the live preview but the archive links themselves are determined by settings in the inspector. A separation of concerns could help here. Let the live preview accurately reflect the widget as it will appear on page, and let the inspector handle widget configuration. With this separation of concerns in mind, the title field would exist in the inspector with placeholder text and only appear in the live preview if populated.

[jasmussen]

Very very nice work in this thread, and great discussion too.

Before I offer thoughts, I'd like to step back a bit and clarify a few interface concepts that have guided much of the work so far. Some of them are a bit intricate, but an help highlight the best path forward.

Block-first interface

All of our work has started from the block as being a section of content which has a front-end and back-end. The block first interface comes with a number of ingredients to make it work, first and foremost being that it can surface hidden attributes of the block. For example image have captions that can be surfaced, quotes have citations.

The abstracted live preview refers to the fact that the block also previews the end result. When the block is unselected in particular, it is as closest to a preview as it will be: optional captions and citations disappear in this mode.

In other words, there's the selected block, and the unselected block. When selected, aside from the block boundaries showing, the Quick Toolbar pops up. This toolbar holds every basic action a user might take on a block, including transformations, alignments and inline formatting.

The inspector is solely for advanced actions a user might take. This provides us a clean separation betweeen the simple and advanced. The toggled sidebar plays into this — on mobile it's hidden and modally toggled when you need to access it. On a desktop, you might toggle it off because you want to write immersively, or you might simply not need any of the advanced actions at all (see also #708).

So to summarize, we have three depths:

• unselected block — serving mostly a preview purpose
• selected block — surfacing basic actions
• optional inspector — surfacing advanced actions

In other words, if we can, we should probably never put items in the inspector that are critical to the functionality of a block itself.

---

So far so good. Given these interface concepts, how can we apply that to the more advanced blocks that widgets suggest us?

I understand the desire to have these widget-blocks serve mostly as previews, and leave the configuration to the inspector. I think, so long as we're not dogmatic about this, that's fine. For example, the latest posts block could work like this:

• Insert the latest post block, do nothing, and it works. It shows the latest posts.
• Click the block in the editor, to surface the title field, just like how captions on images work
• Quick toolbar holds layout specific options, like alignments.
• Open the inspector to configure advanced settings like picking a category, number of posts, etc. These settings do feel advanced, and you can still use the block successfully without ever configuring these.

This is pretty much exactly matching up with @melchoyce's mockups here.

---

Otherwise, if the editing interface is mixed in with the abstracted live preview… how would this then work in the context of the customizer and the widgets admin screen?

Excellent question to be asking. I think there's a near term answer, and a long term answer to this one.

Near term, the inspector isn't a sidebar, but it's a modal. Right now it lives in the sidebar and is shown as soon as you select a block. This is an interface I believe in, but it's also an interface we might change in case user tests reveal this to be confusing interface. The alternative is that the inspector is a modal. You click an "Advanced" button on the quick toolbar, and "drill down" into a modal with advanced settings for the block. The separation between basic and advanced actions (quick toolbar vs. inspector) remains the same.

And so near term there's no reason blockified widgets can't work in the customizer and widget admin screen exactly as they do in the editor now: they have an unselected preview state, a selected state that reveals basic options, and an advanced modal that holds advanced settings.

In the longer term vision, one that involves page and site building, perhaps widgets aren't inserted in the sidebar or admin widget interface at all. Perhaps they are inserted right in the page, in context of where they'll be shown on the front-end also. If such an interface was to ever come to pass (and I hope it does), it feels extra important that we don't make any knee-jerk changes to the block interface concept to accommodate the current way widgets are inserted.

[jasmussen]

And so near term there's no reason blockified widgets can't work in the customizer and widget admin screen exactly as they do in the editor now

I'd like to clarify the above statement I made a bit, because that ☝️ is total speculation, and not my area of expertise. I would defer to those of you with actual widget expertise. Perhaps blocks won't work in any of the widget areas at all — perhaps widgets are simply ported to blocks, and we have both.

[jasmussen]

I also took the liberty of renaming the ticket a bit, to clarify that the first focus should probably be to figure out how our current widgets can live in the new editor, not necessarily the other way around.

[mtias]

Just taking a step back here, but the main goal is to replicate widget functionality with blocks (recent posts block, archives block, etc) not modifying how you work with widgets in the widget admin screen yet, so there only has to be loose alignment there. (These blocks don't even have to be called widgets to the user's eyes.)

With this separation of concerns in mind, the title field would exist in the inspector with placeholder text and only appear in the live preview if populated.

This goes a bit against the spirit of blocks (avoiding indirection for things that can be directly manipulated). Take a look at how images with captions or quotes with source are working with placeholder Editable components as good examples. We should be consistent on that front.

From @melchoyce:

Or, getting rid of the title entirely, and having people add their own title using a header block if they want one.

I think I agree with this. It sounds like the title as part of the widget is just a hindrance at this point since it's trivial in the editor to add a title block using a heading block.

[westonruter]

Thanks a lot for all of your guys's insights here, particularly @jasmussen. Beautiful. This is exactly the conversation I wanted to surface to start to think about what the blocks could look like outside the context of the editor.

The abstracted live preview refers to the fact that the block also previews the end result. When the block is unselected in particular, it is as closest to a preview as it will be: optional captions and citations disappear in this mode. […] In the longer term vision, one that involves page and site building, perhaps widgets aren't inserted in the sidebar or admin widget interface at all. Perhaps they are inserted right in the page, in context of where they'll be shown on the front-end also.

This is really helpful. I'm particularly interested in how this could eventually tie into frontend editing. In a frontend context (in other words, Customizer preview), a non-selected block could essentially be the rendered block. Once selecting a block (e.g. currently, clicking the edit shortcut in the preview) the rendered block could then be replaced with the abstracted live preview, with essential fields shown inline and any advanced fields then shown either in a floating inspector panel, modal, or in the Customizer sidebar. This would be great for widgets.

[kevinwhoffman]

I like the idea that the block appearance will accurately reflect the end result when unselected, and display optional fields only when selected. Initially I was unaware that was the intended behavior, so thanks for that insight.

Inspector compatibility with existing widgets

It would be a big win for plugin developers to make the inspector as compatible as possible with existing widget settings. This would allow plugin developers to quickly make their widgets available as blocks, and then they could progressively enhance them for direct manipulation. It would be akin to launching the iPhone with a fully populated app store rather than waiting for developers to adapt to the platform after release.

A replacement for TinyMCE buttons and shortcode builders

The current solution to inserting widgets into the editor typically relies on TinyMCE buttons that trigger shortcode builders, however the implementation and UX varies widely. Many plugins depend on this process as the primary means of inserting content into the editor, so I'm hoping that this discussion of blockifying widgets provides a standardized replacement for that process.

[jasmussen]

The current solution to inserting widgets into the editor typically relies on TinyMCE buttons that trigger shortcode builders, however the implementation and UX varies widely. Many plugins depend on this process as the primary means of inserting content into the editor, so I'm hoping that this discussion of blockifying widgets provides a standardized replacement for that process.

The block, combined with the inserter, are both intended to be evolutions of the shortcode interface. That is, the block can offer the same as and more than the shortcode can, and the inserter is a unified level playing field for inserting them in the content.

Even though we'd encourage people to write blocks instead of shortcodes, shortcodes will still continue to work.

Shortcode insertion buttons could potentially exist as buttons on the freeform block. There's a ticket for it, #794.

[marsjaninzmarsa]

@melchoyce: some of the widgets that don't require a lot of input or configuration

Sorry for interrupting, but nope. Don't have implemented ≠ don't require. Post type selection, other filtering and formatting options, related tickets are still open not without the reason.

As for theme/plugin developer I'd like to see common interface for creating widget and blocks, with optable availability in both and compatibility layer for old ones. Especially with planned move out from storing widgets in single, serialized wp_options array in to something else.

[westonruter]

@marsjaninzmarsa Widget blocks that are re-used in multiple places, e.g. in a sidebar, will most likely be stored in a custom post type and not options. See #1516. I expect there there will be blocks generated for legacy widgets that are registered via WP_Widget, but moving forward the block would be the common interface.

[westonruter]

Alignment toolbar added to Latest Posts block in #1803.

[karmatosed]

@melchoyce do we need to keep this issue open as there are actionable issues for each widget?

[jasmussen]

There are many good answers and discussion points here. Given we have those answers, as well as individual tickets for porting widgets, I'm going to close this one per Tammie's suggestion. It can always be reopened if this was in error.