Note these are just used as examples of how intrusive the messages can be now that they are popups that you have to dismiss to be able to see what you are doing to continue. The solution is not changing the components and there messages

@dgt41 @ciar4n Can't remember, but didn't you guys add an option to auto-dismiss the alerts? If so, perhaps this should be default in core for any actions performed.

The notification system is not yet finalised, so right not is really annoying.
But the code already has an option for a timeout https://github.com/joomla/joomla-cms/blob/4.0-dev/media/system/js/core.js#L287-L300 meaning that notifications with that parameter set should automatically disappear after the given amount of time (e.g. 2-3 seconds, probably applied to successful and info messages). BTW this needs some more code for the actual notification (the custom element implementation showcased here: #14333

@brianteeman if you have some ideas here, please feel free to write them down

@C-Lodder we need the custom element here to have full client control ;)

The notification system is not yet finalised, so right not is really annoying.

not knowing that is really annoying.

we should have a page where i can see what is todo, in progress, complete etc

@brianteeman See https://github.com/joomla/joomla-cms/projects/2 in know issues part

Closed as duplicate - my bad

I've been trying to keep up with the projects boards to help track things. It'd be helpful if others with access on the repo could ensure things are added to the right board(s) as well, or making suggestions on improving those.

I will have a trawl through existing j4 issues this weekend and make sure they are all in projects and will keep an eye on new issues to add them as well

@brianteeman do you still have access to the other repo: https://github.com/joomla/40-backend-template ?

No

Automatically vanishing messages are a pain as well, especially if the message is a bit longer. It's also not nice that the conatiner is that narrow, again if you have a bit longer messages.
Messages should persist (and can be clicked away when read), but not float over other elements. The messages we have in J3 is actually well done. Just improve on that :)

yes this is just cosmetically nice but unusable
style over function

Message like "Configuration saved", "Article saved" move other elements like in J3 are also bad experience.

Show them in blue Submenu, right over Joomla-Logo.

Imho moving the other elements down is fine. I don't have an issue with that.

Messages should persist (and can be clicked away when read)

@Bakual auto disappearing toasts/alerts/dialogs call them as you like is a common pattern in all the Operating Systems, from Windows XP to IOS and Android. So I don't really see where that should is based, can you please share your thoughts on this one?

In Windows the only messages that disappear automatically are the status ones in the lower right corner. Those are the ones that appear when the system did something on its own. Or a skype mssage which came in. All stuff which isn't important if you have read it or not. because either you can find the content again (in case of Skype) or it just didn't matter (system status messages). But I don't think there are any messages elsewhere that vanish automatically after the user did an action. Especially not without a way to get them back.

My thought is that those message serve a purpose and we should make sure they are read before they vanish. It may be fine for the "Article Saved" type message, but as soon as you got a bit more information you likely want more time to read it. And I really hate it when that messages disappears before I was able to read it all.
Or imagine a collegue comes to you and ask you something while you edit an article. You think "Lets save it fast so i can talk to that guy" and immediately shift your focus away after hitting the button. When you're back from that short talk, you don't know if the article got saved or not becase the message already vanished.

not to mention that disappearing messages are an accessibility fail

It may be fine for the "Article Saved" type message

That's what I had in my mind

When you're back from that short talk, you don't know if the article got saved or not becase the message already vanished.

Well there are other patterns, more modern approaches to this problem. So even if you missed the alert there should be an indicator somewhere in that page that displays if a form has different content since the initial load or the last save (e.g. serialise form and compare to the new state). I think these are separate problems and should be addressed differently. Right now we don't care about the state client side and this is the root of all these little or bigger UX problems. We can do better and make Joomla a lot more user/human friendly...

We can do better and make Joomla a lot more user/human friendly...

As long as that is inclusive and not exclusive i am all for improvements

Well there are other patterns, more modern approaches to this problem.

That was only a simple example for a missed message. The argument applies to any message. Imho, if it doesn't matter if the user sees the message or not, then just don't show a message. Don't show it and hide it after a few seconds. And don't let some messages hide and others not. That would be confusing.

Of course you can still do an indicator if a form has changed content, that would be great regardless.

@brianteeman @Bakual just to point out why @C-Lodder @ciar4n and me thought that the current implementation might be better that the one in 3.x:

• The floating alert box addresses a problem: if the user is in in a long page, any raised alert will go unnoticed, unless we force a scroll to the top, which in many cases can be really unpleasant behaviour (think of a long form with countless fields...).

That said, we also had long discussions with Crystal for that matter. The initial idea was to have the alerts in the lower/upper right side, but then we were convinced to move it to the top centre. Anyways, this is not settled right now, so I guess this whole conversation should move to the relative issue.
By the way, no one is trying to push their own ideas here, we just throw ideas (most of the times backed with some preliminary code). It's up to the leadership and the community to decide which implementation should finally make it to J4.
Also please remember that J4 is not even alpha at this time...

That would only apply to messages which are created dynamically by JavaScript. Since the regular messages are shown on pageload you are already at the top and see them. I know currently it's the same place but that could be done different of course. JavaScript generated messages don't necessary need to be in that area, they can be something completely different.

By the way, no one is trying to push their own ideas here, we just throw ideas (most of the times backed with some preliminary code). It's up to the leadership and the community to decide which implementation should finally make it to J4.

Of course. And since it's in the current code an issue is rightfully raised and the discussion started. If nobody said anything, then the current code will be in J4 stable.

JavaScript generated messages don't necessary need to be in that area, they can be something completely different.

The message container and how items are displayed should be consistent regardless of how they were added to the queue (either the server side message queue or "on the fly" in the client). I wouldn't have drastically different behaviors based on a server versus client generated message.

Depends on what the message has to achieve imho (eg field validation errors could be right by the field), but yes in general they should be consistent.

Contextual messages (like form field errors, which IMO is better displayed with the field than in a message container) are different than general system messages. But since the API we're talking about is for general system messages, let's keep focused on that and keep dreaming for an ability to have contextual messages like that ?

@mbabker @Bakual we already have contextual messages for form fields validation AFAIK

we already have contextual messages for form fields validation AFAIK

Ah true. In J4 it shows a nice message below the empty title field. Nice job ?
Together with a generic floating error message which is over the title field ?