Widget Editor: Design Updates

[mapk]

Revisiting the new Widget Editor, I can see a few areas that require design updates.

Widget areas

Currently, the widgets.php screen shows all theme-registered widget areas together. This is how the experimental Widget Editor works as well.

Overall improvements from widgets.php

• Any block can be used in a Widget Area.
• One global update button that pushes all changes live at one time (similar to the Block Editor). This no longer requires staging widgets in the Inactive Widget Area. The user can drop them into the specific area, then adjust settings and content, and then push them live.
• Brings the familiarity of the Block Editor into other parts of the admin.

---

Multiple widget areas vs. Single widget area

I'm exploring whether or not we should display all widget areas in one screen, or add a switcher that only allows one widget area to be visible at a time.

Multiple widget areas in screen
Remains closer to existing user expectations by presenting all widgets areas and blocks in the same screen.

PROS

• A user can drag and drop blocks between the widget areas easily.
• All blocks/widgets are visible at one time.

CONS

• The Global Block Inserter doesn't know which area to add a block to without that area being indicated somehow.

Single widget area in screen

PROS

• The Global Block Inserter panel can default to open and allow adding easily into the widget area.
• Can inherit the full background similar to the Block Editor.

CONS

• No ability to drag and drop between widget areas.
• Where do the Inactive widgets/blocks live? The Inactive Widget Area is used for widgets that no longer have a place after a theme switch and/or for staging a widget before adding it to an area causing it to go live.

Single widget area + Inactive Widget Area
To remedy the CON in the single widget area exploration, there's a possibility of always showing an Inactive Widget Area. This area would always be visible from whatever main area was being edited.

PROS

• Keeping this area always visible allows users to drag and drop the inactive widgets/blocks into another widget area to reactive them.
• Inactive widgets/blocks retain their settings and visual appearance.

CONS

• There is still some ambiguity around which area the Global Block Inserter should add a block to. I thought disallowing users from manually adding blocks to the Inactive area, but I'm aware of a use case that involves users adding moving blocks into this area for a time and then moving them back into an active area without losing the widget's/block's settings (ie. when a sale is happening on the site).

---

Block Library

Similarly to the widgets.php screen, we can open the Block Library panel by default.

---

Widget area switcher

Moving toward a Single Widget Area, a switcher would be necessary to move users from one widget area to another.

---

Paragraph placeholder

Instead of showing a consistent "Add" button at the bottom of the widget area, we can make this more like the Block Editor by showing the Paragraph block's placeholder instead with the in-page Inserter + button.

---

Document Inspector

When the Document Inspector is open in the Widget Editor, it should display the Widget Area's name and include the description provided by the theme.

[noisysocks]

Love the exploration here, but just noting that we have 9 weeks until the feature freeze for WP 5.6, so any big changes here need to be done quickly or punted.

[paaljoachim]

Great job, Mark!

Having it as close as possible to the standard method of adding blocks in Gutenberg would be best as I see it so that we can keep a consistent method of adding a block (widget). That would mean either opening the inserter as a sidebar or having the + inserter icon directly in a paragraph block.

There could be as you mention an inactive area. So the user can drag blocks/widgets that one is not certain of using.

My suggestion would be to actually test out both methods. Using the inserter that opens as a sidebar and the inserter inside the paragraph block (user can choose which method to use). Today we already have the widget experimental screen inside Gutenberg -> Experiments. So this would actually be something that can quickly get in place so we can get some testing done. With feedback we can refine the experience.

[afercia]

A user can drag and drop blocks between the widget areas easily

I may be wrong, but in the mockups / GIFs above I don't see controls to move / rearrange the widgets by using a keyboard. In the current admin screen, this functionality is available in the "accessibility mode".

[mapk]

I don't see controls to move / rearrange the widgets by using a keyboard.

Great point! The same accessible keyboard interactions found in the block editor would be adopted here as well.

[mapk]

Based the feedback I've received, I've narrowed down the UX direction.

Single widget area

Show only a single widget area at a time.

Widget area switcher

There is a widget area switcher in the topbar that allows the user to jump to other widget areas.

Widgets in the Inserter

Widgets have their own category in the Inserter panel.

• When in the Widget Editor, the Widget category is at the top of the Inserter.
• When in the Block Editor, the Widget category is at the bottom.
• The block preview of widgets work like blocks.

Moving widgets to other areas

• Moving widgets between widget areas can still be done by copying and pasting blocks.
• In the case of the Inactive Widget area, there is a block toolbar option to "Activate in" with a list of widget areas.
• In the Active Widget areas, there can be a block toolbar option to move the block to "Inactive Widgets".

Prototype

This is how it all comes together. Figma file.

[noisysocks]

Displaying legacy widgets in the inserter is a great idea.

In the Active Widget areas, there can be a block toolbar option to move the block to "Inactive Widgets".

