Create proper notification system and area - Toast Notifications

[ellisonbg]

Right now, there are lots of UI actions in JupyterLab that do something, but have no visual indication. An example is saving or renaming a notebook - the user gets no visual feedback those actions have completed or failed.

The existing notebook has a small area in the toolbar that provides notifications. We should:

• Create a notification API, plugin an UI for JupyterLab.
• Investigate other software that offers such functionality to properly design this.

[jasongrout]

Probably 1.0, not 0.9. People can work without it, but definitely needed for 1.0. What do you think?

[ellisonbg]

Sure, 1.0 is fine, retargeting...

[eskirk]

@ellisonbg how do you like this? Nice and non intrusive, multiple notifications can get stacked and you could easily dismiss/interact with them.

[jasongrout]

I think it looks nice.

[ellisonbg]

Questions:

• Where to show notifications in the UI (let's start with a floating design, L/R bottom corner)?
• How notifications stack up if there are multiple ones active at a time?
• What is the content of notifications?
  • Let's have a base notification type that allows any content.
  • Then specific templates for basic things like warnings, errors, info, etc.

@eskirk how is the code/plugin side of things?

[mattb-co]

After doing some research about Google's MD notification strategies (they call them Snackbars & Toasts), I figured I'd mock up a few iterations of what global JupyterLab notifications could look like.

The notifications would appear in the bottom-left corner of the parent container (whether that is the panel or the whole window, which can be discussed later), which avoids distractions from the main left sidebar and the top toolbar.

I created a light and dark version, both of which would stack on each other and could have the potential for a single action. I also created an instance of the dark version that we could use if there are multiple notifications asking for attention.

The dark version is actually a #333333 grey with 90% opacity, to be able to work on a white and a black background (depending on what panel it's over). The white is a solid white #FFFFFF with a drop shadow (I think it would have this property in CSS: box-shadow: 0px 2px 4px rgba(0,0,0,0.15);)

Dark version on white:

Dark version on black:

White version on white:

White version on black:

Multiple notifications:

Let me know your thoughts!

[ellisonbg]

@matt-bowers great!

• I think we need a notification system that can handle many different usage cases. I like this style of notification UI in situations like that.
• We will have to think more about how we want to handle the UI for multiple notifications arriving. My thought is that they would just stack up...
• Probably want all notifications to have a dismiss "x" icon

Questions:

• Most notification UIs I know of use a fixed width for content. Does that make sense here?
• Could you think a bit more about the different types of notifications content we may need (errors, warnings, info, actions) and what the UI for those would look like.

[ellisonbg]

@eskirk are you back and working on this?

[eskirk]

@ellisonbg yeah sorry, it took an extra day to get back but I am looking at this right now, I'll see what kind of progress I can make on this today.

[eskirk]

@ellisonbg so here is how I am imagining taking care of this:

• A notification widget is instantiated when the application is launched, this widget is accessible by all widgets in the program via reference
• Any time an action/function that needs a notification is executed, a function is called in the notification widget and it get's passed certain parameters such as the content of the notification, etc.
• These notifications are appended to a top level dom element, possibly the same element as where the dialog notifications appear? But just in the bottom right
• After x seconds, the notification disappears.

How's that sound?

[eskirk]

@ellisonbg now that I am back from break I really want to try and tackle this feature. When you get the chance we should meet up so I can ask a couple lingering questions and whatnot :^)

[fcollonval]

@ellisonbg
I prototyped a notification system based on react-toastify.

Basically, it adds a container for notifications in the DOM. Then notifications can be sent to it from any place in the code through simplified function:

import { INotification } from 'jupyterlab_toastify';

// Error message notification - do not close automatically
INotification.error('Error');
// Warning message notification - do not close automatically
INotification.warning('Warning');
// Info message notification
INotification.info('Info');
// Success message notification
INotification.success('Success');

// Background task with progression animation
let id = INotification.inProgress('Task in progress!');
// -> Update text
INotification.update(id, 'Updating task...');
// -> Update text, status and set closing delay (in ms)
INotification.update(id, 'Task succeed', 'success', 3000);

// Default call using `toast` function
// This is the only helper function taking two arguments: content and options.
// See https://github.com/fkhadra/react-toastify#usage
INotification.notify('Default');

The tuning made to react-toastify:

• Theming using JLab CSS variables (including close button as notebook tab close button)
• Forced parameters:
  • Position bottom-right
  • Newest notifications on top
  • No time elapsing progress bar
  • Transition with Slide effect
  • Not draggable
