[Notification] Waiting for editor#change before closing notification is weird

[Piotrek Koszuliński]

Currently notification is closed 5s after the first editor#change event. The idea was that the user should see it and we know that the user saw it if he changed something. But since the notification is well visible the user will know in 90% other cases too so I don't feel this is necessary. I would close it 5s (or even shorter) without waiting for editor#change. Alternatively, we need to improve this mechanism and e.g. listen on all keys and mouse movements.

[Piotr Jasiun]

Notification wait for the change event because of such scenario:

• user upload/download big file,
• do not want to wait, go to make some coffee,
• progress is done, notification change its type to success and close after 5 seconds,
• user come back and is confused because he/she see no information about the result.

It case of operation which takes time user may not track the browser window whole time, this is why notification wait for the change event. I agree that we could listen also on scroll and mouse events, but I think that it is more important not to close notification too soon than close it quickly.

[Jakub Ś]

From what I know there is possibility to close notification with Esc, there is X button and notification disappears after 5 sec after change event was fired.

If there is anything missing here (and I repeat IF) then perhaps, this fade time could be made configurable and as PJ has said - some additional listener like scroll or mouse click could be added.

[Piotrek Koszuliński]

do not want to wait, go to make some coffee,

And when he gets back the file is either uploaded successfully and the user sees it in the editor or we display the error notification which by default the user must close manually.

I simply find them a little bit too intrusive. The success notifications don't have to be this visible in my opinion. It depends on a case, but in case of files upload you have other indications that the file was successfully uploaded.

[Piotr Jasiun]

And are you sure that all success processes will be easy to check that they are done without error? We do not know what notifications will be used for and I can image processes which are not that simple to check. Also user may not know that if he do not see warning it means that everything is done (I have seen many times processes which close without warning in case of error).

Good example is a browser. If you download a file (even if it is small file) you need to close the download dialog/panel manually.

[Olek Nowodziński]

1. We should not use change event to interact with notifications. Because change can be triggered externally, from 3rd-party code messing with editor contents, without user interaction. This is the road to hell. Also see 5.
2. Notifications must disappear automatically.
   1. I.e. to avoid "notification avalanche", which would cover the entire editor, if some "notificatiogenic" action is repeated.
   2. But with a long timeout, to give users a chance to read it. Send a message in Gmail to see how it works. It's more like 30s than 5s. Keep it 15, and it'll be just fine.
   3. The only reason to close the notification before timeout is opening a dialog, because dialog is a separate, independent view (just like switching folders in Gmail once the message has been sent).
   4. It applies to errors as well because of 2.a.
3. There must be a possibility to close each notification. And, AFAIR, there is.
4. Closing notifications on window scroll makes no sense because of 1. CKE scrolls randomly sometimes. Also see 5.
5. Closing notifications on click/focus/keypress/scroll is wrong because users may want to finish some tasks first, before reading the notification which has appeared in the meantime.
6. If some people have a strong urge to get some caffeine, that's not our problem, or, at least, not a problem of current implementation. Usually, i.e. in OSs, unread notifications are expressed as a notification counter. No longer a notification but an indicator. As long as CKE's notification system is simple, we don't support it. KISS.

[Piotrek Koszuliński]

Good example is a browser. If you download a file (even if it is small file) you need to close the download dialog/panel manually.

It's not a good example. In the browser the downloaded files panel gives you some additional options like opening this file, deleting it, opening enclosing folder, etc. This is a crucial step after downloading - you want to do something with the file. Our success notifications don't have the same role.

[Piotrek Koszuliński]

BTW. To give a context - we're only talking about file uploads, but what are the other use cases for 'success' or 'info' notifications.