How would this look? Would it say "Activate in ... Inactive Widgets"?

[mapk]

@noisysocks, I have that outlined here: #24698. I wrote it as "Move to Inactive Widgets"

[draganescu]

It's not a small mock-up, but I like it a lot. It does bring in a lot of new things:

• area switcher
• registering each widget as a variation of Legacy Widget
• previews for the variations
• the "activate in" action
• the "inactive widgets area" handling
• a new inserter category

Some of the stuff already exists, the question being if we can simply use them or will we find they're missing bits to enable this workflow. I am optimistic as it looks a lot like the flows the site editor mock-ups show.

[paaljoachim]

I am very hesitant about having a single widget screen, as it would by default hide the overview of the available widget areas. There can be some discoverability issues for the user when entering the widgets screen. There is also no way to drag and drop a widget from one area to another.

Pros and Cons of having a Single Widget screen.

Pro:
As one can add multiple blocks into one widget area it would be nice to keep focus on the one area.

Cons:
It is harder to get a quick overview of all widget areas. As one would need to click the widget area switcher.
It would not be possible to drag and drop widgets from one area to another. As one would need to click the 3 dots icon in the toolbar and choose to activate widget in a specific area.

---

I began exploring the Single Widget mode.
It could actually begin with an All widget areas (Overview etc) mode showing all the widget areas.
Kinda like so:

The advantage here is the user can choose from seeing all the widget areas at once. It would also make it possible to drag a widget from one area to another. I have also included the inactive widget area.

[mapk]

There is some question around what happens when I click the "Widgets" in the wp-admin menu. Does it drop me into an "All Widget areas" screen? or into a specific widget area? or into a list view table of widget areas? Maybe something like this?

[draganescu]

@mapk @paaljoachim the "All widget areas" screen is interesting but it kinda complicates things (a lot? cc @adamziel) Probably that listing is easier, but a new screen to support?

[paaljoachim]

A perspective.
The existing Appearance -> Widgets

User enters the widget screen and sees the available widgets and widget areas.
Goal of the widgets screen as I see it: Is to make "different" content areas such as header, sidebars, footer and other unique content areas easily discoverable and available to be modified.
If we were going to transfer this into a Gutenberg version it would most likely look something like this:

EDIT:
Including a Widgets page title.

EDIT:
Including a Widgets page title and widget area switcher.

New widget screen has a similarity with the existing widgets screen.

If a user uses the Classic Editor plugin the new Widget screen should work nicely even though they are not using Gutenberg.

Full Site Editing in relation to the Widgets screen.
In a page or post screen.
User creates a page or post template and adds in specific sections. We might call these new sections for widget areas. But in relation to Full Site Editing these would just be user defined sections in a page/post template.
These new sections should then show up in the Widget screen as new widget areas.

Single view widget page.

• Greater focus on one widget area at a time.
• More cumbersome to move a widget from one area to another. (No drag and drop)
• More difficult to get an overview of all widget areas. (One might see them in the widget area inserter.)

Multi view widget page.

• Looks similar to the existing widget screen. (making it easier to transition from existing to a new widget screen.)
• Overview of all widget areas.
• Working on one widget area one also sees the other widget areas.
• Drag and drop of widget from one area to another.

I do have a feeling that there is something I am not aware of affecting the way forward.

Edit 2.
For instance looking at: #20877 (comment)
In Full Site Editing the plan is to add the page/post name in the top middle center. Drop down options attached to the name is being discussed. Having a similar layout in the widgets screen will also create an association with Full Site Editing (and likely also content creation in Gutenberg).
This means a new method is being developed. Which includes a top center page/post title with drop down options.

[afercia]

While I see the conversation on the ideal design is still going on, it is important to point out a very important thing for accessibility:

Whatever the final design will be, all admin pages need a good headings hierarchy:

• a main, visible, H1 heading to identify what the page is about
• other headings to identify the page main sections

I see that some of the mockups above just reuse the edit post page design, which has a top toolbar and no visible main H1. At the time of the discussion around the Gutenberg edit post page, this was discussed at length and the accessibility team accepted a visually hidden H1 as a compromise between design and accessibility needs. In a way, the accessibility team considered that decision an "exception". I'm not sure the accessibility need would agree in re-using a visually hidden H1 as default pattern for the new admin pages.

Visible headings benefit all users. To me, it's of fundamental importance that any admin page clearly communicates what its about with a main H1. Headings also allow easy content navigation, both visually, and with assistive technology.

I'll bring this point to the next weekly accessibility meeting for broader discussion. In the meantime, I'd like to kindly ask to review the proposed mockups and add visible headings, including a visible main H1. This is even more important as I'm seeing the layout above being proposed as the "default" new look of all the new admin pages (menus, etc.)

[afercia]

Regarding the "widget area switcher in the topbar": I see that the visible text represent the state and not the available action. Still unclear to me what this control will actually be when implemented:

