Try using snackbar notices instead of prominent ones for saving/failure notices #15594

youknowriad · 2019-05-13T10:26:13Z

closes #13905, closes #11807, closes #12127, closes #15132

This PR is a first stab towards using snackbars for post save/error and reusable blocks save/error notices.

Todo list:

Improving the design
Fix the accessibility issues (contrast and focus styles...)
Tests
Documentation and Changelog
Potentially implement a timeout

You can test quickly by creating random notices in the console:

wp.data.dispatch('core/notices').createNotice(
		'info',
		'Post published.', // Text string to display.
		{
			isDismissible: true, // Whether the user can dismiss the notice.
			// Any actions the user can perform.
			type: 'snackbar',
            actions: [
				{
					onClick: () => console.log( 'test' ),
					label: 'View post'
				}
			]
		}
	);

jasmussen · 2019-05-13T10:42:30Z

Quick GIF:

This is really nice!

Aside from a little design polish — I'll help here — this is a really great first stab. A few quick thoughts, but I'll let others chime in as well:

Snackbars exist in addition to notices, but are great for things that are less important. Like "save successful", or "this is a reusable block, changes made affect all posts that include it", things like that. Because we can only show information that you could afford to miss, we don't really need more than a single visuals style for these, i.e. no need to distinguish levels importance with color. I would suggest we go with a dark gray.
Snackbars disappear after a while.
There can only be one snackbar at a time, which means if you send off multiple, they should be throttled and shown in sequence, one at a time.

nerrad

I like this ui pattern so I think it'll be an improvement for certain types of notices. A couple thoughts though:

In general the notices system in WordPress is in the need of an overhaul and I think GB is starting to establish new patterns for notices that could eventually replace what's currently in WP. I think some consideration needs to be given to how this works/looks for the rest of WP as a whole as we add these new patterns.
I wonder if snackbar notices should be a bit more opinionated about what is allowed as content. Typically they are shorter snippets visually notifying of an action that just completed. So should there be some rules applied to not only what content is allowed in them, but also how much content?
I wonder if notices created by WP/GB core should have a reserved style for them? Doing this would allow for easier distinction (both visually and accessibly) between what notices are added by WordPress/GB and what were added by a plugin.

nerrad · 2019-05-13T11:00:04Z

packages/components/src/snackbar/index.js

