Page MenuHomePhabricator

Notifications Popup is underlying Hovercards, should be on top
Closed, InvalidPublic


When Hovercards are enabled, the popup has a higher z-index than the Notifcation (Notices) popup, which it shouldn't have.

Event Timeline

Volker_E created this task.Oct 3 2016, 10:29 PM
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptOct 3 2016, 10:29 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Volker_E updated the task description. (Show Details)Oct 3 2016, 10:30 PM
Volker_E added a project: Page-Previews.
jmatazzoni closed this task as Declined.Oct 11 2016, 10:15 PM

if we understand the issue, this doesn't seem like it's necessarily incorrect behavior.

Wait, isn't Notices for the user more important than a Page Preview?

jmatazzoni reopened this task as Open.EditedOct 11 2016, 11:05 PM

Reopening this but still not convinced that this is an issue requiring our attention. What I'm seeing is that if I leave my Notifications Panel open for some reason (why?) then go and hover over something to get the hovercard, what I arguably want is to see the hovercard. Which I do. I'm happy. What's the problem?

@Pginer-WMF, what do you think?

Pginer-WMF updated the task description. (Show Details)Oct 12 2016, 9:41 AM

Some thoughts:

  1. I don't think that we need to decide what is shown on top based on the general importance for the user for those elements. As Joe pointed in the case of hovering a link the specific context is the user being interested in that particular piece of information. So getting it may be expected. It would be more problematic if hovercards remain open and the notification panel opened behind them when the user tries to open it. Fortunatelly, thanks to the transient nature of hovercards, this is not possible.
  2. In general terms of layout consistency it is true that intuitively the "chrome" is often considered to be above the content. According to this, any part of the content (paragraphs of text or hovercards) should be below the more persistent controls in the "chrome" such as the notifications panel. We need also to consider that if the notification panel had links for which hovercards are shown, those would appear on top of the notification panel. So the change would be about making the hovercards to be one step higher than the link they point to. Therefore, it seems the change is about Hovercards and not the notification panel.
  3. In practical terms hovercards are shown below the link when there is room for it, so the overlap case is even more of an edge case.

Given the above considerations I'm ok with either:

  • Define more consistent guidelines on how to define the depth of UI layers as part of our design guidelines, and Hovercards to be adjusted to follow that (even if that involves showing it behind the notification panel in the example).
  • Let hovercards to be a clarification layer on top of everything until we find a more practical issue and start a wider consistency process then.
ovasileva triaged this task as Low priority.Dec 5 2016, 3:58 PM
ovasileva added a subscriber: ovasileva.

@Nirzar - any thought on this? I'm okay with allowing hovercards to be on top for such cases.

Nirzar added a comment.Dec 5 2016, 5:58 PM

Let hovercards to be a clarification layer on top of everything until we find a more practical issue and start a wider consistency process then.

this works for me. page previews are reactions to the last action, it chronologically precedes notification popup. current behavior is valid until we have layer hierarchy guidelines.

ovasileva closed this task as Invalid.Dec 19 2016, 11:01 PM

for now considering this expected behavior