Page MenuHomePhabricator

Design automatic topic subscription first-run experience (DiscussionTools)
Open, Needs TriagePublic

Description

This task involves the work with creating mockups for the experience people will have immediately after having been automatically subscribed to a conversation for the first time.

The experience being designed in this ticket should:

  • Cause people to know when and how they will be made aware when someone responds in a conversations they've become subscribed to
  • Cause people to know where and how they can adjust if/when they are automatically subscribed to future conversations they participate in
  • Cause people to know they have the opportunity to customize the channel(s) (e.g. web, email) through which they are notified when someone responds in a conversations they're subscribed to

User stories

  • As someone who has just been automatically subscribed to a topic for the first time (read: posted a comment in an existing conversation or started a new one):
    • I want to know that I will be made aware when someone posts a new comment in the discussion I just participated in/started, so that I have an accurate expectation for how I will know if someone responds to me.
    • I want to know how (read: the channels) I will be made aware when someone posts a new comment in the discussion I just participated in/started, so that I can know where to look for updates about new activity in conversations I'm subscribed to
    • I want to how I can adjust the channel(s) (e.g. web, email) through which I am notified when someone responds in a conversations I've subscribed to, so that I can continue to ensure notifications are being delivered to me through the channels I check
    • I want to know where I can adjust whether I am automatically subscribed to the future discussions I start and/or participate so that I can continue to ensure the notifications I receive are valuable to me
    • I want to know where to look to know whether I am subscribed to a conversation or not, so that I can make sure the software is configured to behave in the way I expect.

Requirements

  • Experiences should be designed for mobile and desktop
  • The experience being designed as part of this ticket should not conflict with the existing You have subscribed! "popup" [i]
  • The first-run experiences being designed in this ticket should apply to the New Discussion Tool and the Reply Tool.
    • Note: we will consider the first-run experiences made for the remaining interfaces in T290779.
  • The first-run "dialog" / UI component should appear visually related/close to the [ subscribe ] affordance IF the [ subscribe ] affordance and the comment you posted/discussion you started are both visible on the screen at the same time.

Mockups

To be created.

Open questions

  • Meta: should this be implemented within and limited to Discussiontools or should this be implemented more generically so all Echo notifications can benefit from it?
    • For now, this implementation will be limited to the DiscussionTools
  • When/if should we implement a "first-run" experience for the moment where people are manually subscribing to a topic for the first time? How – if at all – should that experience impact/relate to this one?
    • For now, we will *not* be making any adjustments to the Manual Topic Subscriptions first-run experience.
    • Reason: we are assuming that once fully deployed, the majority of people will first be subscribed to a topic automatically.
  • For people who have not yet associated an email account with their Wikipedia account, what should should happen if they indicate they would like to receive new comment notifications via email?
    • We will revisit this question in T288178.
  • For people who have an email account associated with their Wikipedia account, BUT who have not confirmed said email account, what should should happen if they indicate they would like to receive new comment notifications via email?
    • People who meet these criteria will see the experience that will be designed and implemented in T288178.

Done

  • All Open questions are answered
  • Mockups are posted that fulfill the ===Requirements and ===User stories

i.

Screen Shot 2021-06-28 at 12.03.03 PM.png (502×538 px, 35 KB)

Related Objects

Event Timeline

Just crosslinking other tasks here with basically the same goal, but maybe from a slightly different workflow part... Which could potentially be addressed (at least in part) by fixing this task, depending on where the parts of the fix actually end up

T58028: Show Echo web notification (asking users to consider providing an email) to users who don't have an e-mail address associated with their account
T58074: Remind users who have entered an email address, but haven't confirmed it

Just crosslinking other tasks here with basically the same goal, but maybe from a slightly different workflow part... Which could potentially be addressed (at least in part) by fixing this task, depending on where the parts of the fix actually end up...

This is helpful context – thank you for saying something, @Reedy !

Just crosslinking other tasks here with basically the same goal, but maybe from a slightly different workflow part... Which could potentially be addressed (at least in part) by fixing this task, depending on where the parts of the fix actually end up...

