Legacy Widget block: Identify the widget in the toolbar and/or settings sidebar

[mapk]

Problem

Because 3rd party widgets, when added to the editor, often times display many form fields, it is difficult to know which widget one is editing.

Explorations

We need a way to identify the widget that is being edited. @mtias suggested adding the widget name to the Legacy Widget block toolbar. Here's a few explorations. Please ignore the block's icon for now except in the case where it's possible that the block's icon can adopt the widget's plugin avatar.

Feedback

Which of these retains a different feel so that this block isn't easily mistaken as a typical block, but still clearly indicates which widget is being edited?

Settings sidebar

There's always the Settings sidebar that can include the Widget name too. Below are various explorations to think though.

Embed block

The Legacy Widget block is refactoring to match the Embed block using variations for each widget just as the Embed block uses variations for each embed. Currently, when the Embed block is used, there is no clear identification of which embed is included in the Embed block unless it is provided by the embedded item itself. There is nothing in the sidebar either. Take a look at this Twitter embed; it shows the Embed block's icon in the block toolbar and only the Embed block name and description in the Sidebar. Ultimately it's hard to tell if this is a Twitter embed or a Quote block. I'm including this for comparison to gauge how closely we want to align with the Embed block.

I propose we communicate the widget name more clearly so there is no confusion.

[mapk]

Showing the widget name in the block toolbar is probably enough. Repeating that name in the block description would be an added bonus tying it together.

If we're keeping the Legacy Widget icon in the block toolbar to differentiate it from the native blocks, I'm proposing we go with these two below.

Block toolbar

Settings sidebar

[ZebulanStanphill]

A toolbar should only contain controls, shouldn't it? Putting the current widget title in the middle of the toolbar sounds like an accessibility no-no, unless I'm mistaken. It should be put before the start of the actual semantic toolbar (though it can still visually appear as part of it, I suppose).

Pinging @afercia to check this out.

[afercia]

A toolbar should only contain controls, shouldn't it? Putting the current widget title in the middle of the toolbar sounds like an accessibility no-no, unless I'm mistaken. It should be put before the start of the actual semantic toolbar (though it can still visually appear as part of it, I suppose).

Correct. A toolbar isn't a place for labelling the object the toolbar belongs to.

it is difficult to know which widget one is editing

Totally agree with this concern. I'd say it applies to all the widget types, not only to the 3rd party ones. When the new widgets page contains active widgets, what I see is this:

Actually, what I see is a series of visually grouped form controls. There's no indication at all of what widget a group is.

Some text with the widget type does appear when clicking on a group or when tabbing through the groups but this isn't sufficient to clearly identify what these sections are, both from a visual and semantic perspective.

What I'd like to see for this page (and for the Navigation page) is some good information architecture.

• how to better identify the various sections of content in this page?
• is the headings hierarchy meaningful?
• are logically related sections of content and controls grouped together?
• are content and operability still meaningful when navigated in a linearized fashion?
• how can we help users find the section of content they are looking for?
• how can we help assistive technology users to efficiently navigate the page content?
• etc.

The first thing I'd recommend is a better usage of headings. Visible headings benefit all users. Additionally, headings are one of the predominant mechanisms for screen reader users to find content in a page.

In the current widgets page, headings allow to find all that is needed to manage the widgets. Not only the main sections are identified with visible headings: also the active widgets within a widgets area do use headings. Screenshot:

Instead, in the new widgets page there are very few headings:

Removing visible headings doesn't help users find content and it's not a good idea in the first place. Specifically regarding assistive technologies, the lack of headings to identify the widgets would be a clear regression in the accessibility level compared to the current Widgets page.

Personally, and I'm pretty sure many in the accessibility team would agree, I'd just ask to add more visible headings especially the ones to identify the widgets.

[mapk]

What I'd like to see for this page (and for the Navigation page) is some good information architecture.

You're in luck! There's been lots of design improvements and they're about ready for implementation.

The first thing I'd recommend is a better usage of headings. Visible headings benefit all users.

That's what was being explored above by adding the name of the Widget to the block toolbar. Keep in mind that these Widget Areas act just like the post editor, so there won't be headings outside of the existing block content. Now if headings are added inside the blocks to display the widget name... that might be an interesting exploration. :)