• Simplified functions for 5 usages:
  • In progress task
  • Success
  • Info
  • Warning
  • Error

Advanced configuration can still be achieved using react-toastify API.

Link to the repository: https://github.com/fcollonval/jupyterlab_toastify
To install

jupyter labextension jupyterlab_notify

Nota: nothing pops up when loading the extensions. Better to install it in dev mode and uncomment the examples in the activate plugin function.

[fcollonval]

[echarles]

@fcollonval this looks great: Now the question is "should this feature be part of juptyerlab core code base?" (cc/ @ellisonbg).

About phosphor/reactjs integration/communication/skin, see also #4234

[ellisonbg]

We have built a new statusbar extension this summer:

https://github.com/jupyterlab/jupyterlab-statusbar

It has a center area for transient information and initial implementations for things like file saving, uploading etc. The status bar can have items that have hover or click based additional information. My inclination at this point would be for us to try to use that and see how it goes, rather that something more invasive notification approaches. Thoughts?

[echarles]

This issue is about notification which can be implemented with a toast or a statusbar. Use case for both those implementations are different, IMHO we need both.

[fcollonval]

My experience on editor UX is mainly with VS Code and PyCharm.

VS Code has both. The status bar reports mainly status of file and some background tasks running (for instance when pushing new file to git repository). The notifications are there mainly for background tasks to request actions (missing linter package or Python environment) or report errors and warning. Error and warning messages must be closed by user action on clicking explicitly on the close button.

PyCharm has a status bar with some pop up. The status bar reports status and all running background tasks (like indexing file). When a background tasks is done (with success or not) a small pop-up is shown to alert the user (usual cases are Git commands interacting with the remote). If something went wrong, I end up a couple of time missing the error messages and its link to log information as the pop-ups disappear without user explicit actions.

So as @echarles suggested, I think both are needed. And the current notification prototype should be extended to allow developers to add buttons and/or links to further information or to start follow-up actions. I pick-up react-toastify also for that purpose as React component can be rendered inside the toast. And it would be nice if a simple API like the one for showDialog could be provided to easily specify buttons/actions. But this will need discussion regarding the best API to do so.

[jasongrout]

If we have a toast notification system, should the statusbar be used to display things like saving, uploading, etc?

I think so. I think toasts should be about things that require user attention/action. I think uploading/saving are progress messages about things the user has already acted on, and are great for a status bar.

[fcollonval]

I'm very interested in working on this.

@gnestor I will have time next week to look at this. May I help you?

[gnestor]

@fcollonval Absolutely! I will reach out to you on Gitter and we can set up a time to chat.

[kwlzn]

+1, a proper notification/growl-like messaging system in jupyterlab would be great. particularly if there was a Python and CLI API to this!

being able to run e.g.

$ <some long running command> | notify "Completed command"

in an in-lab terminal would be huge.

[tgeorgeux]

I've drawn up some toast components along with some rules we can use in how we utilize toast that we can follow strictly within JupyterLab core, and suggest to the wider extension-building community. Material Design calls these "snackbars" but I think we've normalized the use of the term "toast" and we should stick with it going forward (plus the idea of toast popping out of the toaster is a fun match between the system and the real world).

First off, we should start with off with a simple design, that's flexible enough to serve varied needs. Some goals for this design:

• Toast remains non-disruptive to the user's workflow.
• Toast gives updates about asynchronous activities that are going on in the background.
• Toast can be a gentle way to give users a way to recover from a mistake
  • It's desirable to use a toast recovery option in lieu of a confirmation dialogue.
• Toast alerts should not block commonly used work areas.
• Toast should exist in the user's periphery, focus on them should be optional.

[jasongrout]

Also, there should be a way to have levels of information in a toast, like with a summary/detail view, or for a link to open relevant panels in the UX (for example, a log console).

[tgeorgeux]

These are the toast types I'm proposing:

Right now I'm shooting for 4 options of toast a combination of 1 or two lines, and with or without buttons; then light and dark mode for each of those.
I am open to dropping the toast that don't have a button, as we can always have the 'DISMISS' command.

For placement, I've drawn up the two ideas of where they "Should" live below.

[tgeorgeux]

@jasongrout I agree, buttons should link directly to how to resolve a notification.

As for 'levels' of notification, I think we shouldn't allow any interaction with these besides dismissing or hitting the button. These are transiet elements not meant to hold you "center attention", they exist to give small peripheral nudges that may lead to a context switch. I don't think the context switch should take place in the notification itself, but the action could take you to the 'read more' activity.