[material-ui][docs] Revise the Snackbar page

[danilo-leal]

• I have followed (at least) the PR section of the contributing guide.

Was checking out the docs-feedback channel, and someone recently posted that they spent a lot of time searching how to center a snackbar. Then, I visited the page and found that there were some formatting/writing improvements that might facilitate people finding information better the next time.

My overall train of thought for this was to remove most of the "how-to-use" instructions from a UX standpoint (parting from the assumption that the Material Design docs itself are the place for that), and focus on the component's capacities. Also, tried to follow the structure we've been applying across the Base UI and Joy UI docs and simplified some of the demos!

👉 https://deploy-preview-39298--material-ui.netlify.app/material-ui/react-snackbar/

[mui-bot]

Netlify deploy preview

• docs/data/material/components/snackbars/snackbars.md

Bundle size report

No bundle size changes (Toolpad)
No bundle size changes

Generated by 🚫 dangerJS against bc1c817

[mbrookes]

Thanks for working on it!

I have only reviewed the text and not the code changes.

[samuelsycamore]

I was just starting to dig into this doc for another pass when I noticed the color contrast on these demos! 😬 I think the Introduction, Content, and Consecutive demos could use some love.

[danilo-leal]

@samuelsycamore just added the section about the autoHideDuration prop we discussed in a comment above! Mind taking a second look? I think the button's design issue there, which you mentioned is either a problem with the component itself or in the docs, as the Snackbar flips from a dark-colored background to a white one when you switch modes. 🤔

[mbrookes]

Off topic, but what's up with this?

[danilo-leal]

☝️ That's been removed/corrected in this PR! 😬

[samuelsycamore]

I'm pretty sure this is the cleanest component demo page that exists in the Material UI docs now! 🥳 Left one final comment to think about, but shouldn't be a blocker for this PR.

[danilo-leal]

@mbrookes can you double-check this one when possible? Feels like it's ready to go! :)

[mbrookes]

Minor tweaks.

[mbrookes]

In the Transitions demo, if you don't close an open Snackbar first, then when clicking a different button the transition doesn't render correctly. Since it might overcomplicate the demo to fix this, should we add a note to the text to explain that this? Or would adding a short autoHide duration be enough?

[mbrookes]

Regarding the change of case from snackbar to Snackbar, the original intention across the docs was to distinguish between, for example, a button in the general sense (lower case) and an instance of a Material UI Button component (capitalized).

I suspect that distinction has long been lost, and it was sometimes ambiguous anyway, so the only case I would argue for it on this page is "Material Design recommends positioning Snackbars" - it doesn't recommend positioning React Snackbar components specifically. It's not a hill I'll die on if anyone disagrees.

[mbrookes]

I've submitted an approving review because for some reason merging was blocked even though there was already one approving review which is all the repo rules require...

[mbrookes]

One last comment - the Consecutive Snackbars demo immediately dismisses the open Snackbar the moment another one is added, whereas it feels like it should queue them.

[danilo-leal]

@DiegoAndai tried pulling off Matt's suggestion for the consecutive Snackbar demo myself, but just couldn't make two instances appear consecutively with the click on one button only — when possible, can you help out with that one? :)

[danilo-leal]

I'll merge this one in its current state so we get the overall improvements we've added here, and then any additional changes can come in further PRs iteratively — including the one mentioned above (i.e., consecutive snackbars demo). 😃

[DiegoAndai]

couldn't make two instances appear consecutively with the click on one button only — when possible, can you help out with that one? :)

Hey @danilo-leal! So, if I understood correctly, the idea is to queue the snackbars instead of immediately showing them? It seems to me that it may be confusing, like the snackbars are "lagging." I think the timing of snackbars is up to the user's app workflow rather than on our side. The demo seems straightforward to show the transition, so users can take it and integrate it with their app's logic.

What do you think?

CC: @mbrookes

[mbrookes]

I know this is merged already, but I had an unsubmitted comment:

Sam previously mentioned the contrast ratio of the Content demo. It wasn't always that bad, but was never great. Here's v4:

Any chance you could fix that before we wrap this up?

One for a follow-up...

[mbrookes]

I think the timing of snackbars is up to the user's app workflow rather than on our side.

Which is what our demos demonstrate - code for using the components (with sensible UX and accessibility). Sorry if I'm stating the obvious here, or missing your point, but you seem to be arguing for the opposite.

[DiegoAndai]

Which is what our demos demonstrate - code for using the components (with sensible UX and accessibility). Sorry if I'm stating the obvious here, or missing your point, but you seem to be arguing for the opposite.

I argue that the Consecutive Snackbars demo aims to show how to transition between consecutive snackbars without stacking. For this reason, showing that transition right away is better, as that's the main point of the demo.

Queueing seems to be a separate use case. Sure, you can use both, but keeping the demos "atomic" would be better for users. It's easier to merge two demos than to pick one apart for what you need.

[mbrookes]

I just reread your original comment in that context, and I take your point. And having played with queuing I see what you mean about feeling laggy, as nothing appears to happen when you click the button. Let's leave it as is.