Toast notification alert message pop up

[shanaka-rajitha]

Features

• Toast message should include prefix icon, text, button and close icon.
• Toast message should be able to show background color state variations based on scenario (green, red, yellow, blue).
• Toast message should have a time out.

Design URL for specs : https://xd.adobe.com/view/809c4f44-9861-4f57-978a-e2d3515a426e-d5cf/screen/63ee7e10-a6aa-48a7-b9d9-fb78539eaf77/

Toast notification pop up (success state)

[mturoci]

@shanaka-rajitha We support native browser notifications which are superior to custom UI notifications since they show up even if user has not the tab / browser focused. Is there any hidden benefit in implementing these that I don't see maybe?

[shanaka-rajitha]

Hi @mturoci the browser native notifications are good but it does not visually present the status of a message at glance. The proposed alert notifications provide contextual feedback for typical user actions. Something similar to how Bootstrap use the alert component.

[mturoci]

The example provided in description is not the best UX for the outlined scenario. If the model creation is immediate, then user should be taken directly to the project / models page where the new model can be viewed which implies a successful operation. However, if the model creation takes longer the user is very likely to switch tab (since it is better than mindlessly stare at the app, just for the sake of waiting) which may result in missing the in-app notification, thus not getting the info about created the model. In this case native notification is superior as it can be seen even when the tab with the app is not focused currently. Either way, in-app notification is not a good fit.

However, I agree there might be some usecases when in-app notification can be useful. Confirming settings were changed for example. The only thing that worries me is that this can be easily misunderstood / misused resulting in not that great UX of the apps.

@lo5 proposed API for review:

/**
 * Snackbars are temporary in-app low importance notifications that inform user about
 * a particular app state change and disappear on their own.
 * Make sure you don't overuse them too much so as not to downgrade the UX of your app.
 */
interface Snackbar {
  /** Snackbar's text. */
  label: S
  /** Snackbar's type based on scenario. Defaults to 'info'. */
  type?: 'success' | 'info' | 'warning' | 'error'
  /** If specified, renders a button next to the snackbar label. */
  button?: Button
  /** When should the snackbar disappear in 'ms'. Defaults to '5000'. */
  timeout?: U
  /** Specify where should the snackbar be. Defaults to 'top-right'. */
  position?: 'top-right' | 'bottom-right' | 'bottom-center' | 'bottom-left' | 'top-left' | 'top-center'
  /** The events to capture on this snackbar. */
  events?: S[]
}

[shanaka-rajitha]

Hi @mturoci, there is no issue as to what type of notification component is used. What is raised as a concern here is if browser native notifications can visually represent the information with a theme that implies the context of the message shown.

By allowing the notification UI to be app-specific, provides a seamless experience to the user. To provide better UX we do not show all states of warning, information, alert, and success states in the same themeing. Hence why it is more important to show the notifications more visually related to the context than the type of notification used.

[mturoci]

What is raised as a concern here is if browser native notifications can visually represent the information with a theme that implies the context of the message shown.

I understand, what you are saying, but if the user doesn't see notification at all, there is no UX at all thus colors / theming is less important since it is just a cosmetic detail. It doesn't matter what color is the notification of if the user will not see it, right? I propose to give a deeper thought on general UX (how the user will actually use the feature) and less on UI (what colors he will (or will not) see).

[shanaka-rajitha]

Including @mtanco @iamabhishekmathur

[iamabhishekmathur]

@mturoci @shanaka-rajitha

I don't think it has to be one or the other. There are clear use cases for both, app native notification vs. browser native notification.
While I agree that for instant reaction, user should be redirected to the new page, there's also value in having a "Model has successfully been uploaded." message come from an app native notification.

In general, more sophisticated apps tend to use more of app native notifications, while newer/less evolved apps tend to use browser native notifications.

Since browser notifications can be a temporary solution that can be used, I would decrease the priority of this ticket (app native notifications).

@ShehanIshanka @sandruparo please use browser notifications for v1 of mlops app. let's not be blocked by this ticket.

cc: @mtanco

[lo5]

@mturoci - Re: API

• Snackbar: Why not call this a Notification?
• label: Rename to text, consistent with MessageBar.
• type: Make consistent with MessageBar.type
• timeout: Change units to seconds.
• Not clear from the API design: How do I specify a label for the button if the notification contains a button?
• If the notification displays a button, does it timeout?
• button/events: If the intention is to allow handling button clicks, then better to have a name instead of a button like we do with other components. Remove events unless we anticipate this component raising other events.

[mturoci]