To help convey the recent design iterations, I annotated my mockups below.

[ZebulanStanphill]

The first thing I'd recommend is a better usage of headings. Visible headings benefit all users.

That's what was being explored above by adding the name of the Widget to the block toolbar.

Reminder that the widget name shouldn't actually be in the block toolbar. Toolbars are supposed to contain controls only. Something like the widget title should be displayed to the far left before the actual semantic toolbar begins.

[mtias]

@mapk since these widgets are entirely form based and preview is secondary, it might be interesting to display the name of the block within the block outline (inside or over) permanently and leave the toolbar just like any other toolbar.

[mapk]

@mtias I think that's what I was suggesting above.

Now if headings are added inside the blocks to display the widget name... that might be an interesting exploration. :)

Now here are those explorations:

Following the HTML Fieldset tag

Following our Reusable block UI

[bph]

The fieldset feels like a flashback from 2003 :-) I do like the second version: boxes with the title bar (familiar from the current widgets as well as the reusable block views.

[afercia]

Widget Areas act just like the post editor, so there won't be headings outside of the existing block content. Now if headings are added inside the blocks to display the widget name... that might be an interesting exploration

In the current screen, widgets are identified by headings. Removing these headings would be a clear regression in the accessibility level, so I'd encourage to proceed with the "interesting exploration" 🙂

Keep in mind that these Widget Areas act just like the post editor, so there won't be headings outside of the existing block content.

I'm not sure this is a good argument, when it's clear that this screen needs to be as accessible (or more accessible) as the current one. It is clear that treating the Widget Areas like the block editor content area doesn't fit the needs of this specific screen. Also, the headings to identify the various widgets need to be visible otherwise there's no indication at all of what a widget is, see #24870 (comment)

[mapk]

It is clear that treating the Widget Areas like the block editor content area doesn't fit the needs of this specific screen.

Can you elaborate here? What do you believe are the needs for this specific screen that can't be addressed by the block editor?

[mapk]

After sitting on this one for a day (and gathering feedback), let's push forward with this design.

It mimics the Reusable block UI, clearly communicates the widget name, and does these in a simplified way. Keep in mind that on Preview of the widget, the heading area along with the form would be hidden away showing only the frontend preview of the widget. This will also happen when the user clicks away from the block.

[ZebulanStanphill]

@afercia Keep in mind that the block-ified widget areas will also support any existing block, so they are effectively content areas just like that of a post or page. I'm not sure what exactly you're suggesting we should do?

The only major difference between this and the post/page editor is that we're showing multiple widget areas on a single screen. I suspect that probably complicates accessibility, and personally I'd choose to only show one at a time, similar to posts/pages/etc. Maybe even list widget areas the same way we list posts/pages/categories/tags/etc. Would that help?

@mapk That mockup certainly looks better than the current situation, so I'd go forward with it. The only thing I might change is increasing the font size for the heading (or label, or whatever it should be semantically) and getting rid of the line between it and the controls. There's already a solid border around the Legacy Widget grouping the heading with the controls; I don't see a reason to separate it with a line.

[afercia]

Can you elaborate here? What do you believe are the needs for this specific screen that can't be addressed by the block editor?

As I said in a previous comment: more headings 🙂 Please do compare the old page with this new page. The decreased level of accessibility is evident (reminder that headings are also a navigational tool for screen reader users)

we're showing multiple widget areas on a single screen.

This is no different from the old page and I don't think it's a problem. The problem is the overall information architecture not in a visual sense but in a semantic HTML sense (literally; the barebone unstyled HTML).

[ZebulanStanphill]

@afercia Just to be perfectly clear, the headings are for the widget info forms, right? If so, then that sounds easy to implement. And the heading would not be there while the Legacy Widget is in preview mode, right?

Otherwise, it sounds like you're suggesting every block should have a heading preceding it. Because really, what's the difference between the Legacy Widget block and every other block you could insert on the Widgets screen? And quite frankly, I haven't got a clue how that would work.

[afercia]

@ZebulanStanphill I'm not sure I understand what the "widget info forms" are. The point is that headings are navigational tools for screen reader users. For these users, in the new widgets page there's no clear way to navigate through widgets.

Just look at the old page: lots of beautiful headings there 🙂 Now look at the new page: there are only 4 headings. This is a regression in the level of accessibility. Whatever type the widgets are, regardless whether they're in edit or preview mode, there's the need for more headings.

[ZebulanStanphill]

@afercia By "widget info forms" I just meant the set of fields that each legacy widget provides.

We can't just add always-visible headings to the Legacy Widget block in both edit and preview mode. That would go against the preview mode being, well, a preview. It goes against the goal of the editor trying to be WYSIWYG.

And if you only add headings to the Legacy Widget block, then that's inconsistent, because there are many, many other blocks that can be inserted on the same screen. Why would the Legacy Widget block be the only one to have headings?

And if you do add (visible) headings to all of them, then the editor ceases to be WYSIWYG at all.

Furthermore, you could insert a Heading block into any of the widget areas. How does that play into this? Because some headings would be editor-only, but others are actually front-end content, and how would screen readers know the difference? Or should Heading blocks not actually use h1-h6 tags in the editor?

I don't see any problem here that wouldn't also exist in the post editor. And I assume you're not suggesting we add headings to every block there... are you?

I think you're making a mistake by viewing the experimental Widgets screen as similar to the current one, when in reality they're completely different. The current Widgets screen in core is more like the "Document settings" sidebar than the editor canvas.

The experimental Widgets screen is not a series of collapsible panels containing controls. It's a full-fledged WYSIWYG editor, and that seems inherently opposed to the idea of having headings like the ones used in the current Widgets screen.

[afercia]

I'd argue that this page will hardly ever offer a real "preview". By the way, we need to find a way to make it be not a regression compared to the current page. Maybe "modes" could be the answer also in this case. Maybe a deeper separation between Edit and Preview mode could help.

And if you only add headings to the Legacy Widget block, then that's inconsistent, because there are many, many other blocks that can be inserted on the same screen.

In a fist moment I didn't get that also other non-widget content can be used in these areas. I tend to call everything generally a "widget". Other blocks would be sort of "widgets" meaning: content that is displayed on every page in these areas, right? Conceptually, that's not so different from "free-form" widget as in: a widget (block or set of blocks) that builds a piece of content comparable with a widget. How users can identify and navigate to these distinct pieces of content? It hsi is correct, my point about identification and navigation to distinct "units" of content still stand.

The experimental Widgets screen is not a series of collapsible panels containing controls. It's a full-fledged WYSIWYG editor,

Certainly it renders the blocks in a "WYSIWYG" way. Not sure the overall preview will ever be close to the real appearance of the bock areas on the front end. That's why I said I'm not sure there will be a real "preview".

Regardless, we need to find a way to make this page more understandable and content more discoverable. The block editor is a different case because users expect the list of blocks in the post content. Instead, this page is more complex and has different sections that have different purposes. The semantic structure of the page and the headings hierarchy needs to be greatly improved. In a so complex page, only 4 headings are, honestly, far from ideal.

[mapk]

And the heading would not be there while the Legacy Widget is in preview mode, right?

Correct.

And just to clarify, I believe we have the individual heading issue resolved in the latest mockup above. It follows existing UI for the Reusable block and clearly communicates the heading before the user jumps into the widget's form fields. In addition, everything that needs a heading has one. The page has a heading, the widget area has a heading, and each widget has a heading.

[bph]

I am reading through this exchange and I think it's not clear yet, but it seems to move into the direction, that there is no goal of feature parity between the old and the new. Let me break it down a bit. And this might not only an issue for the legacy widgets it might be a significant change for the future of widgets that should be discussed. And if it's better to discuss this some other place, let me know.

Setting screens for widgets:
in the current widget screen, it's more a settings screen to identify which widget goes into which block area. That works similar to the current screen for legacy widgets. There are not particular settings for using core/blocks in block areas, that are different from the edit post settings. The widget registration

Title/heading on Admin
The current screen takes its cues from the widget register array with name and display name. The title is shows on top of the settings in the screen to identify the nature of the widget. Given the above mark up this seems to be working like that also in the new version.

Title/Heading change: in the current Widget screen the end user could change the title via the admin screen. So instead of the "Recent Posts" a user might decide to call it "The Skinny". This functionality seems to be removed in the current mock-ups.

Title/heading on the frontend
in the current handling of widgets, the widget name is pulled into the front end by the theme. It helps with identifying what kind of content is displayed. It also is pulled into the front end of the widget. The legacy widget seems to still have that functionality. For using core/blocks in a block area, like the 'Latest Posts" block, in a sidebar, you now need to also add the heading block separately. This is a fundamental change how widget work currently

I might be quite late to the discussion and tests, so I must have missed the discussion on omitting the title/display name from the widget registration. Are there other properties that will be handled differently from the current widget handling?
How will current widget functions be handled? is_active_widget() is_active_sidebar() the_widget() That allowed for styling etc.

As I said, I am aware that I am quite late to the party and I need to read up about all the decisions that were already made to answer my questions

[ZebulanStanphill]

Title/Heading change: in the current Widget screen the end user could change the title via the admin screen. So instead of the "Recent Posts" a user might decide to call it "The Skinny". This functionality seems to be removed in the current mock-ups.

@bph Unlike the legacy widget, the Latest Posts block doesn't have a heading built-in, so I think the idea is that you would use a Heading block to provide one.

[bph]

@ZebulanStanphill - This is a discussion of Legacy Widgets and it's in the API that there is a title and the old widget screen as well as the current version of the Widget screen allows for editing the title. The mockups by @mapk don't seem to allow for a change of the titles.

[ZebulanStanphill]

@bph I assumed the mockups just weren't showing any legacy widgets with title fields.

[mapk]

I assumed the mockups just weren't showing any legacy widgets with title fields.

Correct. I assume if the Widget provides a Title field as part of their form, it would show in the Legacy Widget block. If the title is filled in, I also imagine that it might be interesting to change the Widget Title in the UI to match. If the widget provides a way for that title to be visible on the frontend, I also expect it to show as it does today.

[bph]

With all the changes between old widget screen, current widget screen and proposed widget screen, it felt It wasn't a fair assumption to make anymore. Glad I was wrong.

[afercia]

I am reading through this exchange and I think it's not clear yet, but it seems to move into the direction, that there is no goal of feature parity between the old and the new.

No one is saying that the old and new screen must provide the same features in the same way. However, before stating that "there is no goal of feature parity", I'd recommend to consider that no individual person in this project, except the owner and the tech leads, can make final decisions. Until that happens, design and development decisions are discussed and made by the teams and the single contributors that contribute to this project. It's a collaborative process.

In this collaborative process teams and contributors do discuss (and it's good that they do so) which features should be kept and which ones can be removed to build a better product. From an accessibility perspective, what needs feature parity in this new screen is the general level of accessibility. The new screen has a clearly reduced level compared to the old one.

@bph to me, your statement "there is no goal of feature parity" sounded a bit like something that came out of the blue and to be frank a bit disrespectful of the efforts and dedication that many are putting in this project. I assume good intent so it's probably something related to language barriers 🙂 (I'm not a native English speaker).

[bph]

@afercia - Sorry you feel disrespected, certainly not my intent. I was just making an observation on something I try to understand. In yesterday's meeting, @youknowriad confirmed my hunch: "The APIs you raise there are probably something to look at and see whether support is possible, but we shouldn’t be expecting 1-1 parity”. The team answered more of my questions during the meeting's open floor section.

[kevin940726]

Did #25638 fix this? I'm skimming through the discussion and I couldn't find any action items left.

[adamziel]

I think the sidebar differs a bit compared to the design:

It seems like the only way to make it consistent with the design below would be to register each widget as a separate block with custom description, as variations are just default set of parameters and can't augment the block description:

[adamziel]

cc @mapk on the comment above

[mapk]

Good catch, @adamziel. If the only way to make my desired design work is to register each as a separate block, then let's hold off.
The current solution using an accordion item specifically to state the widget's description isn't good either. Can we create it in such a way that isn't an accordion?

Maybe something like this:

[noisysocks]

Noting here that if we go ahead with #25741 (and right now I don't see why we couldn't) then we can implement the sidebar design in #24870 (comment).

[noisysocks]

We probably should continue to show the legacy widget's description though, no? I am thinking #24870 (comment) might therefore be the better design regardless of #25741.

[mapk]

Correct @noisysocks. From my understanding, 3rd party widgets should be block variations of the Legacy Widget block which means that the Legacy Widget block description and title should show in the sidebar. That being said, we can then just show the 3rd party widget name below that.