Material-components-web: Add indefinite snackbar duration

[reccanti]

Feature Request

Currently, snackbars time out after a set period of time, which fits with the _transient_ principle in the material design guidelines. The android spec, however, allows the user to display a snackbar for an indefinite amount of time.

I think this feature could be useful to have in the web components. It could still be transient by default, but the user could optionally specify an indefinite length of time. It could be a separate property like:

const snackbar_options = {
    indefinite: true
}

or another value for timeout, like:

const snackbar_options = {
    timeout: null
}

[sgomes]

Thanks, @reccanti!

MDC-Android does seem to have the indefinite option, whereas MDC-Web doesn't. MDC-iOS doesn't either, and in fact enforces a maximum duration of 10 seconds.

It sounds like this needs some consistency; we should reach out to the snackbar designers and get some guidance.

Marking this issue as needing design guidance.

[Garbee]

I'm wondering what the use-case is for a non-transient snackbar? The idea is that these messages are quick assertions that a task has been done for example. If something should be shown until dismissed, it feels like that is something that should be handled in a different way for the best user experience. Like injecting an alert into the page somewhere to inform the user of what you need to.

We still need some guidance since Android is certainly allowing something the spec doesn't say should be done. However good use-cases improve the discussion on whether to introduce changes to the specifications.

Thank you.

[reccanti]

Hi @Garbee,

In a scenario I've been dealing with, I was thinking about using a snackbar to display a maintenance notification to the user. It would pop up if the web app was going to be down for some reason and would have an action that would open a dialog displaying information about the maintenance period and the reasons for it. Since there may be important information in there, I don't want it to just time out without the user having a chance to view it.

I think that an indefinite duration may be useful in the context of snackbars with actions, especially if there isn't a way to easily reproduce them on the page.

Hope this helps!

[traviskaufman]

Hey @reccanti,

I'm unsure as to why Android allows for an infinite duration on a snackbar.

Regardless, in this case we feel that it's best to stick to the spec, which states the following:

Snackbars automatically time out from the screen. For usability reasons, snackbars should not contain the only way to access a core use case.

I understand the initial inclination to use a snackbar for the use-case you've outlined. I've personally seen a lot of applications reach for snackbars as if they were similar to a "persistent alert". However, snackbars are intended to be for transient notifications to a user. For example, "message sent" or "account updated".

For your use-case, I'd take a look at the App Error patterns section in the spec (although I understand that your use-case isn't necessarily an app error, but it's similar in nature), which uses a more modal UX, such as displaying an alert or a dialog.

Finally, if you'd really like to use a snackbar in a persistent manner, you could always mark up an element using a Snackbar structure, and then override some of it's styles, e.g. http://codepen.io/traviskaufman/pen/oBbZjx

[jwgwarren]

This outcome is just irritating.

[dapp]

@jwgwarren I agree, but maybe for different reasons. There should be a difference between the Material Design _guideline_ and the actual library. It shouldn't be the library's job to enforce the design, that should be up to me, regardless of what the original designers think. And I also disagree wholeheartedly with @Garbee about the fact that there even _is_ a "the best user experience." The best user experience for my users is an agreement between me, and them.

Luckily, you can just fork this and change it.

However, it is irritating

[abhiomkar]

Re-opening to revisit this. PR Welcome!

[Garbee]

@dapp

It shouldn't be the library's job to enforce the design

This actually is the point of what Material Components for Web was built for. To provide a reference implementation of the specification. Which would help in an active and productive feedback loop between designers and implementors to make sure what they specified was possible across platforms.

As far as how things are now, I don't know. But when we took MDL and decided to go to v2 (which became this) the entire point was reference implementation.

[dapp]

@garbee to me it seems weird for a components library to enforce a design guideline, and I thought the material components library's whole.point was to provide a common set of components to accelerate development. To me, the choice of which design paradigms to enforce is really about whether you just want people to use it, or whether you insist that they use it in a specific way. To me, open source library maintenance is a balance of those two things for the developers, but if you think this issue is important enough to take a hard stance on, I'll just fork it.

[montoyaaguirre]

This feature has been implemented. If you're using angular material and you want to open a snackbar that will stay on screen until the next one is displayed, you can use:
snackbar.open("Message", "Action", {duration: undefined});