This is helpful context – thank you for saying something, @Reedy !

No problem!

Thought it was worth mentioning incase we can do this in a more generic/"better" way (as features inside Notifications potentially? that this could explicitly trigger in certain situations), rather than just specifically part of DiscussionTools as it's really a bigger "problem" we see on Wikimedia Wikis :). Maybe notifications might be enough, or maybe more specific modals are needed (something to test with users I guess), but certainly could have the notifications trigger the modal, and also have a route from DiscussionTools too

And as always, there's often some useful historical context in these sorts of tasks, considering there's overlap here.

And as "yet another thing"... Just a reminder that peoples emails can become unconfirmed at a later date due to MediaWiki-extensions-BounceHandler (but that's probably smaller edge case, but something to bare in mind. Especially as really old accounts might now have unconfirmed email addresses)

I suspect there is a small minority of users who deliberately don't want to set an email address, so any "reminder" we come up with should be easily and permanently dismissable.

10-Feb meeting notes
Last week, we talked about whether it would be worthwhile to break the work required to support this functionality down further such that engineering could get started on it before the design was finalized.

Notes:

  • For the first iteration, if we are okay with people who A) do not have an email associated with their account or B) have not yet confirmed the email associated with their account being taken to Special:Preferences > User profile > Email options then it is NOT worthwhile for engineering to begin work on this before the design is finalized.
  • For the first iteration, if we woud rather people who A) do not have an email associated with their account or B) have not yet confirmed the email associated with their account being able to add/confirm their email without having to leave the page tehy are on, then it is worthwhile for engineering to begin work on this before the design is finalized.
ppelberg updated the task description. (Show Details)
ppelberg renamed this task from Prompt people to enter an email address as part of the replying and new discussion workflows to Prompt people to enter an email address to receive talk-page related notifications.Feb 24 2021, 3:08 AM

17-Feb meeting notes
Per the team's conversation on 17-Feb, we're going to generalize this task to support the following use cases:

  • Posting a comment with the Reply Tool for the first time
  • Starting a new topic with the New Discussion Tool for the first time
  • Subscribing to a topic for the first time

I've updated the name of this task and the description's ===Requirements section to reflect the above.

ppelberg renamed this task from Prompt people to enter an email address to receive talk-page related notifications to Design automatic topic subscription first-experience.Jun 30 2021, 1:05 AM
ppelberg assigned this task to iamjessklein.
ppelberg updated the task description. (Show Details)
ppelberg added a subscriber: iamjessklein.

(Updated the task description with greater definition. cc @iamjessklein)

ppelberg renamed this task from Design automatic topic subscription first-experience to Design automatic topic subscription first-run experience.Jun 30 2021, 1:07 AM

Here's draft mockup.

This design is built off the assumption that what people will see will not depend on the notification delivery channels they have enabled.
@ppelberg is going to file a new ticket for designing an experience that prompts people to enable email notification if they do not have it enabled.

@DLynch @matmarex - if you build off the designs here in the next two weeks, I will review and update with illustrations. The modal that should appear here is built off a component from the Growth team work.

Automatic Topic Subscriptions.png (3×6 px, 1000 KB)

@ppelberg is going to file a new ticket for designing an experience that prompts people to enable email notification if they do not have it enabled.

The ticket that captures what Jess described above is T288178.

ppelberg updated the task description. (Show Details)

Change 714438 had a related patch set uploaded (by Bartosz Dziewoński; author: Bartosz Dziewoński):

[mediawiki/extensions/DiscussionTools@master] [WIP] First-run experience popup for automatic topic subscriptions

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

You can try the first version here: https://patchdemo.wmflabs.org/wikis/4b915f2804/wiki/Talk:Main_Page (note that you must be logged in to see topic subscriptions)

image.png (2×3 px, 322 KB)

For ease of testing, the popup appears every time you get auto-subscribed. In the final version it will only appear once.


