The current widgets view was definitely designed with sidebars in mind, but widget areas (now block areas) could also be footers, headers, etc. I think that is one thing that should be taken into account when updating this page.

Having all the widget/block areas editable on a single page feels weird. I think this screen should work more like the widget area editor in the Customizer. Notably, one advantage of the current wp-admin Widgets page is that you can drag-and-drop a widget from one widget area to another. I'm not sure how you would replicate this functionality if the Widgets screen became more like the Customizer. Perhaps the widget areas would be shown as tabs in a top bar or sidebar, and dragging a block over these tabs would switch the view over to that block area... kind of like how you can drag text/images from one tab to another in a web browser or from one app to another in most OSes.

And don't forget about the inactive widgets area... how does that fit into all of this? I understand its purpose, but it feels like a weird thing to have in the context of a Gutenberg-ified Widgets screen.

Additionally, the block selection on the left seems a bit odd. I think it should change to be a mix of the block inserter in the post editor and the Customizer widget inserter. Speaking of which, this seems like a good opportunity to add drag-and-drop insertion to the block inserter. The current widget area editors in both wp-admin and the Customizer have drag-and-drop insertion, but the block inserter in the post editor currently does not. See #1511.

Also, this mockup does not seem to take into account the block inspector. That should probably appear on the right side of the screen like in the post editor.

Just in general, the Widgets page in wp-admin feels weird, and it feels even weirder in the current mockup.

Are we going to mix widgets and blocks or are we essentially deprecating widgets?

I think they want to replace widgets with "widgets blocks" - something between a block and a widget.
And maybe themes to be replaced with a gutenberg pagebuilder tool, time will tell...

@nicholasio I think the current plan is that widget areas will become block areas, and there will be a "Legacy Widget" block that lets you embed any old widget into a block area. (Presumably, you could use the "Legacy Widget" block anywhere, meaning you could actually use widgets in posts and pages... something not possible before.) Most, if not all, of the core WordPress widgets will be deprecated and replaced by new block equivalents.

So essentially, widgets are being deprecated, but you will still be able to use them alongside blocks.

The current widgets view was definitely designed with sidebars in mind, but widget areas (now block areas) could also be footers, headers, etc.

I wonder if we can explore how those "areas" are displayed on the page itself. ie. if it's a sidebar areas, it shows as it does now, but if it's a footer or header, those are displayed where a header/footer would be. So it becomes a rough layout of the page itself. I'll mock something up.

Additionally, the block selection on the left seems a bit odd.

As an accordion, this would most likely be collapsed down and wouldn't be so overwhelming.

Also, this mockup does not seem to take into account the block inspector. That should probably appear on the right side of the screen like in the post editor.

I think you're right here. I'll get some mockups up to get more conversations going.

Additionally, the block selection on the left seems a bit odd.

As an accordion, this would most likely be collapsed down and wouldn't be so overwhelming.

What bothers me is that it doesn't look like the inserter in the post editor. Why should the inserter be an always-visible sidebar on the Widgets page but be a pop-up in the post editor? On the other hand, perhaps the post editor should be dockable to the side like the widgets library sidebar? Whatever the case, I think there needs to be consistency with how the block inserter appears in different contexts.

It is also important to note that the widget/block library design does not work very well on mobile compared to the inserter style of the post editor. Perhaps docked sidebar inserters should turn into pop-up inserters on mobile?

I attempted to use Figma for some prototyping. Here's a concept I put together. I wanted to see if there was another way we could contextually display the "widget-areas" instead of stacking them on top of one another. This would replace the /widgets.php in the wp-admin.

Prototype

https://www.figma.com/proto/O6SyONtxLjcUxsHq59EfStPs/integration-widgets?node-id=0%3A1&scaling=min-zoom

Video

Thoughts?

@mapk I'm not sure how that mockup would be implemented in practice. A widget area could appear in different locations depending on the page template, and of course some widget areas would only appear in certain page templates. Trying to fit all the widget areas onto a single screen in a way that makes sense would be difficult to implement, unless you were only trying to show the layout of one page template at a time (with the ability to switch between them).

