Page MenuHomePhabricator

Notices tray icon with 99+ needs more space
Closed, ResolvedPublic

Description

'99+' case (since it occupies three spaces) looks a little bit tight:

Some examples (the browser display scale is 110%):


The example from cawiki - 'D' in 'Discussion' takes more space than 'T' in 'Talk'


Monobook skin:

Details

Related Gerrit Patches:
mediawiki/extensions/Echo : masterUse the right counter for the right badge
mediawiki/extensions/Echo : masterAdjust unread counter position based on length
mediawiki/extensions/Echo : masterTweak badge styles

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptAug 9 2016, 2:42 AM

Change 304584 had a related patch set uploaded (by Catrope):
Tweak badge styles

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

Change 304584 merged by jenkins-bot:
Tweak badge styles

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

Etonkovidova updated the task description. (Show Details)Aug 23 2016, 4:18 PM

The changes have been made and they are in UI:
top: 9px;
left: 55%;
font-size: 0.9em;

vs previously implemented

top: 10px;
left: 50%;
font-size: 0.8em;

However, there are not much visual differences, in my opinion (all screenshots are made in full screen mode, 100% scale):


enwiki monobook
With 'D' in 'Discussion' in cawiki

the same as above in monobook:

With "You have new messages", the added space is noticeable.

@Pginer-WMF and @jmatazzoni: 99+ Looks better, in terms of the space around, if font-size: 0.8em; :

Compare with font-size: 0.9em;

The main problem seems to be that the counter in the badge is not considered when the layout is adjusted for the elements in the personal toolbar.

Keeping a fixed separation that works well for all possible lengths of the badge seems hard: too much space will make notification icons to feel too far apart when there is no badge and too few space will cause overlaps.

If it is not possible to make enough space for the badge we could adjust the degree it overlaps with the icon (the "left: 55%" CSS rule). One option is to increase the overlap in general (e.g., changing it back to left: 50%), but that won't get much extra room. Another option is to treat the "99+" case specially, and only in that case allow a bigger overlap (e.g., "left: 35%"). This will cover a bigger part of the icon, but that should not be a big discoverability problem for users that have reach that volume of notifications.

The main problem seems to be that the counter in the badge is not considered when the layout is adjusted for the elements in the personal toolbar.
Keeping a fixed separation that works well for all possible lengths of the badge seems hard: too much space will make notification icons to feel too far apart when there is no badge and too few space will cause overlaps.
If it is not possible to make enough space for the badge

It's possible to do this, and we even got it working, but it causes a problem: if you have the popup open and mark a notification as read, the number in the badge changes. If it changes from e.g. 10 to 9, the width of the badge shrinks, and so the badge (along with everything to the left of it) moves to the right. The popup is anchored to the badge, so it moves to the right too. So the net effect is that you clicked a button, and in response to that click the button moved away from under your mouse.

You can try this out yourself by setting width: auto; on the <a> in the badge (a.mw-echo-notifications-badge) and position: relative; left: 5px; on the :after of that <a>. You can also fake the number on the badge by changing the data-counter-text attribute.

Thanks for the clarification @Catrope. We definitely don't want the panel to shake as you mark notifications as read. Do you think there will be issues in supporting the other alternative I described (adjusting the "left" overlap percentage when the counter is "99+")?

Adjusting the left percentage won't cause this issue and should be doable. Figuring out that we are in the 99+ case in software might be a bit tricky though (because of translations and different numeral systems), so maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

Elitre added a subscriber: Elitre.Sep 13 2016, 3:34 PM

If anyone were to ask me, I'd advise just putting in some extra space next to the trays to accommodate the worst case and live with it looking extra-spacey when the counters are at low numbers. Would that be wrong?

Anyway, @Etonkovidova, I'm seeing this in the product review column. But I don't see where any changes were made. So I'm not sure what is being asked of me. @Catrope, did you settle on an approach here? Should I put it back in Dev?

If anyone were to ask me, I'd advise just putting in some extra space next to the trays to accommodate the worst case and live with it looking extra-spacey when the counters are at low numbers. Would that be wrong?