+} ) {
+	const classes = classnames( className, 'components-snackbar', 'is-' + status );
+
+	if ( __unstableHTML ) {


How long has __unstableHTML been around and is this a pattern that should continue to be replicated in new things? Is there any attempts to remove the necessity for it being __unstable?

That's a good question, I think we should do an audit of the experimental APIs and see which ones can be made "stable".

That said, I think __unstable is a bit different in the sense that it's not meant to be made stable at all. It's something used internally that third-party developers shouldn't rely on. That doesn't mean the use-case here is not legit and shouldn't be exposed but it shouldn't in its current form. For this particular one @aduth knows more.

I think in this case, it was added to support back-compat with the old notice system which allowed plugins to add arbitrary html (and was related to some work @aduth did with automatically porting usage of add_action( 'admin_notice' ) over to the notices in GB.

Maybe we can just remove it, in that case as we don't support these admin notices anymore

I think at a minimum it should be removed/ignored for the new snackbar notices. I'm not comfortable making the call in general for all notices though.

So... this one's been on my mind lately.

It's not used anywhere in Gutenberg currently. It was originally part of some compatibility effort for server-rendered notices which was dropped late in the 5.0 release cycle. In fact, I still have an open pull request to remove it: #12440 . We would be safe in removing it.

This sat longer than I'd liked, and I know of several occurrences of people indicating they're using it, despite repeated warnings of its unstable nature. The last time it came up in a #core-js chat, we said that we didn't care, and that we'd still remove it since we're not obligated to the backwards-compatibility. It doesn't sit well with me though, largely on the point that we let this specific one linger, and thus it's more "on us".

My latest thought was to do a search in the plugins repository for who might be using it, and to both (a) consider their use case and (b) reach out to them directly ahead of its removal.

I ran the search now:

https://wpdirectory.net/search/01DAVD7SA20EYCQM5K456HMYNK

There aren't quite as many hits as I had expected, but certainly some popular ones.

I think regardless whether we decide to do it now (for which an argument could certainly be made), considering the use-cases is valid.

For example, one instance I'd heard that someone still chose to use __unstableHTML was the need for dismissed notices to be persistent. This seems like a useful feature that we'd want to consider to implement anyways.

Maybe we should flag this in #core-js and also try reaching out to those using it to gather feedback on the use-case requirements for it? Then we could try to implement something that satisfies common use-cases.

Maybe we should flag this in #core-js and also try reaching out to those using it to gather feedback on the use-case requirements for it? Then we could try to implement something that satisfies common use-cases.

I've added it to the agenda as an item to discuss:

https://docs.google.com/document/d/1h21-24QSi02QXr3qMqUAkzpT4B02Ep3ZKKI2qhgwUUw/edit

davewhitley · 2019-05-13T20:00:36Z

To piggyback off of Joen, some additional guidance:

Used for low priority, non-interruptive messaging.
Actions should not use a filled button, it draws too much attention.
An action is not required.
They automatically disappear from the screen after a minimum of four seconds and a maximum of ten seconds.
They shouldn't use a close icon because they disappear automatically. Although, with more research we may find that we need one.
Don't use icons in snackbars, it draws too much attention.
Content should be short, no more than 2 lines.
Action button can drop to a line by itself.
On desktop, the snackbar should be consistently placed. My preference is the bottom center, which I think works in more contexts.

youknowriad · 2019-05-14T09:27:24Z

I added a timeout, now these notices disappear after 10 seconds.

youknowriad · 2019-05-14T09:28:12Z

packages/components/src/snackbar/index.js

+} ) {
+	useEffect( () => {
+		// This rule doesn't account yet for React Hooks
+		// eslint-disable-next-line @wordpress/react-no-unsafe-timeout


This rule doesn't account for React Hooks. It should be possible to use and cancel timeouts in useEffect or other hooks.

Tracked here #15622

packages/components/src/snackbar/index.js

youknowriad · 2019-05-14T10:04:04Z

In general the notices system in WordPress is in the need of an overhaul and I think GB is starting to establish new patterns for notices that could eventually replace what's currently in WP.

These snackbar notifications are low-priority and contextual notifications. I think they defer a little bit from what would be a notification system in WordPress where notices could be persisted across pages and have persistent actions.

That said, the patterns introduced here can easily be reused in different pages thanks to the "notices" package.

packages/components/src/snackbar/index.js

sarahmonster · 2019-05-15T11:40:02Z

So happy to see this happening! This is something we'll need for the navigation menu block as well, which we added in part thanks to @LukePettway's accessibility feedback. 🙌

Our initial mockup here uses the colour system of levels, but I'd be in agreement with @joen that these aren't strictly necessary here, especially if we create guidelines that encourage developers to avoid snackbars for critical (error) messages. Here's a quick idea of how this could potentially look:

Let's look at how we can make this component as accessible as possible from the outset. Providing clear and consistent messaging in flexible ways has the potential to improve the product for all, by providing more helpful and contextual information without overloading users.

I've done some looking around to establish guidelines, but it would be great to get the accessibility team's input here.

Ensure any action is also available elsewhere in the UI so that all users can reach it. Any action link should be supplementary.
Use a Notice component for error messages, so they're persistent. (This also means the importance of colour to denote status isn't necessary, since every snackbar is then informational.)
Use role: status and aria-live: polite to ensure the message is read out, but isn't given prominence over other, more critical elements.
Snackbar should disappear after a relatively longer period of time to allow people time to interact with them (10s) and should also be dismissable (even if via a non-visible action, like tapping on the snackbar itself) so as to ensure it doesn't get in users' way and allow for more choice.
Pressing the ESC key while one of the snackbar’s child elements has focus (e.g., the action button) will dismiss the snackbar.
Copy within the snackbar should be clear and concise. (Maybe we can suggest a format here, like verb + noun or similar... along with an example. This is especially important when the message will only be shown for a limited time.)
Focus should not move to the notification unless the user expressly moves to it. (Given that it's an overlay, this might present some challenges as to how exactly focus moves to the element, and there seems to be some conflicting advice on this, depending on whether the snackbar has an action or not.)

More reading:
https://inclusive-components.design/notifications/
https://www.w3.org/WAI/perspective-videos/notifications/
https://tink.uk/accessible-timeout-notifications/
https://www.lightningdesignsystem.com/components/toast/#site-main-content
https://polaris.shopify.com/components/feedback-indicators/toast#navigation

packages/notices/src/store/actions.js

youknowriad · 2019-05-16T09:31:18Z

packages/components/src/snackbar/README.md

+
+1. [Design guidelines](#design-guidelines)
+2. [Development guidelines](#development-guidelines)
+3. [Related components](#related-components)


I think it would be a good idea to start adding "Accessibility guidelines" to all these component READMEs similar to dev and design. cc @audrasjb @LukePettway

That's a great idea!

youknowriad · 2019-05-16T09:33:33Z

I updated the design, the a11y messages, I added a small README that can be iterated on, I didn't test everything yet but we can open this for review now.

youknowriad · 2019-05-22T14:04:07Z

packages/editor/src/components/editor-notices/style.scss

+
+	@include break-large() {
+		width: calc(100% - #{ $admin-sidebar-width });
+	}


Ideall,y the styles that are specific to "WP Admin" should move to this stylesheet packages/edit-post/src/components/layout/style.scss since the styles in this file can be used in any context (think a page where there's not sidebar...)

👍 That's really helpful to know—I was wondering why there were styles for this component outside of the component itself. It makes things a bit confusing to work with. I'll try to move anything that refers to the sidebar over to that file.

youknowriad · 2019-05-22T14:05:19Z

packages/edit-post/src/components/layout/style.scss

@@ -30,7 +30,8 @@
 @include editor-left(".edit-post-layout__content .components-editor-notices__snackbar");


I'm assuming this mixin is not needed anymore if you want to center them

👍 Definitely had no clue what this was for. 😜

sarahmonster · 2019-05-23T09:50:09Z

I've done my best to fix the design issues outlined my comment above with the exception of the animating-in issue, which we can look into in a separate PR.

I had a bit of troubles with getting the notices centred on all permutations of the sidebar view. I think it may be that I'm not fully grokking how the auto-fold and folded CSS classes are applied to the document body, and I'm missing something. I couldn't figure out the proper CSS class to target in these situations:

For what it's worth, the second scenario here suffers the same issues with the left-aligned approach, so it's probably only critical that we fix the other two scenarios. I'd love some guidance here from someone who's a bit more familiar with the CSS code than I am, since I'm finding it a bit of a challenge to wade through. 🤯

youknowriad · 2019-05-23T09:53:40Z

I had a bit of troubles with getting the notices centred on all permutations of the sidebar view. I think it may be that I'm not fully grokking how the auto-fold and folded CSS classes are applied to the document body

That's exactly why I suggested that we keep the left aligned ones. I also prefer them visually (but I can see how this is just a personal difference). Maybe @jasmussen could help here

jasmussen · 2019-05-23T10:02:21Z

I had a bit of troubles with getting the notices centred on all permutations of the sidebar view. I think it may be that I'm not fully grokking how the auto-fold and folded CSS classes are applied to the document body, and I'm missing something. I couldn't figure out the proper CSS class to target in these situations:

Yes, this is quite messy. We have some mixins to take some of the vinegar out of here, but even then it's not superb.

In fact although it may look nice when centered according to the main column, perhaps it would be worth to think of these notices outside of the boundaries of the editing canvas, but even think of them more as "global notices" for all of WordPress. Which means we could simply center them absolutely, regardless of left or right sidebars (easiest), or even left align them on desktop breakpoints like Gmail does:

The material guidelines seem to suggest the same, which we can choose to take inspiration from.

aduth · 2019-05-24T14:39:17Z

Would this close #15132 ?

youknowriad · 2019-05-29T10:44:37Z

In an attempt to push this into a mergeable state and given the technical complexities and the fact that the left aligned snackbars can work just as well. I restored the left alignment for now.

What's left in this PR? Can I get an approval?

jasmussen · 2019-05-29T10:47:23Z

From a design POV, 👍 👍. We can always explore additional tweaks to how to position this best in any subsequent PRs, but it shouldn't block a wonderful component from shipping. All this needs is a code sanity check.

youknowriad · 2019-05-29T12:39:02Z

Ok let's ship this @aduth and @nerrad already reviewed this from a code perspective and it's good to land early in the release timeline.

mapk · 2019-05-29T14:09:08Z

🎉 Excellent work! Thanks for exploring this @youknowriad!

jwold · 2019-06-06T15:06:38Z

Just want to add my two cents, that from a design perspective the snackbar notice feels much more elegant and simple. Love it!

QuietNoise · 2019-06-13T05:16:28Z

They are lovely.
Can I comment on the fact that they are however not UX perfect when creating new posts.
Because they disappear over time there is no quick way to 'View post' because on new posts the View post link does not yet appear in Admin bar (your example shows that as well).

Admin has to either re-save to see the notice again or refresh the page to see the View post link in admin bar.

jasmussen · 2019-06-13T07:13:39Z

Because they disappear over time there is no quick way to 'View post' because on new posts the View post link does not yet appear in Admin bar (your example shows that as well).

This is a good point. In absence of a different interface for viewing post, perhaps that notification should be a dismissible notice instead of a snackbar. Would you mind opening a new ticket for this? Feel free to CC me.

youknowriad · 2019-06-13T08:36:59Z

I think I disagree with this, when you publish a post, the "view link" is always visible on the post-publish panel unless you start typing.

If we want to improve further, I'd rather think of ways to show an always visible "View post" link in the UI instead of relying on notices.

sarahmonster · 2019-06-14T01:40:49Z

One of our design principles for the snackbar notifications is that any action link will always be available elsewhere in the UI.

This link isn't super prominent right now though, and (I suspect) that the most common action users want to take after publishing a post is viewing that post. IReverting back to a more disruptive notice may not be the best solution here—instead, we should either provide a more prominent link in the post-publish interface or consider redirecting the user to the post, and showing a notification with more post-publish options. (See: changes suggested in #7602.)

youknowriad requested review from aduth, jasmussen, nerrad, mapk, alexislloyd and mtias May 13, 2019 10:26

nerrad reviewed May 13, 2019

View reviewed changes

youknowriad commented May 14, 2019

View reviewed changes

packages/components/src/snackbar/index.js Show resolved Hide resolved

nerrad reviewed May 14, 2019

View reviewed changes

packages/components/src/snackbar/index.js Show resolved Hide resolved

mapk mentioned this pull request May 14, 2019

Users can duplicate post titles #15282

Open

kjellr mentioned this pull request May 14, 2019

Undo and Redo functions do not communicate changes #15297

Open

sarahmonster added Needs Accessibility Feedback Need input from accessibility Needs Design Feedback Needs general design feedback. labels May 15, 2019

youknowriad commented May 16, 2019

View reviewed changes

packages/notices/src/store/actions.js Show resolved Hide resolved

youknowriad commented May 16, 2019

View reviewed changes

youknowriad added the [Feature] UI Components Impacts or related to the UI component system label May 16, 2019

youknowriad marked this pull request as ready for review May 16, 2019 09:32

youknowriad requested review from ajitbohra, chrisvanpatten, gziolo, jorgefilipecosta, noisysocks and talldan as code owners May 16, 2019 09:32

sarahmonster added 4 commits May 22, 2019 13:37

On mobile screens, show full-width snackbar.

6f4a1d5

Attempt to centre snackbar notice within editing window.

266cff1

Ensure that multiple snackbars stack well.

b2b47ed

Reduce max-width for better legibility of long lines.

b0b9fa4

youknowriad commented May 22, 2019

View reviewed changes

Move positioning styles to layout file and nix unneeded styles.

fc5408c

aduth mentioned this pull request May 24, 2019

Exit Code Editor button is hidden when notices show up #11807

Closed

draganescu mentioned this pull request May 24, 2019

Make the "saved" notification disappear on edit #15132

Closed

Restore left aligned snackbars

12cde84

youknowriad merged commit 4956082 into master May 29, 2019

youknowriad deleted the try/snackbar branch May 29, 2019 12:39

youknowriad added this to the Gutenberg 5.9 milestone Jun 7, 2019

youknowriad mentioned this pull request Aug 19, 2019

Phase 2 Scope & Features #13113

Closed

22 tasks

noisysocks mentioned this pull request Jan 17, 2023

Snackbar: Reduce the time messages display by half #47199

Closed

		@@ -30,7 +30,8 @@
		@include editor-left(".edit-post-layout__content .components-editor-notices__snackbar");

Try using snackbar notices instead of prominent ones for saving/failure notices #15594

Try using snackbar notices instead of prominent ones for saving/failure notices #15594

Conversation

youknowriad commented May 13, 2019 • edited Loading

jasmussen commented May 13, 2019

nerrad left a comment • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

nerrad May 14, 2019 • edited Loading

Choose a reason for hiding this comment

aduth May 14, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

davewhitley commented May 13, 2019 • edited Loading

youknowriad commented May 14, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented May 14, 2019

sarahmonster commented May 15, 2019

youknowriad May 16, 2019 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

youknowriad commented May 16, 2019

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

sarahmonster commented May 23, 2019

youknowriad commented May 23, 2019

jasmussen commented May 23, 2019

aduth commented May 24, 2019

youknowriad commented May 29, 2019

jasmussen commented May 29, 2019

youknowriad commented May 29, 2019

mapk commented May 29, 2019

jwold commented Jun 6, 2019

QuietNoise commented Jun 13, 2019 • edited Loading

jasmussen commented Jun 13, 2019

youknowriad commented Jun 13, 2019

sarahmonster commented Jun 14, 2019

youknowriad commented May 13, 2019 •

edited

Loading

nerrad left a comment •

edited

Loading

nerrad May 14, 2019 •

edited

Loading

aduth May 14, 2019 •

edited

Loading

davewhitley commented May 13, 2019 •

edited

Loading

youknowriad May 16, 2019 •

edited

Loading

QuietNoise commented Jun 13, 2019 •

edited

Loading