• If it will be a sort of select element of some sort, it will need a label to clarify the action and the selected option can stay as illustrated in the design because this component will mimic a select element.
• instead, if it will be a button that opens a menu: the button can't be used to represent the state (the selected option). It needs to identify the action. The state needs to be communicated separately.

[afercia]

Headings in the current Widgets page:

• main H1 is visible
• H2 headings identify the page main sections
• H3 headings identify each widget: maybe this could be changed to something else e.g. a list or any other HTML that is semantic enough to represent a set of widgets

[mapk]

Probably that listing is easier, but a new screen to support?

Yes, @draganescu, it would be a new screen. But it would align with all the other list view screens in wp-admin (ie. posts, pages, comments).

The hesitation I have about showing all widget areas in the Editor at one time is that it eliminates the need for individual widget areas and doesn't jive smoothly with showing one editor at a time. I'd like to get more feedback on that.

[noisysocks]

Personally I'd prefer the dropdown option as it's quicker. Going to an intermediary list screen requires a page load.

[mtias]

A few thoughts on the current progress:

• Agreed on having the block library panel open by default, similar to how the current screen works. I'd even consider removing the + toggle in the header entirely and having it always open.
• Without the + it might be fine to lead with page title "Widgets".
• I don't agree with moving the Widgets category to the top. All blocks are "widgets" from a general perspective, and text and images are some of the most common ones to add, so we should leave categories in their current order.
• Focusing on a single area and having a switcher in the header could eventually be a better solution, but not before the site editing project, in my opinion. Right now it's important to minimize changes and retain functionality like moving widgets from one area to another easily. I think this version is a better starting point in that regard:

Also worth considering on very large viewports to stack widget areas horizontally.

The Global Block Inserter doesn't know which area to add a block to without that area being indicated somehow.

The active block area should have some indication. Also the inserter shows a blue line when focusing / hovering a block to indicate insertion point.

[adamziel]

Here's a first prototype of open-by-default global inserter: #24822

[mapk]

Taking in the feedback from @mtias, here's another prototype.

Multiple widget areas on screen

Every widget area the theme provides will be displayed on screen.

Display the page title

As noted by the accessibility team, we should continue to display the page title an an H1.

Widgets are at the bottom of the inserter panel

Although the prototype doesn't really show this, it alludes to it. Widgets would reside at the bottom of the Inserter panel without disrupting the order of the Inserter categories.

3rd party widgets as block variations

The Legacy Widget block will work much like the Embed block. A container block that displays 3rd party widgets as a block variation. I'm still working through how the block's description should read. If the block still reveals itself as a Legacy Widget block as what I believe is being suggested here, than should the widget name be included on the same line as I have it in the prototype, or on it's own line? Or in the block toolbar?

Drag and drop between areas

Showing all areas on screen allows us to keep the drag and drop interaction between areas. Notice that when a block is dropped in a new area, that area is identified in the Document Inspector.

Inserter panel

Inserter panel is open by default, but can close and reopen as needed. This continues in alignment with #24822

Which area is active?

We need a way to identify which area a block will be dropped into when adding from the Inserter panel. If no block is selected, but the area is active, that area is outlined in blue in the prototype. If a block is focused, the block is blue and the system knows to just add the block below the focused block.

---

Prototype

Here's how it all comes together.

[mtias]

Although the prototype doesn't really show this, it alludes to it. Widgets would reside at the bottom of the Inserter panel without disrupting the order of the Inserter categories.

@mapk to clarify, we already have a "widgets" category that holds blocks and many of the core widgets we ported to native blocks. I'd expect we would just register these to that same category. This category shows above Embeds.

[afercia]

Thanks for adding the page title H1.

I may not be updated on the latest designs but I see a difference between the H1+top toolbar design for this Widgets page:

and the one proposed for the Navigation page in #24875

I guess exploring the same design for both pages is already in the works? Since these new pages will also set the new standard for all the new admin pages, I think consistency is key.

[mapk]

I guess exploring the same design for both pages is already in the works? Since these new pages will also set the new standard for all the new admin pages, I think consistency is key.

Just for clarification, I don't think either of these pages are setting any standards for new admin pages. The focus is to bring in blocks without degrading the current experience (improving it ideally). As themes become more block-based, I imagine these screens will be deprecated (only used for older themes) because adding widgets/menus/blocks will happen in the full site editor.

[afercia]

I understand the reasoning but I think that these new admin pages, even if they're in a way "temporary", need to have a consistent design. They will live in the admin for several months, maybe years before they're deprecated. I'd definitely vote to have a consistent design in the admin. There are already too many different admin pages layouts and this isn't beneficial for users under many aspects.

[draganescu]

I think this overview issue reached it's end. We're deep into implementing the proposed designs and each open topic above has gone through their own issue / iteration so far. Can reopen if needed.