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.

flows.png (1×3 px, 172 KB)


Flow no 1
Nth hovercard use

Desktop HD.png (1×2 px, 1 MB)

on hover-out of first hovercard

Desktop HD Copy 2.png (1×2 px, 847 KB)

Flow no 2

Event Timeline

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.

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 subscribed.

@Nirzar - updated workflows based on our conversation yesterday

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

Nirzar moved this task from Design to Product Owner Backlog on the Web-Team-Backlog board.
Nirzar edited projects, added Web-Team-Backlog; removed Web-Team-Backlog (Design).

@ovasileva moving to product manager backlog

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

@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 subscribed.

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.

Done, yes?

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