Advisory banners need to changes and implemented as something else.

[irishetcher]

Is your feature request related to a problem? Please describe.
Change the advisory banners that appear over the title when page is published, updated or when there is an auto-save warning etc. This UX implementation looks clumsy and doesn't fit with the general look of the new block editor

Describe the solution you'd like
Something a bit more subtle elsewhere in the interface. Something dynamic like if you temporarily displayed in the top bar over by the Preview / Update buttons. Or, even if the the View Post item in the admin did some sort of subtle highlighting to suggest that should be clicked.

Describe alternatives you've considered
Sorry if I don't have any concise suggestions but I think that the new block editor needs a little bit more polish here and elsewhere.

[kjellr]

Hi @irishetcher — A recent PR #13614 has recently changed the way these work. Notices will no longer appear on top of the actual content, blocking it from view. They instead push the content down the page a bit.

Please take a look and let me know if that's similar to what you had in mind.

[aduth]

@jasmussen Could you weigh in on whether you'd consider this as satisfied by recent improvements in #13614 ?

Otherwise, we should direct this issue to actionable tasks.

[jasmussen]

Hey! Thanks for the ticket.

Yes, the recent PR should drastically improve how these notices work:

• They now push down content, so they don't cover it
• They don't cover scrollbars anymore, this one was particularly clumsy

I do personally agree that notices as a whole, in all of WordPress actually, can benefit from both visual and technical upgrades, and some diversification, though I'm unsure if there's bandwidth to tackle these in the immediate ongoing phase.

Take the Material Design system, for example, they have the concept of "banners", which roughly correlate to what we have for notices: https://material.io/design/components/banners.html

But they also have a concept called a "snackbar", which can make sense for some prompts: https://material.io/design/components/snackbars.html

Figma uses a snackbar for informing you that it automatically saves documents. In this GIF I pressed ⌘S three times in a row:

We might not want to copy that particular notification, but I would love to see a system for snackbars in WordPress, so we can show a little message that says "Copied to clipboard!" when you press the "Copy All Content" button in the More menu.

That might be the actionable next step: consider a new component for "snackbars", and consider for which actions to show it, and for which existing notices to convert to snackbars.

Thoughts?

[davewhitley]

I think that's a great idea. To help think about what kind of messages would use this new type of notice, I'd consider these guidelines:

• Informs users of a process that has been performed, will perform, or tried and failed to perform
• Non-interruptive, and doesn't require the user to dismiss it (goes away after a period of time)
• Should contain no more than one action
• Shouldn't get in the way, and they appear in the context in which you are working

Here's another example https://ant.design/components/message/

[melchoyce]

I like the idea of having temporary, out-of-the-way notifications — our current notification system is pretty clunky. I do worry a little bit about third-party usage, though.

I was wondering about a11y settings, and found this on Angular's Material components doc:

Accessibility

Snack-bar messages are announced via an aria-live region. By default, the polite setting is used. While polite is recommended, this can be customized by setting the politeness property of the MatSnackBarConfig.

Focus is not, and should not be, moved to the snack-bar element. Moving the focus would be disruptive to a user in the middle of a workflow. It is recommended that, for any action offered in the snack-bar, the application offer the user an alternative way to perform the action. Alternative interactions are typically keyboard shortcuts or menu options. When the action is performed in this way, the snack-bar should be dismissed.

Snack-bars that have an action available should not be given a duration, as to accomodate screen-reader users that want to navigate to the snack-bar element to activate the action. If the user has manually moved their focus within the snackbar, focus should be placed somewhere sensible based on the application context when the snack-bar is dismissed.

Don't use "Dismiss" as a snack-bar-action, instead preferring to use a duration when there is no additional action associated with the notification.

I almost feel like it would be better to use snackbars for anything that doesn't require an additional action, and have them only be used for immediate feedback on a particular action.

[melchoyce]

Some more examples:

Polaris: https://polaris.shopify.com/components/feedback-indicators/toast#navigation
Lightning: https://www.lightningdesignsystem.com/components/toast/#site-main-content
Canvas: https://canvas.hubspot.com/components/alerts-messaging#floating (Shown at the top of the screen)
Carbon: https://www.carbondesignsystem.com/components/notification/usage (Shown in the top right corner)

Also — Toast? Snackbars? Why are we like this, internet friends? Do we need a snack?

[getdave]

I almost feel like it would be better to use snackbars for anything that doesn't require an additional action, and have them only be used for immediate feedback on a particular action.

If the bar is transitory (ie: auto dismisses as per Material guidelines) then it might be less open to abuse as any messages wouldn't be persisted to the UI.

I'm very interested in seeing something like this land, but it would require careful usage guidance.

[jasmussen]

Also — Toast? Snackbars? Why are we like this, internet friends? Do we need a snack?

A webdesigner walks into a bar. Bartender asks, what'll it be? Webdesigner says:

• "can I see the hamburger menu?"
• "let me have a look at your kebab menu"
• "does your snackbar feature toasts?"

[garretthyder]

Hello, coming from #14402 I went back to review the original merged request #13614 and wonder if the overlap issue can simply be resolved by removing the distinction between dismissable and non-dismissable notices on scroll. If they were to all simply stay in position instead of being sticky they still serve their purpose, don't require much extra effort and avoid interference with the editor interface. Once a user scrolls or is interacting with the blocks the notices should take a backseat, they'll always be there on reload or page navigation and scroll back to the top.
In the majority of cases notices have less to do with the editing of content than with information that should be presented on page load. I can see the editing cases where information about blocks being added/deleted/duplicated or validation errors on block editing moving more to the snackbar than notices as they should be visible while you're editing lower on the screen.

Sorry I hope that thought makes sense.
TLDR; Don't make notices sticky they interfere. Continue with introducing another mechanism like snackbar for information relevant to the current editor experience.

Thank you for the continuously intrepid innovations. Cheers

[jasmussen]

by removing the distinction between dismissable and non-dismissable notices on scroll

One concern worth noting is that if you are working on a long document and press "Publish", you are unlikely to see the notice that the publication was succesful because the banner will be out of sight way at the top.

I would suggest that the snackbar as is described in #13905 (comment) is a great way to address that issue — they are transient, contextual, and not disruptive.

[garretthyder]

One concern worth noting is that if you are working on a long document and press "Publish", you are unlikely to see the notice that the publication was succesful because the banner will be out of sight way at the top.

I would suggest that the snackbar as is described in #13905 (comment) is a great way to address that issue — they are transient, contextual, and not disruptive.

Thanks @jasmussen I see what you mean with the publish notice, I was thinking that would reload the screen and leave you at the top like it did with Classic Editor. I agree in those cases where the information is relevant to the editor such as the publish/update or block errors would make more sense in the transient snackbar as they'll be less intrusive and go away after time so won't need a dismiss action. I definitely second the comment you referenced there.

[karmatosed]

I am removing the 'User Experience (UX)' label as part of a label cleanup. It's not being used anymore consistently so let's try and keep to 'needs design' and 'needs design feedback'. If we find a need for another label we can consider it but having those 2 should cover this.

[kosso]

Since we have a 'headless' setup, with Wordpress on one domain and the actual site on another (via the REST API data and Angular), prior to Gutenberg, we could alter the 'View Post' text and link via the post_updated_messages filter.

This new snackbar does not appear to respect any changes made with that filter.

(The text used in the snackbar is set within wp-includes/post.php in the get_post_type_labels() function's $nohier_vs_hier_defaults array. )