• an autosave plugin could display a success message when the content has been saved (note the irony that to make it automatically disappear you have to change the just saved content... and trigger another auto save :D),
• the clipboard plugin may display an 'info' notification when the 'copy' button has been clicked in the toolbar (that you don't have access to the clipboard).

In the first case it is very apparent to me that the notification should disappear pretty quickly and automatically. In the second case I would like it to stay longer, so user can read what the message is, but it can also disappear automatically, because user sees it immediately after his/her action.

My point is that it's clear that the notification duration should be configurable, and it is configurable per notification and globally. However, making notifications waiting for editor#change is an overcomplication which may lead to odd behaviours. Polishing the "wait for action" feature will unnecessarily complicate the code and I'm strongly against that.

[Piotr Jasiun]

Replying to Reinmar:

Good example is a browser. If you download a file (even if it is small file) you need to close the download dialog/panel manually.

It's not a good example. In the browser the downloaded files panel gives you some additional options like opening this file, deleting it, opening enclosing folder, etc. This is a crucial step after downloading - you want to do something with the file. Our success notifications don't have the same role.

Not necessarily. Notification may contain link, e.g. "Learn more."

[Piotr Jasiun]

Replying to Reinmar:

• an autosave plugin could display a success message when the content has been saved (note the irony that to make it automatically disappear you have to change the just saved content... and trigger another auto save :D),\

Agreed that autosave notification should hide quickly. This should be configurable.

[Frederico Caldeira Knabben]

IMHO we're over-bloating the notification thing with features. I'm for starting simple and enhance during time. We should favor, especially in the first state, less code and solutions that satisfy the common case, keeping them still acceptable for the edge cases.

As for this feature, IMHO we should simply hide the notification after a fixed amount of time, period. No configs and no super power... ok, a config just for this is not a big deal.

This approach would solve well the common case, where the user is doing something in the editor and waiting for it to finish.

Then in the future we may feel the importance of waiting for something to trigger the autohide (maybe a browser/OS event). Still the change event doesn't sound like a good option and right now there is no time to research further on this.

[Wim Leers]

IMHO we're over-bloating the notification thing with features. I'm for starting simple and enhance during time.

+1

In Drupal, we show notifications (we call them "messages" — see ​https://api.drupal.org/api/drupal/includes%21bootstrap.inc/function/drupal_set_message/7) statically, for the entire duration of the page load. There are contributed modules that hide them after a while. But that's the default in Drupal core, and it's been like that for… at least 10 years (that very function was introduced in version 4.6, which was released in 2005: ​https://www.drupal.org/drupal-4.6.0). That really is the simplest (read: most braindead :P) solution possible.

I'd also say no notifications are necessary at all for things whose completion is inherently clear. E.g. an image upload. If the image is visible in the editor, it's clear that it's been uploaded. (I'm oversimplifying here, but you hopefully see what I mean: the very presence of the image *is* a notification* of sorts.)

I don't know how exactly this is implemented, but I'd recommend:

• the "stacking behavior" in OS X; it feels very natural and non-disturbing. It shows at most 3 notifications simultaneously. As soon as you dismiss a notification (or as soon as it disappears automatically), the next one in the stack falls down.
• the notion of a "sticky notification" versus an "ephemeral notification" (also from OS X; my names, I don't know the official terms). Some notifications must be manually dismissed (sticky). Some disappear after a certain amount of time (ephemeral). Either type can *always* be dismissed manually. And they optionally offer the ability to perform an (inline) action.
  (The best example, the one that I see most often, and that I never found annoying: the Messages app's notifications. It offers a "Reply" button that allows me to reply *within* the notification. I can dismiss it. And if I don't take either of those actions (reply/dismiss), it'll disappear after a few seconds.)

[Piotr Jasiun]

Replying to Wim Leers:

I'd also say no notifications are necessary at all for things whose completion is inherently clear. E.g. an image upload. If the image is visible in the editor, it's clear that it's been uploaded.

It is not exactly true, because images is visible as soon as upload starts. We put base64 encoded data as a source, but this placholder image will be removed if user close the editor before upload is done, so we need to show him the status.

I think that, to make it simple, warnings should need manual close and all other notifications close automatically after timeout.

[Wim Leers]

Replying to pjasiun:

It is not exactly true, because images is visible as soon as upload starts. We put base64 encoded data as a source, but this placholder image will be removed if user close the editor before upload is done, so we need to show him the status.

I knew you were going to say that, which is why I also said this:

(I'm oversimplifying here, but you hopefully see what I mean: the very presence of the image *is* a notification* of sorts.)

---

I think that, to make it simple, warnings should need manual close and all other notifications close automatically after timeout.

That sounds reasonable. But there are going to be gray areas, where it may depend on the user's intent whether a notification should be manually closed or automatically disappear.

[Piotr Jasiun]

I mean we are talking here about waiting for editor#change event and the default behavior. Beside that notifications have optional timeout parameter so the default behavior may be changed per notification (for example if notification contains a long text or a link).

[Piotr Jasiun]

Changes done (​t/12866).

[Piotrek Koszuliński]

Fixed on major with ​git:969ec74. Notifications no longer wait for the editor#change event.