| Esanders | |
| Feb 9 2023, 4:01 PM |
| F58925302: image.png | |
| Mar 26 2025, 2:10 PM |
| F58925299: image.png | |
| Mar 26 2025, 2:10 PM |
| F58925296: image.png | |
| Mar 26 2025, 2:10 PM |
| F36904218: image.png | |
| Mar 9 2023, 8:36 PM |
| F36823989: image.png | |
| Feb 13 2023, 7:27 PM |
| F36823983: image.png | |
| Feb 13 2023, 7:27 PM |
| F36817938: image.png | |
| Feb 9 2023, 4:01 PM |
| F36817936: image.png | |
| Feb 9 2023, 4:01 PM |
When all your notifications are read, the notification icons at the top of the page are supposed to be 50% opacity.
This works fine in Vector 2010:
However in Vector 2022 they are full opacity to begin with...
...until you click on them to open the dropdown, at which point they get replaced with OOUI versions and take on the correct opacity:
Update:
The decided fix is to never use 50% opacity as that looks like a disabled button, which they aren't.
I will submit fixes, but the approach described in T257143#8407087 that led to this sounds backwards. Vector should avoid knowledge of extensions where possible, and instead skin-specific support should be added to the extensions (be that different CSS, or a different DOM). Why was that not done in this case?
Change 888048 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/skins/Vector@master] Copy over Echo CSS classes required for "all-read" styling
Not 100% sure if this was intentional. There was a requirement somewhere that icon colors match across Vector 2022 skin (that wasn't a problem with Vector since Vector seldom made use of icons). @alexhollender_WMF @RHo can you confirm the correct behaviour here?
Also wondering if Growth team or web team should take this on (I'm guessing this falls into web team domain)
Ah I guess this is a bit of a grey area (pardon the pun) as Echo Notifications is maintained by Growth. I would argue that the intended behaviour should be that notifications and alerts icons should remain the same colour when everything is read since that lighter grey colour indicates disabled state, and one can still open the notifications and alerts trays here.
It is also a redundant visual indication, since the absence of a numbered badge to indicate unread messages if how one knows they have no need to open the alert/notification to be read.
If anything, could we re-purpose this task to not make the Vector legacy buttons change colour?
The greyed-out icon was specified by @Pginer-WMF in T115845:
Finally, when all notifications are read for a given category, only lighter grey icons (#71777D) are shown (with no badges) in order to avoid demanding too much user attention but still providing an entry point to check the different kinds of notifications.
I have no particularly strong opinions on the matter.
There is another class that is not copied over, which is for 99+ icons, so the icons move when the popup is opened. This will need to be fixed as well:
Before:
@RHo, @KStoller-WMF - we're not sure what to do on this one, and willing to follow whatever Growth thinks is best. Any thoughts on how to proceed?
As mentioned in the previous comment, I would be inclined to decline this task since I'd argue in Vector 2022 we are following using the standardised icon buttons for alerts and notifications where making the colour this gray would make it look incorrectly as though they are in inactive/disabled state.
I would argue that the intended behaviour should be that notifications and alerts icons should remain the same colour when everything is read since that lighter grey colour indicates disabled state, and one can still open the notifications and alerts trays here.
That makes sense to me.
@ovasileva - I support whatever @RHo thinks is best here; this seems more Design / UX territory than Growth PM territory.
In which case we need to fix Echo to remove these styles otherwise the grey applies sometimes in Vector 2022 and always in other skins. So there is still work to do here.
Change 894660 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/Echo@master] Remove 50% opacity from notification badges when they are all read
Change 894660 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Remove 50% opacity from notification badges when they are all read
Is deprecating the use of gray in skins really a good idea? This change has now created a situation where some icons are black and some icons are gray, which is inconsistent. This is certainly not an aesthetic improvement. I think an exception should be considered for Vector 2010, returning the bell and tray icons back to their original gray color.
T331502: Ping and notification icons changed from gray to black in skin Vector 2010
Is deprecating the use of gray in skins really a good idea? This change has now created a situation where some icons are black and some icons are gray, which is inconsistent. This is certainly not an aesthetic improvement. I think an exception should be considered for Vector 2010, returning the bell and tray icons back to their original gray color.
T331502: Ping and notification icons changed from gray to black in skin Vector 2010
My understanding is this ticket was meant to address removing the flicker of grey from the bell and tray icon on the personal tools only, and only on Vector 2022, but sounds like this change has meant collateral impact on Vector 2010. @Jdlrobson is there a way to fix on Vector 2022 so that it doesn't cause the issue described in T331502 for Vector 2010?
@Esanders perhaps we should revert your patch and more clearly define the expected behaviour here? I don't really have the time to focus on this right now.
Change 902153 had a related patch set uploaded (by Novem Linguae; author: Novem Linguae):
[mediawiki/extensions/Echo@master] Revert "Remove 50% opacity from notification badges when they are all read"
Change 902154 had a related patch set uploaded (by Samtar; author: Novem Linguae):
[mediawiki/extensions/Echo@wmf/1.40.0-wmf.27] Revert "Remove 50% opacity from notification badges when they are all read"
Change 902155 had a related patch set uploaded (by Samtar; author: Novem Linguae):
[mediawiki/extensions/Echo@wmf/1.41.0-wmf.1] Revert "Remove 50% opacity from notification badges when they are all read"
Change 902153 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Revert "Remove 50% opacity from notification badges when they are all read"
Change 902155 abandoned by Samtar:
[mediawiki/extensions/Echo@wmf/1.41.0-wmf.1] Revert "Remove 50% opacity from notification badges when they are all read"
Reason:
Wasn't needed
Change 902154 abandoned by Samtar:
[mediawiki/extensions/Echo@wmf/1.40.0-wmf.27] Revert "Remove 50% opacity from notification badges when they are all read"
Reason:
Wasn't needed
Unclear what we want to do here (if anything)
We still need to address the inconsistency between the JS and noJS versions in Vector 2022, as described in the task.
This change has now created a situation where some icons are black and some icons are gray, which is inconsistent.
We already have a mix of black and grey icons. The top icons are black unless you have no unread notifications. The grey icons in the popup indicate they are muted/secondary actions. This is not the case for the main badge icons.
I think an exception should be considered for Vector 2010, returning the bell and tray icons back to their original gray color.
I don't understand why this should behave differently in V2010 vs V2022.
I still agree that there is no need for the greyed-out icon when there are no notifications, and think we should re-apply the patch. At the very least we should apply the patch to Vector 2022.
Change 902154 restored by Esanders:
[mediawiki/extensions/Echo@wmf/1.40.0-wmf.27] Revert "Remove 50% opacity from notification badges when they are all read"
Change 902154 abandoned by Esanders:
[mediawiki/extensions/Echo@wmf/1.40.0-wmf.27] Revert "Remove 50% opacity from notification badges when they are all read"
Reason:
wrong patch
Change 929707 had a related patch set uploaded (by Esanders; author: Esanders):
[mediawiki/extensions/Echo@master] Don't grey-out badge in Vector 2022
^ The above patch is now limited to Vector 2022. Note this just keeps the badge black after clicking on it. It is already always black when the page loads.
To be clear the patch just resolves the before/after-first-click inconsistency in V22. All other skins are unchanged:
Before patch
| Before first click | After first click |
|---|---|
 |  |
After patch
| Before first click | After first click |
|---|---|
|  |
While there is still some disagreement about whether the initial rendering should be black or grey, the above change to make it consistent within a session should be uncontroversial.
Change #929707 merged by jenkins-bot:
[mediawiki/extensions/Echo@master] Don't grey-out empty badge in Vector 2022 after first click
@Esanders do you want to keep this ticket open for anything further, or can we call this purely the vector2022 consistency part?
I'm have no complaints with the current behaviour. It is at least now consistent within skins. If others have a problem with inconsistency across skins I'll leave it to them to file a new task.