Page MenuHomePhabricator

OOUI widgets for new notification design
Closed, ResolvedPublic

Description

Even without T115418: API should expose enough structured data about notifications that frontend can render them, we can start working on the front-end work for T114357: Notifications panel: simplify notification items, using fake data. This will also inform what the API output needs to contain.

Changes needed (adapted from T114357#1716968; see T114357 for mockups):

  • Move timestamp to the bottom right, make its font a bit larger
  • (While we're at it, we may want to fix T112217: Mark as read 'x' button is very small as well)
  • Notification text will no longer contain links
  • Add secondary actions at the bottom left. Secondary actions have a label, an icon, a tooltip and an href (link target)
  • "More" menu (dotdotdot icon) with more secondary actions.
    • "Explicit" secondary actions render outside of the more menu, "implicit" ones render inside of it.
    • For secondary actions rendered inside the more menu, the tooltip becomes the subtitle.
    • "Mark as read" is a built-in implicit secondary action for every notification type.
    • The volume control features in the mockups are out of scope for this task.

Event Timeline

Catrope raised the priority of this task from to Needs Triage.
Catrope updated the task description. (Show Details)
Catrope set Security to None.

Change 247017 had a related patch set uploaded (by Mooeypoo):
[WIP] Add ooui widgets for cross-wiki bundled notifications

https://gerrit.wikimedia.org/r/247017

Change 247017 merged by jenkins-bot:
Add OOUI widgets for cross-wiki bundled notifications

https://gerrit.wikimedia.org/r/247017

Checked in beta

Move timestamp to the bottom right, make its font a bit larger
(While we're at it, we may want to fix T112217: Mark as read 'x' button is very small as well)
Notification text will no longer contain links

Screen Shot 2015-12-17 at 9.53.50 AM.png (451×912 px, 65 KB)

Waiting for the following to be shown in UI

Add secondary actions at the bottom left. Secondary actions have a label, an icon, a tooltip and an href (link target)

and

"More" menu (dotdotdot icon) with more secondary actions.

User icon shown in Alerts - a working link.

Screen Shot 2015-12-17 at 9.40.29 AM.png (603×1 px, 173 KB)

User icon shown in Alerts - a working link.

Screen Shot 2015-12-17 at 9.40.29 AM.png (603×1 px, 173 KB)

For the user action, I used the standard icon for "user profile" from the icon repo:

uniE160 - userAvatar.png (20×20 px, 501 B)

It seems that this is not the one used in the panel or the current one used next to the user name in the personal toolbar, both also different to each other as can be seen in the screenshot above.

@violetto, can you confirm whether the icon I'm proposing is the standard one? Are there plans to update the one in the personal bar?

User icon shown in Alerts - a working link.

Screen Shot 2015-12-17 at 9.40.29 AM.png (603×1 px, 173 KB)

For the user action, I used the standard icon for "user profile" from the icon repo:

uniE160 - userAvatar.png (20×20 px, 501 B)

It seems that this is not the one used in the panel or the current one used next to the user name in the personal toolbar, both also different to each other as can be seen in the screenshot above.

@violetto, can you confirm whether the icon I'm proposing is the standard one? Are there plans to update the one in the personal bar?

No, it's not the one that's used... the codebase uses icons from OOUI's MediaWiki icon sets.

To be honest, I am a little confused about standards in these cases, though. It was my understanding that OOUI's MediaWiki theme and its accompanying icons are supposed to be the standard (and are also supported in the code)

Is that not the standard?

User icon shown in Alerts - a working link.

Screen Shot 2015-12-17 at 9.40.29 AM.png (603×1 px, 173 KB)

For the user action, I used the standard icon for "user profile" from the icon repo:

uniE160 - userAvatar.png (20×20 px, 501 B)

It seems that this is not the one used in the panel or the current one used next to the user name in the personal toolbar, both also different to each other as can be seen in the screenshot above.

@violetto, can you confirm whether the icon I'm proposing is the standard one? Are there plans to update the one in the personal bar?

No, it's not the one that's used... the codebase uses icons from OOUI's MediaWiki icon sets.

To be honest, I am a little confused about standards in these cases, though. It was my understanding that OOUI's MediaWiki theme and its accompanying icons are supposed to be the standard (and are also supported in the code)

Is that not the standard?

I took the icons from the icon repository which should be in sync with what's available in code normally (the exception being proposed changes pending to be updated in the code).

From the design resources, the icon I used is part of the "Current" folder (uniE160 - userAvatar.svg) while the one in MediaWiki seems to be part of the Wiki font. I assumed the later was pending to be updated, but @violetto will know better since she created those icons.

Aye, but we moved away from using the wiki font (in Flow, as well) and from my understanding, we moved into using ooui icon packs throughout Mediawiki.

Flow, for instance, required several icons ooui didn't have, so they were added in. If that is the case for Echo, shouldn't we add -- or replace -- the OOUI icons in the "MediaWiki" theme, which, as far as I understand, is supposed to be the new standard?

By the way, technically speaking, we can of course switch the icon around, but since notification widgets are generic and get their information (including which icon to use) from the API, it will be a bit of a structural manipulation to make them use icons from different locations -- especially if some are OOUI and some aren't. This adds complexity to the architecture of the code, so I think it's worth working on adding those icons into OOUI.

Also, in general, this is a little confusing for me. It was my understanding that MediaWiki is going towards OOUI'fication. The OOUI library works with icons that come from oo-ui-icon-XX classes, that use the ooui icon packs. Shouldn't we add the icons we want in there, for standardization?

The OOUI library works with icons that come from oo-ui-icon-XX classes, that use the ooui icon packs. Shouldn't we add the icons we want in there, for standardization?

  • All icons should come from the same technical repository (stored and delivered as engineers consider it better). Especially for general purpose icons, it does not make sense to have different versions on different extensions. The user avatar icon should be the same, and I'm not proposing to create an Echo-specific version of it.
  • The technical repository should be in sync with the design repository. Changes in the design repository (as icons get improved) should be propagated to the technical repository for their use anywhere in the UI.

avatar-inconsistent-icon.png (254×654 px, 24 KB)

As highlighted in the image above, the above points are not happening:

  • From the technical side, two different icons are used (next to the log-in and inside notifications). So I assume that icons are coming from different places in the code.
  • The icons used technically don't reflect the latest version proposed by the designers. Which are the ones I have as a reference when creating the mockups.

Regarding to notifications, we need to make sure we are using the icon from the right place in code. Regarding UI-Standardization, we need to clarify which is the intended icon and make sure it is the same in the different places.

After talking with @violetto it seems that the single-shape version was pending getting update into the code. I created a ticket (T123810) and submitted a patchset for it.

T123810 has been resolved now, which should change the icon inside the popup.

The icon on the personal bar comes from the Vector skin (last modified in https://gerrit.wikimedia.org/r/#/c/157990/ / rSVEC8d1ca663d6e70023c3cf77e5231b3d14496ebd0c) and has to be changed there. Easiest way would be to just replace the user-icon.png and user-icon.svg with copies of the new one (and should be uncontroversial, but you might want to read the discussion on the patch I linked). Changing the skin to actually use the OOUI icon might be a bit more involved.

All specs from this phab task have been verified either a part of other ticket's verification or during general testing.
The issue with avatar icon is still present - T123810: Update avatar icon.

I marked with check mark the feature that were checked, and with exclamation mark the issue that probably require some attention.

Move timestamp to the bottom right, make its font a bit larger
(While we're at it, we may want to fix T112217: Mark as read 'x' button is very small as well)
Notification text will no longer contain links
Add secondary actions at the bottom left. Secondary actions have a label, an icon,
a tooltip - out of specs? and an href (link target)
"More" menu (dotdotdot icon) with more secondary actions. It seems that dot menu is only for bundled cross-wiki notifications and wikitext talk pages?
"Explicit" secondary actions render outside of the more menu, "implicit" ones render inside of it.
For secondary actions rendered inside the more menu, the tooltip becomes the subtitle.- out of specs?
"Mark as read" is a built-in implicit secondary action for every notification type.
The volume control features in the mockups are out of scope for this task.

a tooltip - out of specs? and an href (link target)

I recall @SBisson mentioning that the full-name of pages was included as the title attribute to allow users to check the tooltip in case the truncation generated some ambiguity. Not sure if there is a ticket about adding the tooltips, or whether that work was already completed.

"More" menu (dotdotdot icon) with more secondary actions. It seems that dot menu is only for bundled cross-wiki notifications and wikitext talk pages?

This was captured in T125949: For items with more than 2 actions, hide the rest under the "..." menu

For secondary actions rendered inside the more menu, the tooltip becomes the subtitle.- out of specs?

This was captured in T126738: Show descriptions for the actions under the "..." menu on notifications

a tooltip - out of specs? and an href (link target)

I recall @SBisson mentioning that the full-name of pages was included as the title attribute to allow users to check the tooltip in case the truncation generated some ambiguity. Not sure if there is a ticket about adding the tooltips, or whether that work was already completed.

The tooltip is added in the truncation task (T121822)

"More" menu (dotdotdot icon) with more secondary actions. It seems that dot menu is only for bundled cross-wiki notifications and wikitext talk pages?

This was captured in T125949: For items with more than 2 actions, hide the rest under the "..." menu

For secondary actions rendered inside the more menu, the tooltip becomes the subtitle.- out of specs?

This was captured in T126738: Show descriptions for the actions under the "..." menu on notifications

Action's subtitles (called descriptions in the code) and tooltips are 2 different things. Please make it explicit in the above ticket if they shouldn't be.

Action's subtitles (called descriptions in the code) and tooltips are 2 different things. Please make it explicit in the above ticket if they shouldn't be.

I tried to capture this in a new ticket: T127424
The basic idea is that descriptions are materialised as text or a tooltip depending on the space available (tooltip for actions in the notification, and subtitle text for those inside the menu).

jmatazzoni subscribed.

Pau wrote:

I tried to capture this in a new ticket: T127424
The basic idea is that descriptions are materialised as text or a tooltip depending on the space available (tooltip for actions in the notification, and subtitle text for those inside the menu).

The requirement for "description" that are diaplsyed as hover text in menus-- described in T127424 and T126738-- have been put on hold (in the backlog) until such time as we have more complex functions, like volume control, that require description for clarity.

It looks like that hover text is the only thing outstanding (correct, @Etonkovidova?), so I'm marking this ticket resolved.