Page MenuHomePhabricator

First run opt-out experience for hovercards
Closed, DeclinedPublic



Let readers know about new feature (hovercards) and provide an opportunity to decide whether to use it or not.


We ask them after using the hovercards.


There are two proposed flows for asking readers if they would like to keep the hovercards.

Flow no 1:

  1. Hovercards are enabled
  2. User sees page previews upon first hover
  3. User sees page previews for subsequent X hovers
  4. User is presented with option to disable
  5. User selects to keep/disable
  6. User preference is kept.

Question - what happens when users switch browsers? Perhaps we should cap the onboarding experience at X weeks, months after page previews are live.

Flow no 2:

  1. Hovercards are enabled
  2. User is presented with a notice in the form of a page preview and prompted to view the preview
  3. User views review
  4. System presents option to enable/disable
  5. User preference is saved.


Flow no 1
Nth hovercard use

on hover-out of first hovercard

Flow no 2

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 20 2016, 10:58 PM

I assume this is when we push it to stable? Otherwise the user can always disable it in the beta features page.

What shows after the user taps "Disable it"?

What if the user tapped through on the hovercard instead of dismissing the hovercard?

Also, how would the user re-enable it?


disable it will disable it and show how to enable it back. I will upload the mocks

What if the user tapped through on the hovercard instead of dismissing the hovercard?

That's a good question. i don't have answer yet.

Also, how would the user re-enable it?

we are working to finalize the design for re-enabling hovercards.

@Moushira can you start driving traffic to this page? (VP's and mailing lists?)

dr0ptp4kt triaged this task as Medium priority.Apr 26 2016, 5:52 PM

According to the data from the A/B test on huwiki (T139319#2467334, T139319#2509065) the settings cog is very rarely clicked (in <0.01% of hovers), which is surely a good argument for such a change.

ovasileva updated the task description. (Show Details)Oct 6 2016, 1:58 PM
ovasileva added a subscriber: ovasileva.

@Nirzar - updated workflows based on our conversation yesterday

Nirzar updated the task description. (Show Details)Oct 6 2016, 4:42 PM
Nirzar updated the task description. (Show Details)

@Nirzar - looks good. I like both. I think this is a good candidate for testing

@ovasileva A/B testing or usability testing?

Nirzar updated the task description. (Show Details)EditedOct 17 2016, 11:10 PM
Nirzar moved this task from Design to Product Owner Backlog on the Readers-Web-Backlog board.

@ovasileva moving to product manager backlog

@Nirzar - both, but A/B testing would be difficult, so usability testing in particular

@ovasileva are we still planning on doing this?

@Nirzar - as we stand right now, I don't think so, but I'd like to keep it open as a reference for once we go into approaching the enwiki community

Jdlrobson added a subscriber: Jdlrobson.

Per it feels like we should decline this.

I don't see the point in allowing it to clutter the backlog.

As a suggestion if we don't want to decline this, maybe we should start using Reading-Web-Planning again?
I'll start an email thread.

ovasileva changed the task status from Open to Stalled.Jun 12 2017, 3:25 PM
ovasileva added a project: Page-Previews.

Not a bad idea. However, I would like to have it appear at least on the page previews backlog, if not the overall reading backlog. As it was in the product owner backlog, I don't necessarily see it as clutter - these are the tasks that require product decisions, such as this one. Marking it as stalled for now.

This comment was removed by demon.
demon added a subscriber: demon.Jun 30 2017, 11:29 PM

Done, yes?

Still stalled, technically. After we deploy, I think it'd be okay to close, we will most likely not be doing this.

Nirzar closed this task as Declined.Oct 10 2017, 9:43 PM