@iamjessklein can you please fill in the task description's ===Done section?

@ppelberg - I've added in the Done criteria in the "Description" - please review.

In T279149#6972382, @iamjessklein wrote:

@ppelberg - I've added in the Done criteria in the "Description" - please review.

Thank you, @iamjessklein. I made some tweaks to:

• The ===User Stories section
• The ===Done section

...provided the above look good to you; I think this task description is all set.

Considering that we currently don't have an opinion on T279312, and we don't have a dashboard of some sort for notifications, and aren't planning on bringing topic subscription into the Watchlist, I think we should default to using the same visual language as Flow (star).

One thing that we might want to consider is introducing "blue dots" for guidance for the first few uses of the feature and provide an educational tip to explain the feature.

example screenshots of blue dots

@iamjessklein: are you able to describe the connection you see between these reasons [i] and the proposed path forward [ii]?

Reason I ask: I'd been thinking that on 4-March [iii] we came to decide that, for now, we would consider new comment notifications as distinct from watchlist entries. As such, re-using the same icon (the "Star") in these two contexts could lead people to think these two actions ("Watching" and "Subscribing") are related in ways that they are not [currently].

i.

In T279149#6977015, @iamjessklein wrote:

Considering that we currently don't have an opinion on T279312, and we don't have a dashboard of some sort for notifications, and aren't planning on bringing topic subscription into the Watchlist...

ii.

In T279149#6977015, @iamjessklein wrote:

...I think we should default to using the same visual language as Flow (star).

iii. T273911#6882727

So for the medium term we aren't putting anything in the watchlist or having a subscription dashboard, which means there's no holistic way for contributors to manage all of their topics. I recognize that the star could potentially be confusing for senior contributors, but I don't think we should introduce any new iconography (and possibly new language is a bad idea as well) if in the long term we do end up having some sort of topic management system that requires yet another visual language (so we would we end up changing it many times).

After a series of conversations which I summarized over in T279150#6981608, we've come to three potential designs for near term implementation.

Option 1: Text/ Subscribe (what's currently implemented)

Option 2: Text/ Subscribe next to a pipe adjacent to the Edit button

Reason NOT to do this: we know for sure that this will change when we start working on the topic panel ui treatments so it will be 2 changes that someone will have to get used to.
Reason TO do this: it's not styled and therefore we have time to see how this will relate to the future topic panel design.

Option 3: Overflow to match what's over in Echo Notification dropdown (T279150)

Reason NOT to do this: It's just an extra click to get to what you want to get to.
Reason TO do this: if we want to think about this overflow menu pattern and expand it into a more robust component later on.

I'd love thoughts on these designs (which can be seen in greater detail in Figma). Do you feel any conviction about which direction we take?
cc/@ppelberg @Esanders

Thank you for posting these, @iamjessklein.

In T279149#6981687, @iamjessklein wrote:

I'd love thoughts on these designs (which can be seen in greater detail in Figma). Do you feel any conviction about which direction we take?

I think we should move forward with Option 2: Text/ Subscribe next to a pipe adjacent to the Edit button.

Reasons:

• I think this approach will increase the number of Senior Contributors who experiment with topic subscriptions because the "costs" for doing so will be relatively low. [i]
• This approach aligns with the strategy we've been following, and has proven to be reasonably effective, to-date: 1) Quickly validate the usefulness of new functionality by way of minimally invasive changes in the page's UI [ii] and then, 2) Improve the discoverability of said new functionality. [iii]

Reason NOT to do this: we know for sure that this will change when we start working on the topic panel ui treatments so it will be 2 changes that someone will have to get used to.

• @iamjessklein: can you share what the "2 changes" you have in mind are?

For context...

While I agree with – what I understand to be – the sentiment underlying the statement above (changes bear costs and those costs should be considered), I think this approach minimizes the number of changes Senior Contributors could potentially need to navigate/cope with considering improvements to the discoverability of the Abonnieren/Abbestellen affordance will happen by way of topic containers (T269950) which people who have the topic subscriptions feature enabled need not use if they do not wish.

i. The decision to try topic subscriptions is "smaller" in so far as there are fewer things you need to consider: "Do I want to try out being able to receive notifications about new comments in specific sections?" rather than "Do I want to try out being able to receive notifications about new comments in specific sections and add a foreign to the page?"
ii. See: the text-only styling of the [ reply ] link and re-use of the page's existing New section link for the New Discussion Tool
iii. See: T249578, T255560, T267444, and T269950

To clarify the 2 changes:

-first someone will have to get used to the word subscribe in text form as well as the proximity
-second they will need to get used to the style and placement should we change/move the item

As I defer to you and @Whatamidoing-WMF about how the roll out strategy, I am alright with this being a first iteration.
Let's hold off on any additional treatment to the Watchlist page (directing Senior Contributors off the page for Topic Subscription notifications) until we validate through testing in T275232
Let's also hold on creating any kind of on-boarding or guided experience (blue dot tours) for this first prototype, and again we can validate through testing if there's a need. With regard to that, I've added a question T279164 is about how well junior contributors understand Edit vs. Subscribe as actions

