Snackbar: re-position snackbar above modals #54153
Conversation
mikachan
added
[Type] Bug
# Conflicts: # packages/components/CHANGELOG.md
|
Size Change: +30 B (0%) Total Size: 1.51 MB
ℹ️ View Unchanged
|
|
I don't think that this is a good change. If a user is opening a modal, then they're expecting that content to be what's in their viewport. If the snackbar conceals content or controls (e.g. for low vision users at high magnification or small devices), then a keyboard or screen reader user has to close the modal, then dismiss the snackbar, then re-open the modal in order to gain access to that control. Snackbars shouldn't be used for notifications that are of such critical importance that a user must see them or deal with them, because they have a lot of accessibility concerns, particularly for low vision. And as low-importance notifications, they should also not be forced above the user's intended context. |
|
personaly i would rethink the position of the snackbar #47446, that is located right at the opposite side of the button that generates it, which is not UX impactfull at all ;-) (proximity concept) |
|
@joedolson, thanks for leaving such detailed feedback! I agree that it's not a great experience when a user may want to dismiss a snackbar notification, as this action closes both the snackbar and the modal.
I understand that the snackbar notifications are of low importance, however, I'm not sure it's a great experience when the user can only see a portion of the notification when it's obscured by the modal, especially in the case where a snackbar notification is shown while a modal is already opened (for example, in the new Font Library modal, shown in the video here). I'm wondering if we could introduce a modal-friendly snackbar notification that, for example, always shows at the bottom of the modal, so it's displayed within the modal itself. If a modal is open, we could also disable the current snackbar, so only one shows at a time. This issue may be specific to the new Font Library modal, so perhaps some additional design input is needed here. @jasmussen, what do you think of the current snackbar notifications that show when adding and deleting fonts in the new Font Library modal? They currently display like this:
@Marc-pi, thanks for linking that issue! I'm not sure the position of the snackbar should be changed to be closer to the 'save' button, as other actions in the editor also trigger snackbar notifications, so changing the position wouldn't always guarantee that it would be closer to the action that triggered it. Also, in the case of large modals that take up the majority of the screen, the snackbar would still be behind the modal. |
Adding to this thought, Instead of embedding a snackbar into the modal, may be a modal can have its own messaging system with props and as you said a dedicated area in the footer (bottom left) section to show success or error messages. |
Yes, this is exactly what I was thinking! |
@joedolson do you think this is a general problem in the current notification system in the editor, or do you detect this only on the changes introduced in this particular PR? |
|
One of the concerns I also had as a keyboard user was not being able to dismiss the notification since focus is trapped in Is there a way I can test this in the post editor? No site editor, please. Thanks. |
Based on the instructions to test above, the scenario being tested is when an action spawns a snackbar and then a modal is opened. In that scenario, the snackbar should remain below the modal. If the snackbar is spawned after the modal is opened, then that's a different situation. The ordering of layers should match the ordering of events: if a modal is opened on top of an existing snackbar, then it should not be blocked by it. And @alexstine's concern is extremely important: a user needs to be able to dismiss a visible notification without needing to first dismiss their current context. |
Yes I agree, I think this may be the biggest blocker to re-positioning the snackbar to being above the modal. From testing it just now, I believe focus is trapped in the modal, so you're unable to interact with the snackbar with the modal open.
I think this is also true 😞 Apologies, I should've tested this more thoroughly before suggesting it as a solution.
You can open the Preferences modal from the post editor, but I'm not sure of a setting that triggers the snackbar in the post editor. You need a combination of a snackbar notification being open whilst a modal is open, and I'm not sure this is as easily triggered in the post editor. For more context on why this combination is important, it's because this issue was raised whilst working on the Font Library front end PR, which introduces a modal to manage font files. Adding and removing fonts currently triggers a snackbar notification whilst the Font Library modal is open, but the snackbar is underneath the modal, and can be difficult to read depending on the screen size. Thanks @alexstine, I think your above comments alone are enough for us to discuss an alternative solution. 🙇 I'm not sure of any other settings in either editor that trigger a snackbar notification whilst a modal is open, so this may be specific to the Font Libary work. What are good alternatives to using the snackbar for update notifications in this case? Here are a couple I can think of:
|
|
Second option sounds good to me personally. 👍 |
|
Good PR, I will defer to the experts already in the thread, and only respond to this:
The font library should not use a snackbar at all, as I also suggested in this comment. The upload flow as it works at the moment is a bit flawed, and diverges quite a bit from how you upload images. The models there should be identical so uploading always follows the same model. In the comment I go into more depth, but essentially uploading should be either:
This is visualized in the mockups in #45271 and it is quite important that those mockups are followed, the current PR diverges in a few places. |
OK, we can remove them.
It's currently working like this. The last time you tested the PR, it was different. Please try the latest version. Apart from that, @jasmussen, please provide an alternative to display error messages when the user actions fail (for example: WordPress doesn't have write permissions on the server). |
How's this? 
That's the regular Notice component. I think the question around the snackbar for this error is valid enough, as is the PR here. Important just to not let this block the fonts library, if the notice can help that to happen. |
|
Thanks for your detailed feedback here, @jasmussen. I didn't realise the Snackbar shouldn't be used; I think that means we should close this PR and the related issue at #52609. |
What?
The snackbar notifications currently show underneath the modals, which becomes more of an issue when the modal takes up a large percentage of the screen (e.g. at smaller resolutions, or where large modals are used). This PR adjusts the position and z-index of the snackbar component to allow it to display over the top of the modal.
Why?
Closes #52609.
How?
This PR wraps the
SnackbarListcomponent increatePortal, in order to attach it to the body. This is similar to how theModalcomponent works. This means the z-index can then be changed to allow the snackbar notifications to display over the top of the modal. The positioning of the snackbar has also been slightly adjusted as its position is now relative to the body element.Testing Instructions
The easiest way to test this is to test on a smaller viewport:
Screenshots or screencast