It seems like it would be more productive to heed the advice of the "Manage with Live Preview" button on the widgets screen. That link was the first step in deprecating the admin screen in favor of the customizer version with live preview. The widgets admin screen has a fundamental disconnect with the way that widget areas actually work - with different areas showing in different parts of the screen and potentially on different parts of the site.

It will be very difficult to clearly reflect the frontend page structure on this screen in a way that users will be able to understand. Experimenting with contextual approaches to this experience in the customizer offers numerous opportunities for this fundamental problem to be solved. Starting with the visible edit shortcuts that are already in core, revamped widgets could be edited directly on the frontend (of the customize preview) or in an overlay that is more directly related to the display on a particular screen. The ability to navigate to different parts of the site within the customize preview solves a problem that this screen will never be able to address.

I suggest abandoning this proposal and closing this issue in favor of #13205.

Trying to fit all the widget areas onto a single screen in a way that makes sense would be difficult to implement

Agreed. I think the prototype, for me, was a way of distilling it more.

The widgets admin screen has a fundamental disconnect with the way that widget areas actually work

This is true, and the reason for the exploration above. I totally agree!

I suggest abandoning this proposal and closing this issue in favor of #13205.

This screen is a focus area of Phase 2, so I don't think this will happen. I believe the purpose behind changing it over to "blocks" is to help users understand the paradigm shift of everything becoming a block.

While this screen will eventually be deprecated in the future, especially as more of the site is built in Gutenberg, it's a necessary "baby step" to get us all there together. Maybe the best thing is to keep the existing layout, but just allow the use of all blocks within the accordion content areas? This will keep our resources and investment minimal on this particular piece with just a few suggested tweaks to the mockup in the initial post. It will also allow us to move to the Customizer more quickly.

I suggest abandoning this proposal and closing this issue in favor of #13205.

Same consideration already made for the Menus screen, see #13206 (comment). The customizer is not fully accessible. The admin widgets screen is the only place where persons with accessibility needs have a chance to manage widgets without having to face big accessibility barriers.

I'd also like to remind everyone the Widgets screen has an alternative "accessibility mode" (just click on the link in the top right). I'd be totally in favor of removing the accessibility mode if the new admin screen is built with accessibility in mind from the beginning. Which means, as a start: no fancy things, keep it as simple as possible.

A good way to start addressing accessibility before any visual mockup is designing the information architecture first. Think at this screen as a blank document where information needs to be organized with headings to identify the main sections and tasks, grouping together logically related controls, and making sure the perceived information makes sense when navigating content in a linearized way.

Re: the blocks selection on the left:

As an accordion, this would most likely be collapsed down and wouldn't be so overwhelming.

Is there a real need for the whole section on the left? I'd tend to think consistency with the design proposed in #13206 for the Menus screen is important. Maybe I'm missing something but having only the Widget areas with an inserter would greatly simplify the user interface. It will also allow to get rid of the drag and drop between the left and right sections, which will be an accessibility win.

That said, to my understanding all the core widgets will be blocks. However, what happens to custom widgets added by plugins and themes? Not all of them will be readily updated to blocks. Is there the need for some backwards compatibility mechanism like in the case of meta boxes? /Cc @youknowriad

That said, to my understanding all the core widgets will be blocks. However, what happens to custom widgets added by plugins and themes?

The idea is to build a classic widget block capable of rendering the edit and preview of any widget (like now) #4770

It will also allow to get rid of the drag and drop between the left and right sections, which will be an accessibility win.

Technically speaking, it will also be easier/quicker to not support drag and drop as right now, we can't have a single inserter targeting multiple editors.

The idea is to build a classic widget block capable of rendering the edit and preview of any widget (like now) #4770

+100
This is exactly what we need also. Thank you for having this in mind already!

What about also experimenting with ways to display widgets differently on different parts of the site? I mentioned some search use cases on https://make.wordpress.org/core/2018/12/08/gutenberg-phase-2/#comment-35058

