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.

[orcunomattic]

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?

[annchichi]

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 the color applied elsewhere, maybe to the icon or stroke.

Yeah, those are good points. Review what we have, and I will explore it and share some progress.

3 notices at one time, the rest being overflowed into the tray? Or is this just a visual update?

Indeed, those are really often seen that notices are yelling for attention on the same page.
@orcunomattic's video showed a suitable type as that was also part of the team discussion. I haven't mentioned it yet but want to propose as another feature request as it feels like another big project we'd need that requires more cross-functional collaboration as it may touches on our whole notification system.

[jasmussen]

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?

That's an interesting idea, yes, this would also allow eliding (see more) buttons for way too many stacked notices.

[jameskoster]

Yeah, collapsing multiple Notices could be a nice interim, until the WP Feature Notifications project gains more traction 👍

I think we should try to respect the tone of the individual notices though.

It would be good to get early feedback from the @WordPress/gutenberg-components team on that, in case it would involve a new component. It may need to be a follow up.

[orcunomattic]

I think we should try to respect the tone of the individual notices though.

I agree, I am thinking the collapsed state can use the urgency style of the most urgent notice in the mix and the expanded state can better differentiate between each notice. Maybe something like this may work:

[jarekmorawski]

Alternatively, we'd display a small summary when the tray is collapsed.

[rogermattic]

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.

@jameskoster I came here to say exactly this! I see an inline notice as an extension of a badge in (at least) some cases! Big +1 on using the same colours (binding them somehow programmatically) and same variants (with icons).

@orcunomattic @jarekmorawski I always have some reservations about displaying multiple notifications at the same time, especially when they’re grouped or hidden under a banner. While a nice banner might look clean, it can make notifications too easy to miss, which goes against their main purpose. Notifications should be noticeable enough to grab the user's attention or follow carefully planned rules around their timing and visibility.

Design guidelines should clearly define when and how notifications are used. They shouldn’t be persistent to the point where we need to hide them under a banner just to clean up the UI. For example:

• if a notification is actionable and blocks other actions (a valid reason to display it), it shouldn’t be collapsible and should have a distinct style suitable for the top of the screen (like the current one),
• if it’s informational—like alerting the user to a disruption, limit, or state—inline notices (like @annchichi suggested) work better. Displaying these in context makes sense, and they naturally wouldn’t need to be collapsible.
• for general updates or feature announcements, which are “good to know” rather than urgent, they belong in a different part of the UI. These shouldn’t disrupt the user’s experience and would benefit from a different style altogether.

[mirka]

Yeah, collapsing multiple Notices could be a nice interim, until the WP Feature Notifications project gains more traction 👍

It would be good to get early feedback from the @WordPress/gutenberg-components team on that, in case it would involve a new component.

We already have a NoticeList component, so we have a certain amount of leeway on how to present that visually.

[jameskoster]

@rogermattic I think that's a good instinct that touches on a related but probably separate topic: Where in the UI can notices appear? This is likely a broad discussion that needs to happen in a dedicated issue. We need to avoid recreating the Notice Chaos one often finds in wp-admin. Maybe only error Notices appear at the top of admin pages and all others live in a Notifications panel...?

In terms of the design for individual notices, here are some other points it would be good to explore/document:

• General best practises, IE when to use Notices vs Snackbars
• What are the do's/dont's around
  • Using titles; how long should they be?
  • Notice content (length, max-width)
  • Actions (when to use, how many)
  • When to make notices dismissible
  • Combinations of tone with other features, e.g. should error Notices always be actionable?
• Responsive behavior—how does spacing adjust as notices appear in wider/narrower locations?