Thoughts and questions:

  • What to do when the [unsubscribe] button is off-screen (because the section is very long)? Right now the popup just kind of floats there in top-right corner, attached to nothing (and the little arrow detaches in an ugly way).
  • The copy needs to be different depending on whether the user has email notifications enabled.
  • I assumed the icon in the design was a placeholder, and I put in a bell icon instead (like we use for notifications), did you have a different one in mind?
  • How/When should the popup be hidden? Currently it's hidden when you click anywhere outside of it, or on the close button. I'm wondering whether it's too easy to accidentally close it, especially given that it is shown only once. On the other hand, we probably don't want it to stay visible forever and cover the content until the user leaves the page.

First-run experience design approaches
@iamjessklein: I've reviewed and added comments to the designs you have in Figma. [i]

Please let me know if you think anything I've written could benefit from more clarity.


i. https://www.figma.com/file/NreUF7q404NYuoMOPJGeWl/OWC-x--Work-in-Progress?node-id=2076%3A24581

During today's team meeting, we arrived at the following question which @iamjessklein will explore in the next design iteration:

  • In cases where the [ subscribe ] affordance is not visible to someone who just posted a comment or started a new discussion [i], how can the current design approach be adapted so that: 1) people become aware that they have automatically been subscribed to the conversation they just started or participated in and 2) the dialog/popup/etc. that makes them aware of "1)" is presented in such a way that people associate the information contained within it with the [ subscribe ] affordance?

CaseScreenshotLink
i. Example: a long conversation, where the section heading is not visible after you've published a comment in the conversation
Screen Shot 2021-09-08 at 2.05.58 PM.png (1×1 px, 612 KB)
Wikipedia:Village_pump_(technical)#dtenable_testing

Just want to clearly document the issue that we are focusing on right now. I created this flow chart (below) to show the tension that we are facing in this moment because we want to communicate two things simultaneously to contributors:

  1. Acknowledging that they have successfully "edited" the page and
  2. Informing them that they are automatic subscribed to topic subscriptions and direct them to where they can go to make changes to that (preferences)

Flow.png (1×3 px, 93 KB)

The tension is where the blue/green boxes on the chart appear.

The solution that we are working towards is "variant b":

Iteration on Variant B.png (3×7 px, 1010 KB)

We will be choosing from the following OOUI components:

OOUI options.png (1×1 px, 87 KB)

My next steps:

  1. iterating on variant B with ooui components for look and feel
  2. consider the ux for pages when the subscribe button isn't geographically close to the reply/new topic
ppelberg renamed this task from Design automatic topic subscription first-run experience to Design automatic topic subscription first-run experience (DiscussionTools).Fri, Sep 10, 11:22 PM
ppelberg updated the task description. (Show Details)

After doing a bunch of iteration, I believe that our best path forward is to use a modified version of the pop-up used by the Growth team. Compared to the simple dialog in OOUI, this would not feel as disruptive. The copy and imagery in these mockups are not final. The noticeable difference in the approach here is that I have moved away from anchoring the dialog to the "unsubscribe" button. My thinking here is that the primary message that we are trying to communicate here is:

  1. you have been auto-subscribed
  2. you can change that subscription in your preferences

I think that the anchor is adding unnecessary complexity to the communication in this moment by bringing in a third component (the button). This solution would eliminate the need to create different treatments for longer threads or mobile.

Second Iteration on Variant B.png (3×9 px, 2 MB)

Update: 14-Sep
I'm documenting the next steps that surfaced in the conversation @iamjessklein and I had offline earlier today:

  • 1. @iamjessklein is going to iterate on the designs she shared in T262103#7352110 by including an image within the currently-named Automatic Subscriptions dialog that leads people to know where on the page to look to know they're subscribed to a converation.
  • 2. @iamjessklein is going to take a first pass at drafting the copy that will be included within the dialog. For now, this copy will be shown within the mockups themselves.

...in line with the above I've made updates to the task description's ===Requirements and ===User Stories sections.

I've incorporated illustrations into the mockups (the copy is not final in these mockups).

Third Iteration on Variant B.png (3×8 px, 2 MB)

Additionally, on a separate figma frame I made three attempts at the copy for this:

Copy Explorations.png (599×1 px, 175 KB)

@ppelberg Please leave feedback on the figma files as comments.