Page MenuHomePhabricator

Notifications tray (mobile) - design refinements
Open, LowPublic

Description

Description

I think with some design refinements the read-state for notifications could be clearer. Currently the black text and dark gray background don't do an adequate job of communicating that a notification has been read.

User story: As a user, I'd like a clearer read-state for notifications, so that I have a better idea of when a notification has been read.

Designs

currentrefined

Changes to "read" treatment:

  • update background to Base90 (#f8f9fa)
  • change icon color to Base20 (#54595d)
  • change primary text to Base30 (#72777d)
  • change secondary text to Base50 (#a2a9b1)

Developer notes

This is in the Echo extension
Note: Special:Notifications is incompatible with foreign MFContentProviderScriptPath.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptJun 11 2019, 4:07 PM
ovasileva triaged this task as Normal priority.Jun 18 2019, 3:40 PM
ovasileva moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.
MBinder_WMF updated the task description. (Show Details)Jun 19 2019, 4:19 PM

noting the related task here T225260

ovasileva set the point value for this task to 2.Jun 19 2019, 4:21 PM
ovasileva added a project: Notifications.
Restricted Application added a project: Growth-Team. · View Herald TranscriptJun 19 2019, 4:21 PM
Cntlsn added a subscriber: Cntlsn.Jul 5 2019, 11:45 AM

@alexhollender thanks for working on this.
I think the proposed color treatment will definitely makes the difference between read and unread notifications more clear and explicit.
It should work equally well for desktop too.

While we're here, a couple of concerns about notifications in general:

  • It doesn't seem very clear to me that the read/unread notification dots are interactive. I think the proposed color treatment for the read state of the dots is more correct than the previous one, but I'm still wondering whether the user will understand they are interactive in the first place, when they are in unread mode (I didn't know it was possible until I bumped into this, and the related task).
    • Any thoughts about this?
  • I have the feeling that the links sticking to the bottom of the notification container (user avatar icon + username) won't look like interactive elements, mostly because the largest area of the notification is itself a link.
    • Do we have any data on the user interactions with those links?
    • Is it possible that a different color treatment would make the interactivity more explicit?
Cntlsn updated the task description. (Show Details)Jul 8 2019, 4:38 PM
JTannerWMF moved this task from Inbox to External on the Growth-Team board.Jul 9 2019, 7:34 PM
JTannerWMF added a subscriber: JTannerWMF.

Moving this to external as it sounds like Readers-Web-Backlog working on this

@Cntlsn

Interactive read/unread dot
I agree that this isn't super clear. On desktop at least it has a hover state, but on mobile it's not discoverable at all. This is a small fix for starters, just so it stands out more: T227624. Aside from adding a "mark as unread" button I don't have any other small ideas yet. We could look at some other mobile notification systems.

Username link
Agreed. Same issue here, it's more discoverable on desktop with the hover state. We could try adding an underline to the username, though it might look weird with the avatar?

@alexhollender

Username link
Agreed. Same issue here, it's more discoverable on desktop with the hover state. We could try adding an underline to the username, though it might look weird with the avatar?

What about making it progressive blue like other links?

@alexhollender -- do you think parallel issues to the ones you're describing on this task also exist on desktop. If so, do you think we should also address desktop while we're at it?

@MMiller_WMF I believe our involvement with this started exactly because @alexhollender thought that while at it, it would be a good idea to normalize echo on both mobile and desktop. But I would leave it to him to add any further details.

@alexhollender -- do you think parallel issues to the ones you're describing on this task also exist on desktop. If so, do you think we should also address desktop while we're at it?

Yes (and yes @Cntlsn ;). My understanding is that the work needs to be done separately so I've created T228819.

@Jdlrobson an additional refinement we'd like to make is to the color and outline of the dot indicator. Based on T227624#5337647 I've included that refinement in the desktop version of this task (T228819), with the understanding that it will carryover to mobile. Here is a mockup for reference:

Jdlrobson updated the task description. (Show Details)Aug 1 2019, 9:10 PM
Jdrewniak removed Jdrewniak as the assignee of this task.Aug 13 2019, 5:18 PM
Jdrewniak added a subscriber: Jdrewniak.

@alexhollender, there are three icon colors currently AFAIK: progressive (blue), constructive (teal), and black. The recommendation in the description is to change progressive for read notifications only (a fourth color). Should the others be changed?

Niedzielski removed Niedzielski as the assignee of this task.Aug 23 2019, 6:42 PM

I've been poking around in the Echo extension which I haven't developed in previously. These are my recommendations for how to proceed with this task but I'm unsure if the changes are wanted or if we're the best team for them given component responsibilities:

  • In echo.variables.less, @import 'mediawiki.ui/variables';; replace overlapping colors with MediaWiki definitions.
  • Consult with Growth on icon color needs. This task proposes unread and read icon states whereas previously there was no distinction in the icons themselves. The Echo extension defines a EchoNotificationIcons configuration in extension.json. This configuration is passed to a ResourceLoaderImageModule subclass, ResourceLoaderEchoImageModule, which parses the config into a format the superclass understands. There may be other concerns here that I'm unaware of but I have at least the following questions:
    • Why do we need this level of configuration? Can we use ResourceLoaderImageModule directly? If not, let's drop ResourceLoaderEchoImageModule and convert the config to a standard ResourceLoader module in extension.json.
    • How should we handle the need for multiple icon variants? At least the following options exist: 1) use variants with ResourceLoaderImageModule directly, 2) add variant support to ResourceLoaderEchoImageModule and the custom config, 3) manually style the SVGs.
  • Update the selectors as needed to use the new icons (this task).

Since this is some work, now is the time to remove specialization in MobileFrontend and MinervaNeue that makes changes difficult and bloats the code. To whatever extent possible, extract the following styles from MobileFrontned and Minerva:

  • MinervaNeue/skinStyles/ext.echo.styles.special/SpecialNotificationsOverlay.less
  • MinervaNeue/skinStyles/mobile.notifications.overlay/minerva.less
  • MobileFrontend/resources/mobile.notifications.overlay/NotificationsFilterOverlay.less
  • MobileFrontend/resources/mobile.notifications.overlay/NotificationsOverlay.less

@ovasileva, I'm happy to task this out if these changes are a priority.

@alexhollender, there are three icon colors currently AFAIK: progressive (blue), constructive (teal), and black. The recommendation in the description is to change progressive for read notifications only (a fourth color). Should the others be changed?

Thanks for pointing that out. When I look at notifications on desktop and mobile all icons are blue. Can you post a screenshot?

Jdlrobson removed the point value for this task.Aug 26 2019, 5:23 PM

Removing story points per https://phabricator.wikimedia.org/T225535#5434577 as it sounds like the scope has changed given further analysis.

ovasileva lowered the priority of this task from Normal to Low.Aug 28 2019, 4:14 PM
ovasileva moved this task from Incoming to Triaged but Future on the Readers-Web-Backlog board.

@alexhollender we can decline this if we can solve T235193 and use the desktop modal on mobile as part of T226125 - let's chat about this at next opportunity