Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Revise the Introduction of the Snackbar Component #16391
On June 28th, 2019, during the weekly accessibility meeting on Slack (see https://wordpress.slack.com/archives/C02RP4X03/p1561735811067700), potential accessibility issues were pointed out regarding the introduction of the Snackbar component in Gutenberg 5.9. During the discussion about these issues, a much wider range of problem areas were highlighted and some members proposed to revise whether the Snackbar component should be kept inside the editor interface or if it should be removed.
Concerns about Snackbars apply both to their current use (at the moment, they're used to display a message after a post is saved/updated) and to their future use in other parts of the editor. Following is a list of potential issues concerning both accessibility and UI/UX that were pointed out during the meeting.
During the accessibility meeting, it was decided that the first issue to be addressed is whether the Snackbar component is valuable and, as such, should be kept in future versions of the Gutenberg plugin and finally merged into the core. After reaching consensus about keeping the component in the editor, another GitHub issue will focus on how to improve accessibility for the Snackbar component.
In order to keep the discussion here focussed, let’s start by evaluating the use case for the Snackbar component. The identified accessibility and UX issues are ones we can fix. Before we address the specifics, let’s focus on the key question:
Does WordPress need a hierarchy of notifications?
WordPress, by virtue of its extensibility, can often overwhelm users with notifications:
Establishing a hierarchy of notifications can help reduce this mental fatigue and allow users to approach their work in a more focussed way.
By introducing a lower-priority form of notification, we’re able to have more control over how notifications are sent in WordPress. A multiplying array of notifications that require user interaction can quickly veer into over-sharing territory, but avoiding sending notifications when processes are complete can mean that users lack certainty about those processes.
The article distinguishes between low-priority (“just FYI messages”) messages, and high-priority (“messages asking users to take action”) messages, and recommends that lower-priority messages disappear on their own.
WordPress notifications (the current Notice component) traditionally require user interaction to be dismissed. This makes sense for high-priority messages that require the user to take action, but is inappropriate for those that are simply notifying the user of a successful process (“Your upload is complete.”), or are just meant as a quick heads up (“You’ve changed your theme, but you can undo this if you need to.”).
The goal of snackbar notifications is to offer a less-obtrusive alternative for those sorts of low priority messages.
To illustrate the difference here, let’s first take a look at a great example of a traditional WordPress notification: the one that lets you know a plugin update is available. In this case, the user needs to take action, and the notification remains present until that action is completed. Once they manually upgrade their plugin, the notification will be dismissed.
On the other hand, the “Post updated” notification doesn’t necessarily require the user to take any action. Even so, it’s usually been displayed in a similar manner to the example above:
This notification is informing the user of a successful action. The message remains on the screen until the user specifically takes action to dismiss it, or triggers a new action to replace it. In this case, the message is inherently temporary though: Yes, the post was updated, but if the user continues making edits on the page, the notification becomes obsolete. Over time, the notification remains on the screen, but it becomes less useful and less accurate.
In the latest versions of Gutenberg, this message has been transitioned into a snackbar notification. The snackbar appears briefly to alert the user to the success of their button press, provides them with an optional next step, and dismisses itself automatically. This is a more appropriate treatment for this particular message: it is less intrusive, temporary, and doesn’t require the user to take any action.
Benefits of establishing a notification hierarchy
Establishing a hierarchy to Wordpress notifications allows us to do the following:
Let’s continue to iterate
The current iteration of snackbars may not be the ideal one, and Gutenberg may not be using them correctly all the time just yet. Placement, timing, usage, and visual treatment are all aspects that can definitely be iterated on.
For instance, we could introduce a user setting to control the timeout or even hide them altogether for users who find notifications distracting. Or we redefine the rules such that a lower-priority notification cannot have an associated link or control, thereby forcing developers to only use these for non-actionable system messages.
From a design perspective, these notifications are a first step toward establishing a hierarchy of notifications in the system, which serves a very real problem.
A hierarchy of notifications appears valid. To help further this discussion we should define which notifications are high-priority and which or low-priority. We can do so in this issue, and move the a11y concerns to another issue entirely for more focused actions.
I'll attempt to classify some notifications below to help move the discussion forward. This is not an exhaustive list, nor is it set in stone. I'm open to alternative suggestions.
Low-priority Notifications (snackbars)
I doubt I covered them all. @youknowriad, do you know where I might find a list of all these notifications that are being used in snackbars?