Interestingly, I think that 2 is the most-complex one to implement, because those links are already meddled with by VE so we'll need to be careful to not trip over each other.

In T279149#6984916, @DLynch wrote:

...those links are already meddled with by VE so we'll need to be careful to not trip over each other.

@DLynch can you share more details about the above? What does "meddle" mean in this context?

In T279149#6992671, @ppelberg wrote:

In T279149#6984916, @DLynch wrote:

...those links are already meddled with by VE so we'll need to be careful to not trip over each other.

@DLynch can you share more details about the above? What does "meddle" mean in this context?

Change/modify/add-to

Change/modify/add-to

Yes, we already in VE's Javascript adjust the precise target of those links so that VE takes over. Depending on settings, we also create and add the "edit source" version of the link so there's not just "edit".

Mostly we'll be on talk namespace where VE is suppressed so there's only "edit source"... but since we can trigger DiscussionTools on non-talk-namespace, there'll be ways to have both running at once I assume.

Re: mobile web.

I *think* that the mobile version with this direction should look like:

Please leave high level feedback here and detailed feedback on the Figma file.

In T279149#7010093, @iamjessklein wrote:

Re: mobile web.

Per the conversation @iamjessklein and I had yesterday (20-April), we are going to finalize the mobile designs in a separate ticket. That ticket is: T280822.

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

[mediawiki/extensions/DiscussionTools@master] WIP Subscribe label buttons

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

@matmarex You've implemented it correctly in T280199 👏

In T279149#7047853, @iamjessklein wrote:

@matmarex You've implemented it correctly in T280199 👏

Is it possible to implement what is pictured in the task description's ===Mockups section?

Context: in T279149#6982355 we came to decide on the presenting the Abonnieren / Abbestellen affordance as text next to the existing section [ edit ] links.

Yes, but it hasn't been done yet. The patch I added above is an old one (from March), it just wasn't linked properly to this task.

I've looked into this a bit more and I'm no longer sure it's a good idea to re-use the section edit link area right now:

• It makes the subscribe feature harder to pick out on the page, and it is grouped in with a tool that performs a very different action (edit)
• There will be inconsistency across pages and headings:
  • On most talk pages where VE is disabled you will see [ edit | unsubscribe ]
  • On project pages with __NEWSECTIONLINK__ you may see [ edit | edit source | unsubscribe ]
  • Any heading lower than an h2 will only show [ edit ] oder [ edit | edit source ], making it harder to see quickly which sections are subscribe-able.
• Section edit links are configurable:
  • There's no user preference to disable them, but...
  • They can be disabled for a whole page using the __NOEDITSECTION__ magic word
    • It may be possible to work around this by recreating the section edit link group ourselves, and then just adding one link so you get [ unsubscribe ], but this feels hacky and flaky.

Revision to implementation
Per this today's team meeting, to start, the Abonnieren / Abbestellen affordance on desktop will:

• Be located on the right side of talk pages in LTR languages and on the left side of talk pages in RTL laguages
• Be styled to appear like all other link affordance on talk pages (e.g. [ reply ] / [ edit ] / [edit | edit source]

Change 685413 had a related patch set uploaded (by Esanders; author: Esanders):

[mediawiki/extensions/DiscussionTools@master] Subscribe/unsubscribe with plain text links

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

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/5c38ec39c4/w/

This works as expected @Esanders - in terms of looks, in order to match reply and edit "sufficiently plain" buttons it should have brackets.

I think bracket-less might be more plain than with brackets. Without brackets it looks like a prototype, with it looks like we consciously designed it to look like [ edit ] links?

While I default to @iamjessklein to make the final call here, my instinct [i] is to do what she proposed in T279149#7061602 and style the Abonnieren / Abbestellen links to be consistent with the [ reply ] links (read: encapsulate the links in brackets [ ]).

Thinking:

1. We are striving to present the Abonnieren / Abbestellen affordances in the way Senior Contributors will find to be most consistent with the way talk pages currently appear.
2. There are precedents for styling talk pages affordances with [i][ii] and without brackets [iii]
3. Considering "1." and "2." I default to the approach that's consistent with how the [ reply ] and [ edit ] links appear.

i. [ Add topic ] affordance on meta.wiki
ii. Section watchlist gadget's [ watch ] affordance
iii. fr.wiki's Ajouter un sujet affordance

Note: during today's team meeting, I expressed a preference for the "bracketless" approach. As the above indicates, I've since revised the approach I am leaning towards, albeit without strong conviction.

Test wiki created on Patch Demo by ESanders (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/c647283588/w/

Change 685413 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Subscribe/unsubscribe with plain text links

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

Change 674421 abandoned by Esanders:

[mediawiki/extensions/DiscussionTools@master] WIP Subscribe label OOUI buttons

Reason:

Using text labels for now - might be useful in the future.

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

Test wiki created on Patch Demo by JKlein (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/91bccd4c6b/w/

+1 looks good.

Test wiki on Patch Demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/5c38ec39c4/w/

Test wiki on Patch Demo by ESanders (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/c647283588/w/

Test wiki on Patch demo by JKlein (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/91bccd4c6b/w/