This post also shows some use cases where there are different layouts depending on what type of page the user is on: home page, a single page, or a single post. I think archive pages, 404s, etc are also all important cases.

Having all the widget/block areas editable on a single page feels weird.

This is one of its biggest advantages over the Customizer. You can see all the widgets assigned to all the areas at once. For me, the Customizer is very limiting.

one advantage of the current wp-admin Widgets page is that you can drag-and-drop a widget from one widget area to another.

I don't want to lose this ability! I use it a lot, and a theme I wrote is based on the ease of doing this. This includes the inactive widgets. If you use an accordion or hide some widget areas, you are limiting the adjustability, as in the Customizer.

And don't forget about the inactive widgets area

Please don't get rid of this. It is important for theme switches, which may happen programmatically. But also important for being able to retrieve info that might have been entered when using a different theme. Having no access to the inactive widgets is the biggest problem with using the Customizer for widgets.

Why do widgets have to change to blocks? Aren't they already a type of block, and the new blocks are just now catching up with them? Why get rid of an API that is already so entrenched? Why switch to defining "content areas" when we already have widget areas and content? Why redo everything for the "new kid" when the new kid could just fit in with the existing easily?

Why do widgets have to change to blocks? Aren't they already a type of block, and the new blocks are just now catching up with them?

You're correct, @joyously. Widgets are already kind of like blocks. However they cannot be added easily anywhere on the page, especially in Gutenberg. Converting them to blocks solves this. Widgets-blocks are now treated equally with other blocks and can be added anywhere within Gutenberg. The widget screen in wp-admin is changing to reflect this and help everyone understand the paradigm of blocks.

Here's a prototype of what this screen can be. Please chime in with feedback.

1. Changing words from "Widgets" to "Widget-blocks" to help communicate the shift.
2. Keeps the functionality of the current widget screen.
3. Uses the Gutenberg block-inserter in a blown out panel. I kept this white so that it was an obvious change and also mimicked the Gutenberg block-inserter.
4. The Widget-block areas are still displayed as they normally are, but reflect blocks similarly to Gutenberg editor. In fact, they are like mini-Gutenbergs. 😉
5. I am missing the Inspector (Gutenberg sidebar) from these which should probably be thought through more. If the widget screen is going to include everything that Gutenberg does to interact with blocks (toolbar, inserter, inspector) than maybe this becomes a larger Gutenberg screen that allows for all this.

Prototype:

https://wp.invisionapp.com/share/VYQ6PWPWTH3

Video of prototype:

Accessibility

I'd like an a11y review of these thoughts. Does the block-inserter of Gutenberg meet a11y needs? If so, do this prototype work in respect to a11y? A user should be able to insert a block directly from the widget area now which is new.

Why to mix widget-blocks with blocks?
They should be separated I think...

Like Paragraph or Heading - are not widgets-blocks...
Why not to make instead a Text Editor or Gutenberg Editor widget-block that will have all these blocks inside it...?

Why to mix widget-blocks with blocks?

That's the great thing here! As more of WordPress becomes editable within a Gutenberg interface, you'll be able to add blocks anywhere you want. I'm using the wording "widget-blocks" just to help make a transition toward this. Eventually, the term "widgets" won't be used at all b/c everything will be a block. That's a ways out yet though.

But perhaps wording it like this might causing more confusion?

Why not to make instead a Text Editor or Gutenberg Editor widget-block that will have all these blocks inside it...?

I'm not sure I follow, but there is a Classic Widget block being developed (#4770) that will act like a block (can be added anywhere within a Gutenberg interface), but contain widgets that haven't yet converted to blocks.

I'm sharing a simple comment that summarises the PR's of the main remaining tasks to get block editor for widget areas:

• Highest priority PR: Implementation of rest endpoints that abstract widget area as blocks. #15015
  --(in progress) Some updates to a very recent review are pending, but the PR can still benefit from reviews.
• Second PR with the highest priority: Connect the widget endpoints to the block editor in the widgets screen.
  #15074
  -- Depends on #15015.
  --(in progress) Reviews are pending.
