Update `Notice` component design

[annchichi]

What problem does this address?

Heya @jameskoster
Coming from the Woo team, we discussed the notice components from both the WordPress Design System (WPDS) and our Woo library. While we aim to align with the design system as much as possible, we'd like to discuss some specific considerations for inline notice usage.

Current status
WordPress Design System (WPDS) banner notice

• Primary use case: page-level alerts above content

Woo's inline notice

• Developed specifically for Woo UI integration (e.g., within settings sections)

Observations on Current WPDS
Design elements

• Banner notices have a larger "X" close button
• Informational variant currently lacks background styling

Accessibility:

• The current Error banner notice may need to be reviewed for color contrast. For example, it shows text and background contrast ratios (APCA just passes at 60). The button and background contrast is a bit low here.
• Text and button contrast against red background requires improvement

What is your proposed solution?

Proposed enhancements
We'd like to suggest the following additions to the WP notice component:

• Option to remove left border when needed
• Have variants for inline usage
• Support for optional icons (as currently implemented in Woo's library)
• Exploring the inline notice in Figma a bit and left some notes for you.
  This is for sure not final but want to bring the visibility to you and get your feedback on direction first before we move further. Or need to follow WPDS button style. Then Magda (I dont' know why I can't tag your name) and I will continue to work on it.

Note
We can reuse Magda's proposed badge component colors:

• Reuse the newest Gutenberg color mixins
• Provides consistent, easier implementation for developers

Thank you!

[jameskoster]

I agree the Notice component is long overdue a tune-up :)

Option to remove left border when needed

Removing the left border in general is probably a good idea, it interferes with spacing when inset, and can disappear entirely when outset (if the notice is full width inside a container that clips).

Support for optional icons

We might consider following the emergent convention in the Badge component. IE an icon is always included when the 'tone' is warning, error, or success. This helps a11y since color alone is not an adequate indicator.

Have variants for inline usage

Could you elaborate on this, perhaps with a screenshot example?

---

From the core side of things we should also keep in mind the notices that appear in the editor:

Currently these use the Warning component, which I believe is private to the block editor package. If we can find a design that works then there could be opportunity to use Notice instead, and deprecate Warning.

cc @jasmussen @jarekmorawski as we were recently discussing this :)

[jasmussen]

Removing the left border in general is probably a good idea, it interferes with spacing when inset, and can disappear entirely when outset (if the notice is full width inside a container that clips).

I would agree. For example I think there are some good patterns to take inspiration from, that @fcoveram worked on for WordPress.org:

I'd also tentatively agree that we really don't need that many different visual styles for notices and warnings. They could all look mostly the same. As a provocation: what if they all looked like snackbars, same color too?

[jameskoster]

As a provocation: what if they all looked like snackbars, same color too?

There's definitely some conceptual overlap, so they could share characteristics like radius and elevation. However, I'd recommend avoiding a dark background for now. This is primarily because Notices can include action buttons, and the only Button variant we currently have that works well on a dark background without overrides is primary. While it might be fine for one notice action to use a primary button, having more than one is likely not ideal.

[Mamaduka]

The editor error boundary no longer uses the Warning component (see #64245). I am happy to update it and match the new design patterns.

The Warning block editor component is a public API, mainly used for in-canvas block warnings like - invalid content.

Should we close this old issue in favor of a new discussion here - #34901?

Screenshot

[jameskoster]

Should we close this old issue in favor of a new discussion here

Seems okay to close the old issue. I'm not 100% sure the designs there adhere to the latest conventions for details like typography.

[annchichi]

Could you elaborate on this, perhaps with a screenshot example?
Yeah, I attached it in the link. Pardon for not getting the screenshot, @jameskoster

In WooCommerce's inner notice, we have four colors.

• I adjusted the color to match the badge component, with and without icons also.
• Banner style taken from the design system. But I was not sure about the button style.
• My exploration file is here and left some notes and mentioned you in Figma @jameskoster.

Agreed with what @jasmussen mentioned that we don't need that many colors. Would love to know what y'all think and how we can proceed. Thank you!

[jameskoster]

I reckon we can mimic the badge behavior when it comes to icons—If the tone of the notice is error, warning, info, then the icon is included automatically. This is because color alone is not an accessible way to communicate the tone, and the icon gives a familiar at-a-glance indication of the nature of the message.

It would be good to think about guidelines for when to use Notices too. For example do we need a neutral notice? Or should notices only be used in situations where a tone is required?

Then there's the action buttons to consider. Theming them to match the notice color is going to add a lot of complexity that I don't know is warranted for such a narrow use case. I wonder if the notice background could be white, and color applied elsewhere, maybe to the icon or stroke?

[jasmussen]

Good instincts. Relatedly, how can abuse be discouraged? As soon as something becomes pinned and loud like this, it can be used for malicious purposes. "WooCommerce database update required" seems valid enough, as does "There's a new version of WordPress". But "Take part in our Black Friday sale, no now!" is less so. Further: what happens when 10 different plugins send 10 such notices? To be fair they may all be important, but unless you act on them one by one, it's not going to be a legible to anyone.

To frame the question differently: should conversations about changes to the notice compenents inner behavior be related to conversations about a notifications tray, that might let us throttle and show at most, say, 3 notices at one time, the rest being overflowed into the tray? Or is this just a visual update?

[jameskoster]

Yeah we should keep the Notifications project in mind, although there hasn't been an update in over a year so it doesn't feel imminent(?). For now this is mostly just a visual update, but let's consider how the notices would look in a narrow container like a notifications tray.

[orcungogus]

Another thing to consider for this component is how we can better accommodate multiple notifications (with different weights) on pages within the WP ecosystem. This is a very common scenario and stacking notifications is not a scalable solution.

We can set up the rules for the Notice component so that it gets swapped with a Multiple-notices component when there is more than one notice on a given page. Below is a quick take on it, WDYT?