Here's the first-run task T133230

I can see how discoverability is a problem if you don't forcibly enable, but even so, at least for power users I think some kind of opt-in process would be better. Maybe display hovercards the first time, or first few times, but require some sort of confirmation to keep it enabled, and disable if that does not happen.

@Jhernandez @Prtksxna I can't find documentation of it, but I could have sworn that we had an agreement to reverse this: T64952 and had put something in place. Anyone with Navpops should not see hovercards.

In T135628#2307389, @JKatzWMF wrote:

@Jhernandez @Prtksxna I can't find documentation of it, but I could have sworn that we had an agreement to reverse this: T64952 and had put something in place. Anyone with Navpops should not see hovercards.

I can't find a related task either, but yes, when the feature is default it should give priority to Navigation Popups (if enabled), and when its in Beta Features, Hovercards should be given priority.

In T135628#2306908, @Tgr wrote:

I can see how discoverability is a problem if you don't forcibly enable, but even so, at least for power users I think some kind of opt-in process would be better. Maybe display hovercards the first time, or first few times, but require some sort of confirmation to keep it enabled, and disable if that does not happen.

Some version of T133230: First run opt-out experience for hovercards might be helpful here.

In T135628#2311308, @Prtksxna wrote:

Some version of T133230: First run opt-out experience for hovercards might be helpful here.

Yes, but it should be an opt-in experience, not an opt-out one.

I'm not sure about the opt-in aspect of things, and anyway our approach will reflect the outcome from T133230: First run opt-out experience for hovercards.

But with respect to the behavior when both things are On - yes, the NavPopups should override Hovercards. I'll tag this for sprint 73.

Change 291026 had a related patch set uploaded (by Bmansurov):
Disable Popups when the Navigatio Popups gadget is enabled

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

I've +2ed but note my comment - you might want to do a follow up - but the bug is now fixed.

@Jdlrobson left a comment there too.

Change 291026 merged by jenkins-bot:
Disable Popups when the Navigation Popups gadget is enabled

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

017cb24 has been pulled by our staging server.

I've confirmed that this bug is fixed on our staging server.

N.B. that the Popups extension isn't enabled on the Beta Cluster /cc @Jhernandez

See T136602.

The above patch has been SWAT deployed and fixed the problem.

@bmansurov Is this task ready for signoff on the sprint board?

@MBinder_WMF not yet, that was a temp fix.

Change 292744 had a related patch set uploaded (by Bmansurov):
Detect whether NavPopups gadget is enabled before showing Hovercards

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

@dr0ptp4kt currently we don't take the Navigation Popups gadget into account when logging events, which may distort your EL analysis. When the gadget is enabled with the change above, Hovercards will be disabled. This means that even though a user sees a navigation popup (using the gadget), 'dwelledButAbandoned' event will be logged when the user dismisses the popup. Is that OK? Or should we also modify the schema to indicate that the gadget is enabled (thus the Hovercards extension is not)?

The old behavior was that enabling NavPopups had the same effect as manually disabling Hovercards: there was a link in the footer to reenable, and that could be used to switch between NavPopups and HoverCards, without having to change gadget preferences. If it's possible to do that, it would be preferable to the current behavior (where Hovercards seems to totally disappear when NavPopups is enabled).

Also it would be nice if there was a way to select "Hovercards when available, NavPopups otherwise", given that NavPopups supports various link types that Hovercards doesn't (user page, diff etc).

In T135628#2360158, @bmansurov wrote:

@dr0ptp4kt currently we don't take the Navigation Popups gadget into account when logging events, which may distort your EL analysis. When the gadget is enabled with the change above, Hovercards will be disabled. This means that even though a user sees a navigation popup (using the gadget), 'dwelledButAbandoned' event will be logged when the user dismisses the popup. Is that OK? Or should we also modify the schema to indicate that the gadget is enabled (thus the Hovercards extension is not)?

Okay, I think I understand. You're saying that we might, at least for logged in users, see a decent number of dwelledButAbandoned events for the navpopups gadget users, who are logged in.

@bmansurov, if it's a very simple change you can do in this part of the task, sure, go ahead and add it as `navpopGadgetEnabled' to the schema.

@Tbayer & @JKatzWMF, note for any future queries you might need to add results from two tables for time series analysis.

@bmansurov, if you feel a new task needs to be created, please do so and then tag it for sprint 75.

Good catch!

@Tgr, your comments noted. Right now we're trying to keep it simple, but let's ensure this is visible in our collective backlog so we tackle it when we come back around to the preferences workflow.

T137203 has been created as suggested by @dr0ptp4kt.

Rechecking and merging this is blocked on T137265.

Change 292744 merged by jenkins-bot:
Detect whether NavPopups gadget is enabled before showing a hovercard

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

@bmansurov Should we cherry-pick the change to the wmf/1.28.0-wmf.5 branch so that it can rid this week's train and, hopefully, be signed off towards the end of the sprint?

@phuedx I'm not sure as this is not an urgent bug and things were not broken on the wmf/1.28.0-wmf.5 branch.