• Render widget areas that reference a post_id in the website frontend.
  -- #15074.
  --(in progress) Reviews are pending.

Merging the 3 PR's that reference each other in a chain allows us to have an end to end demo of the block editor for the widgets screen.

In Parallel we need other improvements to make blocks work as expected in the widgets screen.

Remove wordpress/editor usages from the core blocks (wordpress/editor is not available in the widgets screen).

• #15635
• #15572
• #15521

Fix UI problems that make the screen not work as expected or that make the screen have a suboptimal experience.

• #15472
• #15470

Other UI problems are affecting the widgets screen, for which a solution is not yet implemented. The major problems are:

• the block popover is not appearing in the right positions.
• The block inspector is still not available.
• We don't have something equivalent to the global inserter, we can only insert blocks using the sibling inserter, and "/" autocomplete inserter. Maybe we should have a global inserter per widget area?

Given that some time passed since the last widgets work update I'm going to share a new one containing the developments since the last update.
The PR's that connect the widgets endpoint with the widget screen were merged and the PR that renders block in the front widget area of a website was also merged.
The screen still provides a suboptimal experience and many enhancements are in progress.

Merged PR's (related to the main screen work): #15015, #15074, #15651

A PR that allows the legacy widget block to reference an existing widget was proposed #15801.

Legacy widgets still don't work as expected on the widget screen for that we need to make sure we can land user server-side render component on that screen #15635 and we need PR previous referenced #15801. Both PR's are pending a review/re-review.

Regarding the work to remove wordpress/editor usages from the core blocks:
#15572 was merged. #15635 is pending a re-review and I will soon update #15521 to address the reviews.

Regarding the work to Fix UI problems that make the screen not work as expected or that make the screen have a suboptimal experience: #15472 was closed because we updated code in other PR that fixes the root cause of the problem.
#15470 is in discussions and is pending a decision.

One major concern I have is the single save button and single draft/publish functionality.

This is definitely a rising concern. I'll explore this more and look at moving this button to be Block Area specific (mockups soon to come). I don't think it's necessary to move to actual blocks.

Another update.
The short term project board is available at https://github.com/WordPress/gutenberg/projects/27.

We merged another two important PR's #15521, #15396

PR's that need reviews

The next PR with higher Priority is
#15801 which when merged will allow legacy widgets to be used in the widgets screen.

#15548 is practically ready and needs final approval.

#15948 was updated and needs final approval too.

Some problems /potential enhancements were found in the PHP code, and two PR's were submitted. It would be some additional eyes on them:
#15981
#15983

Props to @TimothyBJacobs for doing an initial review to one of these PR's.

Pending updates/discussion

#15635 was discussed, and it seems we arrived at a possible solution. I liked the suggestion provided by @gziolo of having a ServerSideRenderProvider; I'm going to implement it in the next hours.

#15470 @aduth provide an alternative idea exposing a new component that includes the BlockEditorProvider but also some artifacts expected from a block editor, e.g., the writing flow. I guess if no one was any concern regarding that approach the best path is implementing that component and update #15470 to use it.

Other updates

#15988 proposed by @aduth will unblock the popover positions problem on the widget screen I will review it in the next few hours.

This issue hasn't been active in a year. Is there another overview issue for the widget screen?

I don't think so, @ellatrix. If you'd like to close this, we do have the Project Board that has a list of issues as well.

It would be nice to keep this old issue open as it also links to the Project Board. It can also be updated when someone has the time to go back to this issue again.

Ok, since there's no movement on the project board and no movement on this issue, I'll remove it from the WP 5.5 board.

@ellatrix  I'm unclear on the status of this feature. Is there still plans to convert over the widget sidebar stuff to using Gutenberg blocks?

All the PRs Jorge mentioned here: #13204 (comment)
Have been merged.

Hey Aslan. @jcklpe

The status of the feature is that no one has worked on the Widgets screen in wp-admin for a long time, so it is removed from the WP 5.5 project board. It does not mean it will not be worked on, only that it is not a priority for 5.5.

I will close this big issue as today it only stands for historic documentation.