Snackbar: Why not call this a Notification?

We already have a meta_card.notification. Although it is a string, the attr name is notification so we need to distinguish between native vs in-app notifications somehow.

label: Rename to text, consistent with MessageBar.

Sure

type: Make consistent with MessageBar.type

Sure, @shanaka-rajitha can you additionally design notifications for danger and blocked types please?

timeout: Change units to seconds.

Sure

Not clear from the API design: How do I specify a label for the button if the notification contains a button?

The initial intention was to use existing Button API which contains label. Other alternative would be to split this into 2 new attrs - name and label_button.

If the notification displays a button, does it timeout?

I would think yes if the routing achievable via button is considered optional, otherwise should be redirected right away after the action that triggered the notification and the notification will be used for decorative purposes without button. Wdyt @shanaka-rajitha ?

button/events: If the intention is to allow handling button clicks, then better to have a name instead of a button like we do with other components. Remove events unless we anticipate this component raising other events.

The reason I didn't propose a simple name was that I couldn't come up with any clean way of specifying button label.

The events attr is there to support dismissed event, similar to dialog and side panel. Can be removed if not needed though.

[shanaka-rajitha]

Sure, @shanaka-rajitha can you additionally design notifications for danger and blocked types please?

Hi, @mturoci I have updated the rest of the designs for all other color variations, icons used are picked from Fluent icons.

Design URL: https://xd.adobe.com/view/0790f950-abbd-41fa-b372-332295fd876f-52c3/screen/8e728e9a-cab7-42cd-8dc4-061a3ca65235/

[shihan007]

@mturoci So we have updated new toast layout as you can see and here if we are including an action button it better not to keep the toast as auto timeout. For the normal toast messages (ex:- project uploaded, saved successfully) we can have auto timeout.

cc: @shanaka-rajitha

[mturoci]

@shihan007 got it, thanks

[lo5]

We already have a meta_card.notification. Although it is a string, the attr name is notification so we need to distinguish between native vs in-app notifications somehow.

Let's name this notification_bar, consistent with message_bar.

The initial intention was to use existing Button API which contains label. Other alternative would be to split this into 2 new attrs - name and label_button

What about adding a buttons: Component[] so that ..., buttons=[ui.button(...), ui.button(...), ...] can be rendered as 1/more buttons. The button's caption, primary, link, icon, etc. properties can be ignored.

For consistency, would be good to also add buttons to the current MessageBar component as well (mapped to Fluent's actions and MessageBarButton).

[mturoci]

Sounds good @lo5, I would just replace buttons: Component[] with buttons: Button[] to prevent people from rendering other form components, not just buttons.

[lo5]

I would just replace buttons: Component[] with buttons: Button[]

This will run into issues with the Python driver. ui.button() returns the union type Component.

[mturoci]

Oh I see, thought it will only need a bit of frontend tweaks. Will explicitly point out that only buttons are supported unless there is a better solution, e.g. introducing ui.notification_bar_button.

Another question: Do we also want to support loading as described in the designs? If so, one option could be renaming buttons to items and leverage the generic nature of form components - let user pick which components and order they are rendered in. This flexibility can also cause a lot of trouble though.

@shanaka-rajitha @shihan007 where can I find the designs for danger and blocked types? Cannot find them within
https://xd.adobe.com/view/0790f950-abbd-41fa-b372-332295fd876f-52c3/screen/8e728e9a-cab7-42cd-8dc4-061a3ca65235/

Also what is the usecase for the default notification in designs? I thought the notification should always carry a message and sentiment (success / error). So far, I went with info as default.

Warning and error notifications use the same icon which is odd. Let's go with StatusErrorFull icon for error instead.

[mturoci]

Progress so far:

Screen.Recording.2021-09-28.at.12.43.39.PM.mov

• styled buttons according to design if link=True specified
• handled mobile viewport - only 2 positions available - top / bottom
• auto close after 5s when no buttons included with optional manual close
• if buttons present, manual close is required

[shihan007]

@mturoci this looks great

[sandruparo]

looks great @mturoci

[sandruparo]

@dulajra @VijithaEkanayake These components are already built in the sdk and they will probably merge this soon. and will let you know once its done.

[dulajra]

@mturoci When can we get this ready in the Wave SDK? Can we use this toast as a floating component and form component as well?

cc: @iamabhishekmathur

[mturoci]

When can we get this ready in the Wave SDK?

Probably by the end of January.

Can we use this toast as a floating component and form component as well?

Toasts are floating components in general. For form, you can use existing ui.message_bar.