I'd prefer to fix the case where there is a problem ("99+") without generating a problem for more common cases (according to our data, 99% of the users have 5 or less unread notifications).

In the comments above I proposed the following: treat the "99+" case specially, and only in that case allow a bigger overlap with the badge (e.g., "left: 35%"). this makes the badge to act as if the text was right aligned (expanding to the left when needed instead of taking additional space to the right).

The comment form Roan where he indicates that "Figuring out that we are in the 99+ case in software might be a bit tricky though" is a bit confusing to me because is the software the one writing "99+" in the first place so I expected there should be a more elegant way to know the number of notifications a user has beyond parsing the badge text. Some possible ideas:

  • Add a specific class when the "+99" text is computed, and base the CSS rule to adjust the overlap on such class.
  • Base the decision in the width of the badge instead of the content. If the badge is "too wide" we increase the overlap.

Based on @Etonkovidova's screenshots above, it looks like changes were made but this issue is not fixed. @Catrope suggested:

maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

@SBisson, you worked on this. Would that solution be complicated? Would it work? As Pau points out, the 99+ case is pretty rare, so I'm moving this off the Q2 board (to Triage/Hot). But I'd like to fix it if we can. Stephane, if you think this will be easy to fix, go ahead and move it back to Q2.

Based on @Etonkovidova's screenshots above, it looks like changes were made but this issue is not fixed. @Catrope suggested:

maybe we could apply the adjusted left percentage in all cases where the badge text is longer than two characters.

@SBisson, you worked on this. Would that solution be complicated? Would it work? As Pau points out, the 99+ case is pretty rare, so I'm moving this off the Q2 board (to Triage/Hot). But I'd like to fix it if we can. Stephane, if you think this will be easy to fix, go ahead and move it back to Q2.

I've never worked on it but I can check what such a fix would look like.

I wrote down what this would look like (it's a few simple CSS changes but I don't remember what they are), but not in a very useful place. You should be able to find it by looking through my (Roan Kattouw (WMF)'s) edits on [[WP:VPT]] on enwiki

@jmatazzoni, @Catrope, @SBisson, In case it was lost in the comments above, I'll mention it again:

I'd prefer to fix the case where there is a problem ("99+") without generating a problem for more common cases (according to our data, 99% of the users have 5 or less unread notifications).

In the comments above I proposed the following: treat the "99+" case specially, and only in that case allow a bigger overlap with the badge (e.g., "left: 35%"). this makes the badge to act as if the text was right aligned (expanding to the left when needed instead of taking additional space to the right).

The comment form Roan (T142454#2602121) where he indicates that "Figuring out that we are in the 99+ case in software might be a bit tricky though" is a bit confusing to me because is the software the one writing "99+" in the first place so I expected there should be a more elegant way to know the number of notifications a user has beyond parsing the badge text. Some possible ideas:

  • Add a specific class when the "+99" text is computed, and base the CSS rule to adjust the overlap on such class.
  • Base the decision in the width of the badge instead of the content. If the badge is "too wide" we increase the overlap.

Is any of these a viable solution for the specific "+99" case?

Change 328404 had a related patch set uploaded (by Sbisson):
Adjust unread counter position based on length

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

Change 328404 merged by jenkins-bot:
Adjust unread counter position based on length

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

Etonkovidova added a comment.EditedDec 22 2016, 1:28 AM

Checked in betalabs - IE11, Windows 7, Chrome 54. FF 50, Safari 10.

@Pginer-WMF, please review the screenshots.

Added the screenshot for cawiki (to check the case with 'D') - looks ok.

Interestingly, that in monobook skin, two-digit numbers cover the icons almost completely. This is a slight regression - look at the monobook screenshot in the ticket description. Also, I added tabs 'unwatch' to see how new layout fits for users with many tabs.

@Pginer-WMF, please review the screenshots.

Good. The fix seems to avoid the overlap (except for the Monobook case, which can have a separate ticket).

Change 328730 had a related patch set uploaded (by Sbisson):
Use the right counter for the right badge

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

Change 328730 merged by jenkins-bot:
Use the right counter for the right badge

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

jmatazzoni closed this task as Resolved.Dec 22 2016, 11:08 PM