Talk:Talk pages project/Notifications

Jump to navigation Jump to search

About this board

Prototype: topic subscriptions

6
Summary by PPelberg (WMF)

T275232 contains the issues and opportunities for improvement that surfaced in this conversation. These same issues and opportunities have also been documented on the project page: Talk pages project/Notifications#Usability testing.

PPelberg (WMF) (talkcontribs)

An *in-progress* prototype of the new topic subscription feature is ready for you to try.

This prototype enables you to elect to receive a notification via Echo when someone posts a new comment in any conversation you have decided to "subscribe" to.

Below is information about:

  1. The goals of this prototype
  2. How to share feedback about the prototype
  3. How to try the prototype
  4. What will happen after you all share feedback
PPelberg (WMF) (talkcontribs)

1. Goals

The goal of sharing this prototype with you all at this stage is to learn:

  1. Which – if any – of the fundamental assumptions we've made about how the feature works conflicts with existing workflows/practices?
  2. What – if anything – do you think could be changed about how the feature currently works for it to improve your awareness of new comments in conversations you are interested in?

2. Sharing feedback

Once you have tried the prototype and you are ready to share what you think of it, please add a new topic to this talk page by doing the following:

  1. "Start a new topic" on this talk page
  2. Name this new topic: "Topic subscription prototype feedback: YOUR USERNAME"
  3. Write your answers to the "Feedback questions" below.
PPelberg (WMF) (talkcontribs)

3. Trying the prototype

  1. Visit this link on a desktop computer: https://patchdemo.wmflabs.org/wikis/77cda30f9d/wiki/Talk:Main_Page
  2. Create a new account (this is a test wiki, not a single-sign on wiki)
  3. Experiment with the feature by "subscribing" to a few conversations on this talk page and/or create a new talk page.

4. Feedback questions

Please answer the questions below when sharing feedback about the prototype.

  1. What did you find unexpected about how the prototype looks and functions?
  2. What do you appreciate about the prototype?
  3. What do you wish was different about the prototype?

5. Next steps

  1. We will compile the feedback you all share and post it to this page.
  2. Communicate when we will address the issues that surface
  3. Learn what people who are new to using talk pages think of the prototype
  4. Refine the prototype
PPelberg (WMF) (talkcontribs)

Update: there had been an issue that would have prevented you from trying the prototype. That issue should be resolved as of earlier today, 6-April.

Carn (talkcontribs)
PPelberg (WMF) (talkcontribs)

Thank you

@Dyolf77 (WMF), @Patriccck, @Pelagic, and @Sunpriat: we value the time and effort you all put in to trying the manual topic subscription prototype and sharing the feedback you had about it with us.

We've documented, and in some cases, acted upon the feedback you all shared in this Phabricator ticket T275232.

Reply to "Prototype: topic subscriptions"

Topic subscription prototype feedback: Pelagic (2)

4
Pelagic (talkcontribs)

First impressions (brain dump, apologies if this is a bit too stream-of-consciousness)[1]

  • Created account successfully.
  • Noticed that there are no "subscribe" links for my own talk page. (makes sense, after finding that they do appear elsewhere)
  • The talk for Nellie Bly appears to be at Talk:Main Page, but no biggie. (https://patchdemo.wmflabs.org/wikis/77cda30f9d/wiki/Talk:Main_Page)
  • Subscribe links are easy to notice.
  • Typographic style for Subscribe / Unsubscribe feels different from other elements, but F12 inspect-element tells me it's 14px Arial bold and body text is 14px Arial. Maybe because "Edit source" is smaller and not bold, and there are three styles on the same line? (shrug)
  • No objection to having Subscribe aligned-right on same line with the heading. (Is there a gadget or option on w:en that puts the edit links on the right? How would that interact?)
  • Tried page with useskin=timeless, think it actually looks better than vector (maybe the narrower column width, or maybe the way the different weights and styles of Segoe UI relate versus Arial).
  • I like how the text and mouseover colours are different for "Unsubscribe".Stands out subtly without being intrusive.
  • Instructions say "Write your answers to the questions listed in the "Sharing feedback" section below" but I couldn't find that section/post. (I feel like I'm doing it wrong, but scroll around and can't see it.)
  • Fired up an in-private browser and posted anon (which I feel okay about because the 172.16.x.x address doesn't expose my home IP as discussed previously elsewhere, and the preview shows my username as a 172.16 for reassurance)
  • Switched back to first window, now it says logged out but, whatever, logged back in. 3 notices. Welcome to PatchDemo, we're glad you're here. You just made your first edit; thank you, and welcome. [IP] replied in "Moving article". Clicked the third (top) tile/item/whatever you want to call it. Noticed that it not only took me to the section but scrolled down to near the reply (?). Clicked back on Notices and see that the item is marked as read but still visible. Does prod Echo do that? Maybe it seems different because I normally have too many unreads.
  • Switch back to anon window. notice that as a not-logged-in IP user I still see "Subscribe" links, and they are wrapped to the next line. Subscribe to see what will happen.
  • Reply to unwatched topic (i.e. anon replies to topic not watched by Pelagic). Check back with notices and I did get a notification for an unwatched topic (unexpected). The page now says I'm subscribed (also unexpected). Did I mess up, or was there some weird interaction between the logged-in browser and the in-private not-logged-in browser?
  • Time to take a break for now. There are some limitations to testing with two browser sessions on the same computer and IP.
  • But I can't let it go. Back to anon window, refresh page, Subscribe links have disappeared. Doubting my sanity now, wish I'd taken a screenshot. Check that I'm definitely not subscribed to "Remarkable translation effort". Post anon reply (172.16.0.164). Go back to logged-in window and refresh. No notifications, that's better.
  • Check watchlist. Nothing much there. That's expected based on previous discussions I've seen which indicate this would involve Echo notifications not Watchlist entries. Good for me; I don't work my watchlist much, but others work differently.

Overall: generally works; a little weirdness, but probably hard to replicate that. Sorry if too much detail, but instead of paying testers to record their narration on usertesting.com I can channel the underworld for free...

Question: How can I see all the topics that I'm subscribed to and manage them? Do I need to wait 'til I get a notification then click through and unsubscribe from there?

PPelberg (WMF) (talkcontribs)

First impressions (brain dump, apologies if this is a bit too stream-of-consciousness)[1]

@Pelagic, this is great. Comments and questions in response to what you've shared below...

Follow up questions for you

Noticed that there are no "subscribe" links for my own talk page. (makes sense, after finding that they do appear elsewhere)

Can you share what leads you to think "subscribe" likes NOT appearing on your own user talk page "makes sense"?

Reason I ask: we made a couple of assumptions when deciding on this behavior and so we're curious about how those assumptions compare with what you intuitively thought.


Typographic style for Subscribe / Unsubscribe feels different from other elements, but F12 inspect-element tells me it's 14px Arial bold and body text is 14px Arial. Maybe because "Edit source" is smaller and not bold, and there are three styles on the same line? (shrug)

Good spot. What do you think about this updated design that, we intend, to be more consistent from other elements on the page?


No objection to having Subscribe aligned-right on same line with the heading. (Is there a gadget or option on w:en that puts the edit links on the right? How would that interact?)

Can you share a link to the gadget you have in mind?

Note: I wonder whether this potential conflict is "moot" considering how we're planning for the Subscribe/Unsubscribe affordances to now be adjacent to the edit links that appear immediately next to section headings. See the updated design for reference.


Reply to unwatched topic (i.e. anon replies to topic not watched by Pelagic). Check back with notices and I did get a notification for an unwatched topic (unexpected). The page now says I'm subscribed (also unexpected). Did I mess up, or was there some weird interaction between the logged-in browser and the in-private not-logged-in browser?

This sounds unexpected. Before filing a ticket for this, can you please confirm the steps below describe what you experienced?

  1. Open two browser windows.
  2. In one browser window, you are logged in as User:Pelagic. In the other browser window, you are NOT logged in.
  3. In the private browser window where you are NOT logged in, you posted a comment (call it "Comment 1") to "Topic A" (made up name)
  4. ❗️ In the browser window where you are logged in as User:Pelagic, you receive a notification via Echo for "Comment 1" in "Topic A" despite User:Pelagic NOT having been subscribed to "Topic A"
  5. ✅ In the browser window where you are logged in as User:Pelagic, you reload the talk page "Topic A" appears on and notice you are now "Unsubscribed" to "Topic A"

Comments

Instructions say "Write your answers to the questions listed in the "Sharing feedback" section below" but I couldn't find that section/post. (I feel like I'm doing it wrong, but scroll around and can't see it.)

You are NOT doing it wrong :) This was a mistake I made and one @Patriccck just pointed out to me as well.

Hopefully it's fixed now. See "2. Sharing feedback > 3. Write your answers to the 'Feedback questions' below."


Clicked back on Notices and see that the item is marked as read but still visible. Does prod Echo do that?

If by "still visible" you mean the below, then I think production Echo behaves this way as well.

  1. Click the "Notice" (📥) icon
  2. See the notification you clicked sometime before "Step 1" appears within the dropdown with a gray background

Question: How can I see all the topics that I'm subscribed to and manage them? Do I need to wait 'til I get a notification then click through and unsubscribe from there?

For now, it is not possible to see all the topics you are subscribed to. With this said, it is something we are thinking about introducing (see phab:T273342).

If you have ideas for what questions you would expect this view to help you answer and what actions you would expect it to allow you to take, we'd be keen to hear them!

Pelagic (talkcontribs)
  • Can’t subscribe on my own talk page makes sense because I already get alerts for posts on my talk page. Though there are other ways this could be done, e.g. one type of alert for new section/topic + a different alert for a reply + topics are subscribed by default and you get a link to unsubscribe. Would people want to unsubscribe from topics on their own talk when they could simply delete or archive them instead? Now I wonder, for other talk pages (not my own): would I want to watch the whole page but unsubscribe from specific topics? Should there be a subscribe-all link?
    • I agree with what you wrote at T276996#6909778, still reading the rest of the ticket/task.
  • (Un)subscribe link style and position Both have their merits. I really appreciate all the work Jess is doing with iterating over designs and testing. On the one hand, it's logical having the actions "edit | unsubscribe" together. On the other, having the links on the right, with different colours for subscribe/unsubscribe allows me to scan the page and see which topics are subscribed. That's less applicable where not all discussions are short, though. I suspect people may find the new design more natural, but not sure how you can get more opinions. Have you considered a ⭐️ marker to the left of the section heading, or some indicator in the ToC?
  • Gadget for edit links on right found it at English Wikipedia – Preferences – Gadgets – Appearance – Move section [edit] links to the right side of the screen. Haven't tried it myself, and I don’t know if it's installed on other wikis.
  • Notice for unwatched topic I'll retry and let you know. Rereading what I wrote, looks like I couldn't reproduce it at the time.
  • Read but still visible yes, you’re right. With a small screen and on a wiki where I have a lot of unreads, the read items are scrolled offscreen. Was just more noticeable when there are only a few items in the list, and the newly-read item didn’t change position.
PPelberg (WMF) (talkcontribs)

I'm sorry for the belated response, @Pelagic; comments below...


Can’t subscribe on my own talk page makes sense → because I already get alerts for posts on my talk page

Understood. It's helpful to see how this assumptions we've made line up with what you instinctively thought.

Should there be a subscribe-all link?

We share this question and so too does @Patriccck; I've added this to the "Issues" table in T275232's task description.

(Un)subscribe link style and position → Both have their merits. I really appreciate all the work Jess is doing with iterating over designs and testing.

@JKlein (WMF) will be glad to hear this ^ _ ^

On the one hand, it's logical having the actions "edit | unsubscribe" together. On the other, having the links on the right, with different colours for subscribe/unsubscribe allows me to scan the page and see which topics are subscribed. That's less applicable where not all discussions are short, though. I suspect people may find the new design more natural, but not sure how you can get more opinions.

These are the trade offs that have come to mind for us as well. Since I posted last, we decided for the Subscribe/Unsubscribe affordance to be located on the right side of the page [in LTR languages]. You can find the thinking that influenced this approach in T279149#7064405.


Have you considered a ⭐️ marker to the left of the section heading, or some indicator in the ToC?

We did consider the "⭐️" marker and ultimately decided against reusing so as not to lead people into mistakenly thinking "Watching" and "Subscribing" are currently related. The thinking behind the decision to treat these features as discrete, for now, can be found in T279498.

Gadget for edit links on right → found it at English Wikipedia – Preferences – Gadgets – Appearance – Move section [edit] links to the right side of the screen

Thank you for pointing this out – you sharing this gadget is the first I've heard of it.

By the way: are you aware of an easy way to see how popular a gadget is across projects?

I'm aware of Special:GadgetUsage, although based on what I currently know, I assume that to do the above I'd need to visit each project individually...

Notice for unwatched topic → I'll retry and let you know. Rereading what I wrote, looks like I couldn't reproduce it at the time.

Understood – thank you.

Read but still visible → yes, you’re right. With a small screen and on a wiki where I have a lot of unreads, the read items are scrolled offscreen. Was just more noticeable when there are only a few items in the list, and the newly-read item didn’t change position.

Mmm, I see. Even still, would it be accurate for me to understand part of what you're saying above as: "It can be difficult to differentiate between notifications you have and have not read within Echo's dropdown?"

Reply to "Topic subscription prototype feedback: Pelagic (2)"

Topic subscription prototype feedback: Sunpriat

6
Sunpriat (talkcontribs)

notes before the test

  • If there are a lot of notifications, they will spam the list and it will be more difficult to pay attention to something important, users will simply be afraid to use it, the list needs to merge its elements.
  • I saw something like this in the Flow. Didn't look very helpful. Probably I would like to know from "when" the answers begin (date, how old the messages are there) just by looking at the merging notification.
  • Users need rules so they can read them and know when notifications are triggered. To know how to proceed so that the notification is guaranteed and why (or how to do it if you need it) is not sent. (like a Manual:Reverts#Conditions for execution)

after the test

  • Pressed subscribe, pressed spacebar to scroll down the text screen, unsubscribe occurred. The focus remained on the button. If you click on the star for adding to the watchlist, then when you press the spacebar, the star will not be activated again as an unwatch - it has no focus. Should work the same as the watchlist star.
  • It is unusual to see the line not all the way to the right edge. This is some kind of gap in the border and the topics begin to merge, connect (it looks like a wikipedia:Template:Outdent for moving a comment thread, there is also an incomplete line). The line must be full width in order to be guaranteed to split for dosing information.
  • When commenting with a participant's notification (@), the notification appears in a different (left) notification icon (some did not understand the need to separate notifications before. Now notifications look of the same type but appear under different icons - this is a bit difficult). If you click on the notification (@), it goes to the section heading. It was expected that it will also scroll further down to the comment (scroll from new notifications is more convenient).
  • I was afraid that the list would be spammed unread, but everything turned out to be grouped. But when it was marked as read, now the list was spammed with the read. It was expected that what was marked as read would also group or disappear.
  • And if you are subscribed to several topics, then, after being marked as read, the list is a complete mess of other people's nicknames, as if there is someone's chat. There is no "you" in the text of notifications, so they look like a completely alien mini-chat.
  • When I click on the notification, it scrolls immediately to the comment, but at the same time the line of the previous comment is visible, and if there is such a short comment, then it seems that this is for the above comment - this can be confusing. In the Flow, the border on the left was highlighted in color after opening from notifications and it was immediately clear to which comment I went. It may be better for the comment to be immediately the first line at the beginning (top) of the screen.
  • The discussion goes from top to bottom. Notifications go from bottom to top. In a collapsed group, I would like to see the natural order from top to bottom. This is confusing when you see the beginning of the lines and read/view them upside down, but they are in fact in the opposite order.
  • I made a subsection in the topic and did not receive a notification. https://patchdemo.wmflabs.org/wikis/77cda30f9d/w/index.php?title=Talk:Citation_needed_example&diff=prev&oldid=91 If someone summarizes the topic, then I will not know about it.
  • And there are no signature buttons for the subsection, notifications from the subsection are not received.
  • Someone previously expressed a desire to receive notifications from replies to their replies. That is, for example, the ability to filter notifications only if the (::, :::)replies are deeper in the thread of your (:)reply, and other people's (:)threads are less interesting.
PPelberg (WMF) (talkcontribs)

@Sunpriat we appreciate you taking the time to try out the prototype and document the thoughts in brought to mind.

Below are responses to the first half of the comments you shared. Later this week, I am going to comment again with responses to the second half of the comments you shared...

Follow up questions for you

1. Probably I would like to know from "when" the answers begin (date, how old the messages are there) just by looking at the merging notification.

What is "...the merging notification." you are referring to above?


2. It is unusual to see the line not all the way to the right edge...This is some kind of gap in the border and the topics begin to merge, connect...

Noted. I've documented this issue in phab:275232.

In the meantime, can you share a bit more detail about what you mean by the topics merging? Are you suggesting that it's difficult to tell sections apart without the topic borderline extending all the way?


3. When commenting with a participant's notification (@), the notification appears in a different (left) notification icon (some did not understand the need to separate notifications before. Now notifications look of the same type but appear under different icons - this is a bit difficult)

I want to make sure I am accurately understanding what you are saying above. Are you saying that you find it confusing/unintuitive that notifications can appear in two places depending what kind of notifications they are? For example, if you are "pinged," you will see it appear in the "🔔" icon (the software refers to these as "alerts") whereas if a new comment is posted in a section you are subscribed to, it will appear in the "📥" icon (the software refers to these as "notices")?


4. If you click on the notification (@), it goes to the section heading. It was expected that it will also scroll further down to the comment (scroll from new notifications is more convenient).

Can you please read phab:T253082 and let me know whether that ticket describes the functionality you are describing above?

Comments in response to things you shared

5. Users need rules so they can read them and know when notifications are triggered. To know how to proceed so that the notification is guaranteed and why (or how to do it if you need it) is not sent.

We agree, people who are curious need to be able to read how the feature works. We will, most likely, document this information on the Talk pages project/Feature summary page.


6. Pressed subscribe, pressed spacebar to scroll down the text screen, unsubscribe occurred.

Good catch. I've documented this issue in phab:275232.

Sunpriat (talkcontribs)

@PPelberg (WMF) 1. When there are several messages from the same topic, they are shown as one message (group) (when you click on which a drop-down list with all messages appears), they are combined into one logical flow or as a node in a mindmap. Visually merged into a coherent dialogue. It can be a dumb button "unfold me" or a slightly smart button somehow useful itself summarizing its content into itself.

2. When the line is at its full length, when viewed from top to bottom - oh, here is the line, then this is the end, everything is simple. The new Vector has a fixed width and a lot of white space on the left and right (1920x1080). I look from top to bottom - there is no line in the right half of the screen, on the right side these topics are visually united, connect and continue each other, I have to look further along the left side, additionally compare the top topic and the bottom topic and the line between them - this takes a little more time and unnecessary actions.

3. Perhaps in English the difference in words is more understandable, perhaps the situation is worsened by a less distinguishable translation, as very similar synonyms. Imagine that instead of alerts|notices there is the same word (or there are no words, only icons bell|tray) notifications|notifications, and here it is difficult for many to understand how what comes to the first list differs from the second.
I subscribed to the topic, I receive mini-messages in the right list, then the user pinged me, a message appeared in the left list under the bell, but there is no message in the right, as if he pinged from the topic without my subscription. Everything related to the topic was transferred to the right stack in one place, then a part strongly related to the topic appeared in the left stack, while nothing new appeared in the right stack, and then there is a feeling that something went wrong, that there was a sorting error, that something was lost and did not come to the right stack.
I was expecting something to appear in the right column. I understand that displaying +1 at the bell and +1 at the tray at the same time would be a visual overflow. It can be +1 at the bell and 0 at the tray. But an element should appear in the right column - this shows that the message appeared in the subscribed topic, and, for example, this element has an additional icon bell icon that it was with a ping (it is immediately clear that the +1 was sent to the left column instead and nothing was missing in the right column, no missed incoming messages).

4. Almost, but here with the requirement/clarification that the user experience should not differ. I expect to see the message in exactly the same place on the screen and start reading it in the same place on the screen as when I click on the messages from the subscribed topics from the right column.

5. Sometimes users ask in the wiki forum / in discussions why the ping of another participant did not work, why some tag was not set for editing - except for curiosity, this is the need to send them to read somewhere via a link or to provide a qualified answer.

PPelberg (WMF) (talkcontribs)

1. When there are several messages from the same topic, they are shown as one message (group) (when you click on which a drop-down list with all messages appears), they are combined into one logical flow or as a node in a mindmap. Visually merged into a coherent dialogue. It can be a dumb button "unfold me" or a slightly smart button somehow useful itself summarizing its content into itself.

Ah, now [I think] I know what you are referring to (see this screenshot)! Assuming I am understanding what you are describing above accurately, I think we have implemented the "merging" functionality you are referring to in phab:T275949.

Here's how it works right now:

  1. When you have notifications for multiple comments from the same "topic," you will see them merged/grouped into one item within Echo that you can expand.
  2. That "one item" will show you: i) the number of comments you are being notified about, ii) the title of the topic in which they were posted and, iii) the username of the person who posted the most recent comment.
  3. You can open the "one item" to see all of the notifications contained within it by clicking the "expand" icon. You can see what the icon looks like by visiting this page and searching for the word "expand".

Please let me know if anything above prompts new questions and/or does not match up with what you would expect.


2. When the line is at its full length, when viewed from top to bottom - oh, here is the line, then this is the end, everything is simple. The new Vector has a fixed width and a lot of white space on the left and right (1920x1080). I look from top to bottom - there is no line in the right half of the screen, on the right side these topics are visually united, connect and continue each other, I have to look further along the left side, additionally compare the top topic and the bottom topic and the line between them - this takes a little more time and unnecessary actions.

I see. Thank you for explaining this in more detail. We've adjusted the prototype so that the horizontal line that runs underneath ==H2== sections is not interrupted by the Subscribe/Unsubscribe link. I think this addresses the issue you were referring to, but if not, please let me know.


3. Perhaps in English the difference in words is more understandable, perhaps the situation is worsened by a less distinguishable translation, as very similar synonyms. Imagine that instead of alerts|notices there is the same word (or there are no words, only icons bell|tray) notifications|notifications, and here it is difficult for many to understand how what comes to the first list differs from the second...

You described this in a wonderfully vivid way. While I think the sorting issue you are describing above is out of scope for this particular project, here is the ticket in Phabricator where this issue is being tracked so we do not lose sight of it: T142981.

We'd value you commenting on that ticket if you think there are important details that are missing.

4. Almost, but here with the requirement/clarification that the user experience should not differ. I expect to see the message in exactly the same place on the screen and start reading it in the same place on the screen as when I click on the messages from the subscribed topics from the right column.

You want to be taken to the precise location on the page where the content you are being notified about exists, regardless of what kind of content it is...understood.

Here is a ticket where we can track the work involved with implemented this: phab:T282029.

5. Sometimes users ask in the wiki forum / in discussions why the ping of another participant did not work, why some tag was not set for editing - except for curiosity, this is the need to send them to read somewhere via a link or to provide a qualified answer.

Are you able to share what "did not work" means in this context?

Are the people you referring to talking about pinging someone and that person not responding? Are they talking about pinging someone and doubting whether the person they are pinging was actually notified? Something else?

Sunpriat (talkcontribs)

@PPelberg (WMF) 1. Yes, it's about a bundle. But the key point was in "from when". A similar flow-notification-reply-bundle was in Notifications/Message audit (2014), after adding the "subscribe" function it was rewritten to https://translatewiki.net/w/i.php?title=MediaWiki:Flow-notification-reply-bundle/qqq . There was also "x replied in y topic. last time". Comments can be imagined as hot (new) and cold (old). The bundle always shows the hot end of the queue and this provokes quick but harsh responses. Often you need to answer after thinking for a while, but not too long. Or to see the date of the oldest message in order to understand the time interval of the "reader's debt".

3. The key point was that notifications from one topic are strongly logically connected, and appearing in another column breaks this connection. Importance qualifier lost. The topic I subscribed to is important to me. But the ping notification remains similar to all other pings. I expected the connectivity to be preserved, for example, the text "you are subscribed to this topic" or the star icon appears in the ping notification, so that this ping stands out from the rest as more important to me.

5. "and doubting whether" e.g. Q: I updated the comment, but why hasn't the notification been sent? A: you must write both nickname and signature Help:Notifications/Types#Mentions Q: but I added both a nickname and a fresh signature A: you should do it on a new line Manual:Echo

PPelberg (WMF) (talkcontribs)

Yes, it's about a bundle. But the key point was in "from when"...Often you need to answer after thinking for a while, but not too long. Or to see the date of the oldest message in order to understand the time interval of the "reader's debt".

@Sunpriat: can you share how you would expect the notification bundling to work? I ask this wondering whether you describing this will help me to more fully understand the issue you are referring to above.


...the text "you are subscribed to this topic" or the star icon appears in the ping notification, so that this ping stands out from the rest as more important to me.

Ah, I see. I've filed a ticket for what you are describing here: T283302.

Please comment on the ticket if you think it ought to be adjusted in any way.


"and doubting whether" e.g. Q: I updated the comment, but why hasn't the notification been sent? A: you must write both nickname and signature Help:Notifications/Types#Mentions Q: but I added both a nickname and a fresh signature A: you should do it on a new line Manual:Echo

These example questions are helpful; thank you for sharing them.

Would it be accurate for me to understand you as saying that there is a need for a single place to be able to direct people to where they can understand what is required for a ping to be sent successfully?


By the way: I appreciate how patient you have been in engaging with the follow up questions I've asked.

Reply to "Topic subscription prototype feedback: Sunpriat"

Topic subscription prototype feedback: Patrik L.

5
Patrik L. (talkcontribs)
  1. What did you find unexpected about how the prototype looks and functions?
    I think that this new tool should notify me when is there any edit in the section. Some examples: When someone adds this template and do not reply, I want to know it. When someone adds a sub-section, I also want to know it.
  2. What do you appreciate about the prototype?
    I like that I'm noticed immediately (instead of listing in watchlist that is a little bit disorganized and fussy - at least mine).
  3. What do you wish was different about the prototype?
    There are some talk pages that I want to subscribe all. For example, if I can watch AN at cswiki, I can take action against vandals very fast. But this needs function described at point one.
PPelberg (WMF) (talkcontribs)

Thank you for trying out the prototype and sharing the thoughts it brought to mind, @Patrik L. A couple of follow up questions for you below...


I think that this new tool should notify me when is there any edit in the section. Some examples: When someone adds this template and do not reply, I want to know it. When someone adds a sub-section, I also want to know it.

Can you share what led you to suggest the above? Asked another way: what do you worry will happen if the topic subscription feature is NOT adjusted to allow you to be notified whenever an edit, no matter its size/type, is made to a section you are subscribed to?

There are some talk pages that I want to subscribe all. For example, if I can watch AN at cswiki, I can take action against vandals very fast. But this needs function described at point one.

In describing the above, were you thinking about being able to subscribe to all of the existing conversations on a given page? Being able to subscribe to all new conversations that are started on a given page? Something else?

Patrik L. (talkcontribs)

Can you share what led you to suggest the above? Asked another way: what do you worry will happen if the topic subscription feature is NOT adjusted to allow you to be notified whenever an edit, no matter its size/type, is made to a section you are subscribed to?

Hmm, good question. I think that minor edits like grammar or spelling fixes should not be supported by the topic subscription feature. But edits like adding template about the task at Phabricator are important, I think.

In describing the above, were you thinking about being able to subscribe to all of the existing conversations on a given page? Being able to subscribe to all new conversations that are started on a given page? Something else?

I wondered about being able to subscribe all new conversations that are started on a given page using a special button.

PPelberg (WMF) (talkcontribs)

Hmm, good question. I think that minor edits like grammar or spelling fixes should not be supported by the topic subscription feature. But edits like adding template about the task at Phabricator are important, I think.

I see. So it sounds like what you are describing is a desire for being able to customize/configure the activity you are and are NOT notified about when you subscribe to a section.

Please let me know if I've understood this in a way that is different from how intended it.

In the meantime, I've noted this issue in phab:275232.

I wondered about being able to subscribe all new conversations that are started on a given page using a special button.

Understood. I've noted this issue in phab:275232.


...thank you, @Patrik L.!

Patrik L. (talkcontribs)

Yes, you understood all that I wrote right. Happy to help. :)

Reply to "Topic subscription prototype feedback: Patrik L."

Topic subscription prototype feedback: Habib

4
Dyolf77 (WMF) (talkcontribs)

I tried the prototype and these are my two comments about it:

  • Can users select to add/not add the talk page to their watchlist? For example in a talkpage I want to subscribe to a topic but don't want to watch the page. It could be an option when subscribing: "Do you want to add this page to your watchlist?".
  • Is it possible to add other users to the topic (subscribing them, and they may accept or refuse). It is a bit delicate, but sometimes we want a potential user to subscribe to some topics.
PPelberg (WMF) (talkcontribs)

We appreciate you giving the prototype a try, @Dyolf77 (WMF). Comments and questions in response below...

Follow up questions for you

Can users select to add/not add the talk page to their watchlist? For example in a talkpage I want to subscribe to a topic but don't want to watch the page. It could be an option when subscribing: "Do you want to add this page to your watchlist?".

At the moment, "Subscribing" and "Unsubscribing" from topics and "Watching" / "Unwatching" pages are unrelated. The thinking for how we arrived at this initial decision can be found in the "Open questions" section of T279498's task description.

With the above said, can you share how you intuitively thought topic subscriptions and the watchlist would/would not relate?

Is it possible to add other users to the topic (subscribing them, and they may accept or refuse). It is a bit delicate, but sometimes we want a potential user to subscribe to some topics.

This is a great question. Currently, it is NOT possible for you to subscribe or unsubscribe another person to/from a topic.

Can you share what led you to ask this question?

Dyolf77 (WMF) (talkcontribs)

Thanks @PPelberg (WMF), these are my answers to your questions:

With the above said, can you share how you intuitively thought topic subscriptions and the watchlist would/would not relate?

>> When a user finds an interseting topic to subscribe to, probably they were watching the page. I thought if they found a topic, certainly they don't visit pages or discussions randomly, they must be following these pages. In another case they can be pinged in a discussion in a page they don't watch, so, they want to follow to watch all the page when they subscribe.

Can you share what led you to ask this question?

>> When a topic is relevant for more than one user. For example, this user is working with a group on a common project, while pinging these other users is the "normal" practise, they can subscribe them to the topic. This way, they are updated with comment/feedback/questions.

PPelberg (WMF) (talkcontribs)

>> When a user finds an interseting topic to subscribe to, probably they were watching the page. I thought if they found a topic, certainly they don't visit pages or discussions randomly, they must be following these pages. In another case they can be pinged in a discussion in a page they don't watch, so, they want to follow to watch all the page when they subscribe.

I appreciate you sharing how you are thinking about the relationship between the Watchlist and Topic Subscriptions, @Dyolf77 (WMF). I'd like to make sure I'm accurately understanding what you shared above and ask you two questions based on that understanding:

  1. "People are most likely to discover topics worth subscribing to by way of their watchlist." Assuming I've understood this correctly, what do you think are the implications of this?
  2. "When someone is pinged on a page they are not already watching, upon landing on that page, they are likely to want to follow (read: watch) the entire page when they go to "subscribe" to the topic in which they have been pinged. Assuming I've understood this correctly, are you suggesting "Watching" and "Subscribing" being treated as separate actions will cause extra work for people?

>> When a topic is relevant for more than one user. For example, this user is working with a group on a common project, while pinging these other users is the "normal" practise, they can subscribe them to the topic. This way, they are updated with comment/feedback/questions.

Ah, okay. I understand this more clearly now...thank you for explaining this. I understand what you are suggesting here as: one possible way of increasing the likelihood people are made aware of comments that are relevant to them is by enabling other people to subscribe them to conversations.

We are going to revisit this general idea as part of the next iteration of the topic subscription feature. In this next iteration, we are planning to introduce a way for people to automatically become subscribed to conversations they participate in and/or start. More context in phab:T263819.

As it relates to the specific idea you proposed about offering people the option to subscribe others to conversations: I'd worry this could lead people to A) become inundated with notifications they did not elect to receive and B) become vulnerable to abuse/harassment.

Reply to "Topic subscription prototype feedback: Habib"

Topic subscription prototype feedback: Pelagic (try 1)

4
Summary by Pelagic

Problem fixed, root cause bypassed. (Matmarex added a switch to skip MD5 check on glitchy SFS data that was affecting account creation on PatchDemo). phab:T279395, phab:T279449

Pelagic (talkcontribs)

Currently, when I try to create an account, I get:

... RuntimeException: SFS IP file contents and file md5 do not match!

Backtrace:

from /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(222)
#0 /srv/patchdemo-wikis/77cda30f9d/w/extensions/StopForumSpam/includes/DenyListUpdate.php(86): MediaWiki\StopForumSpam\DenyListUpdate::fetchDenyListIPsRemote()
...
PPelberg (WMF) (talkcontribs)
PPelberg (WMF) (talkcontribs)

@Pelagic are you able to try creating a new account with the prototype once more and comment here whether you are able to do so successfully?

...we think we've resolved the issue that was causing you to see the error above.

Pelagic (talkcontribs)

Yep, works now, thanks @PPelberg (WMF)! I've commented at the Phab ticket also, to the same effect.

First feature: subscribing to topics

41
Summary by PPelberg (WMF)

T275949: Implement topic subscription notification bundling

T275943: Add support for subsection subscriptions

T275881: Don't search for signatures in blockquote elements

T275260: Enabled people to write custom rules for what activity they are notified about

T274215#6845061: Consequences that could emerge when people are able to be more specific about the activity they are and are not made aware of.

T273342: Introduce a way to view all of the topics you are subscribed to

T276990: Ensure duplicate notifications are *not* sent for the same talk page event

PPelberg (WMF) (talkcontribs)

Last week, we shared the first new notification feature we will be working on is a way for people to elect to be notified when another person adds a new comment in a specific talk page topic (read: section).

The question we have for you all is: What do you think is important for us to consider as we begin designing and implementing this feature?


Note: you can see more of the details of how we are thinking about implementing this feature in this ticket on Phabricator: T263820.

PPelberg (WMF) (talkcontribs)

The idea of being able to more precisely follow particular talk page sections has come up many times over the years.1234

Accordingly, I'm going to tag *some* of the people who have participated in those conversations who we think will have valuable insight to share as the Editing Team begins designing and implementing this functionality:

@Sdkb, @Vriullop, @Mihia, @Another Believer, @Enterprisey, @Xneb20, @Jack who built the house, @Rjclaudio, @Timeshifter, @Drcrazy102, and @Pokéfan95.


---

1. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2016/Categories/Watchlists#CW2016-R043

2. https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2015/Watchlists#Section_watchlists

3. https://en.wikipedia.org/wiki/User:Enterprisey/section-watchlist.js

4. https://commons.wikimedia.org/wiki/User:Jack_who_built_the_house/Convenient_Discussions

Sdkb (talkcontribs)

Hmm, since it seems like a pretty straightforward feature (on the user end), I'm not sure I have too many thoughts about considerations to have in mind. The main thing is just building something that works, and that doesn't malfunction in edge cases.

Something that's always good to have in mind is how a technical change might affect editorial culture. On the whole, section watchlisting will be massively convenient, which will make it easier to curate watchlists that reflect what I actually care about. But not getting notified about other discussions on a page I'm monitoring for my own thread might mean slightly less branching out, and fewer replies to threads in some areas. It could also introduce new avenues for abuse, such as someone starting a new section on the same topic because they suspect an opponent is only monitoring the original section and don't want them to notice and reply.

Talk page sections can be fluid, where sometimes they'll be created in a discussion that's already well under way, or sometimes threads on the same topic will be merged. You'll want to make sure section watchlisting can handle this.

This might be a little overly fancy, but sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria. For instance, at ITN nominations, some editors might want to only watchlist sections that are not recent deaths, so it'd be really powerful to be able to tell the software "watchlist new sections here if they don't contain |recent death = yes". Or maybe someone put together a photo collage for an article, so they'd want to watchlist new sections for that article with the word collage so they could engage with anyone making suggested changes.

On a more basic level, being able to watchlist pages but not their talk pages is something that I definitely hope gets added with this. Being able to monitor the Teahouse talk page without having my watchlist become a torrent of questions would be very nice.

PPelberg (WMF) (talkcontribs)

Thank you for taking the time to share what comes to mind, @Sdkb. A couple of things you said prompted new thoughts and questions. I'm going to quote and reply to each below.

Before that, I wanted to clarify: as we are currently designing it, the new feature we are working on will *not* affect the way the Watchlist functions. Instead, it will introduce a new event for which people can receive notifications about via Echo. If this information brings new thoughts to mind, I'd be keen to hear them. In the meantime, I'm going to respond to the points you raised...

Something that's always good to have in mind is how a technical change might affect editorial culture....not getting notified about other discussions on a page I'm monitoring for my own thread might mean slightly less branching out, and fewer replies to threads in some areas.

Accounting for the unintended consequences increased specificity could have is a great point. I've made a note of this on Phabricator here so we can think through how we might monitor/evaluate the extent to which what you are describing above is happening: T274215#6845061.

One loose idea/metric we could use to track the move: "Of the pages on which people are subscribed to at least one section, how many of those pages do people also have on their watchlists?" <-- if other ideas strike you, please comment them.

It could also introduce new avenues for abuse, such as someone starting a new section on the same topic because they suspect an opponent is only monitoring the original section and don't want them to notice and reply.

Another a good thought. I've also documented this on Phabricator here: T274215#6845061.

Talk page sections can be fluid, where sometimes they'll be created in a discussion that's already well under way, or sometimes threads on the same topic will be merged.

Can you describe this scenario in a bit more detail? Or better yet, link to a page/diff where you've seen what you're describing happen?

This might be a little overly fancy, but sometimes, there are pages where I might want to pay attention only to future sections that meet or exclude particular criteria.

This idea of enabling editors to be able to write custom rules for the kinds of activity they are and are not notified about strikes me as something that could be, as you said, quite "powerful." While it is outside of the scope for what we are able to take on as part of this project, I've created this ticket in Phabricator so we don't lose sight of it: T275260.

Sdkb (talkcontribs)
Whatamidoing (WMF) (talkcontribs)
Jack who built the house (talkcontribs)

May I ask how deep a level will the implementation of this feature go? Will there be some backend that will keep data related to sections (sections themselves, not subscriptions, not notifications)?

Because, you know, the biggest issue with watching sections on wikis is that there are absolutely fluid; it's extremely hard to come up with a general solution to tell if two sections as of different revisions, possibly on different pages, are the same section. There can be two sections with the same name on one page, and there can be a section same as some other section on this/other page, but named differently (renamed/moved/archived). If a section is moved to a different page, will it be able to trigger notifications for users who subscribed to it on a different page? That could require backend support.

(Actually, in the respect that sections are fluid, comments are not much different, and I believe @Matma Rex would give you a full insight on that, so I'm not at all sure that conceptually/practically it would make sense to keep such a registry, since if we wanted topics/comments to be perfectly encapsulated and kept in the database in a 1-to-1 fashion, we would reinvent Structured Discussions.)

I can say that in Convenient Discussions, there is a method dedicated to searching for sections on the current page. It uses a number of factors with different weights that add up to a score that should be above a certain threshold:

  • headline
  • anchor (id)
  • ancestor chain
  • first comment's anchor (id) (date + author + index)
  • index on the page (lowest weight)

(This method is used to match sections as of different revisions on the same page in order to notify the user while they have the page open, Convenient Discussions doesn't use it for watching purposes, as there is too much data to keep, and the script currently doesn't rely on any external databases.)

The section's headline may change for obvious reasons, just as the index and the id (but these would help if there are absolutely identical sections on the page, which is sometimes the case with bot-created sections). The first comment's anchor may change because the user edited the comment and added another timestamp or if a bot added its comment under the section's headline (this often happens in Russian Wikipedia, for example) or if there is another comment with the same timestamp on the page. Ancestor chain, which uses headlines, may also change, but is extremely helpful to tell between subsections with the same name.

If too many parameters of a section are altered, we could lose track of it, but also could rightfully ask, should we consider it the same section after all (see Ship of Theseus).

Matma Rex (talkcontribs)

On the fluidity of sections

We plan to identify sections by their anchor and the timestamp of the oldest comment in the section. We're using the oldest comment instead of the first for exactly the reasons you outlined.

The subscription will not depend on the page on which the section is, so it will trigger notifications even if it's moved to another page, or if it's transcluded from another page in the first place.

When two or more sections have identical anchors and timestamps, subscribing to one of them will subscribe you to them all. We expect that to be very rare.

We will parse every edit to detect sections being renamed (this will work together with the code that will parse every edit to detect new comments and send notifications), and update your subscriptions to point to the new name when it happens.

When a section is renamed in some messy way, we might lose track of it still, but at least we'll be able to tell that is has disappeared and maybe send a notification about this or something. We haven't figured out the details yet.

On a registry / database of topics and comments

We're not doing this right now, but we have some vague ideas about a backend structure that would track each comment and section, and allow us to have permanent links that would point to the latest version of the comment/section even if they're archived or deleted. These could be used for sections in your list of subscriptions to find out if the section has been archived or renamed, and for comments in your notifications so that the links in them still work after a few weeks when the comments are archived.

We couldn't "reinvent Structured Discussions" even if we wanted though, because as long as the pages are written in wikitext, comments will sometimes disappear or be indistinguishable from each other. But we think we could make these links pretty reliable.

Enterprisey (talkcontribs)

I have a lot of ideas for testing section-watchlist that are only written in notebooks; I'd be happy to put them up if there's any interest in that. As it is, the diff-handling code is perhaps halfway there (although it covers almost all edits in practice). There are a lot of details.

Jack who built the house (talkcontribs)

> the timestamp of the oldest comment in the section
Oh that's a good idea, have updated Convenient Discussions to use it.

Thanks for the explanation. Interesting architecture, seems like it might work. I can recall the cases (rare indeed, but still) where Convenient Discussions failed with similar premises in Russian Wikipedia, apart from bot-created sections that I mentioned:

  • We have an "Administrators' noticeboard" page, and admins who close requests would usually create a subsection and call it "Result". If an admin decides to close multiple requests at once or within a minute, two sections with the same name and oldest timestamp may be created. In this case, looking for the section's ancestors would help. Of course, if you plan to consider subsections subscribable at all.
  • On RfC/polling pages, there are often subsections pre-created for users to comment/vote in support/opposition to some idea, simply called "For" and "Against" or something like that. First of all, initially these sections are empty, with no signatures at all, so I'm curious how you will deal with such sections. When first comments/votes appear in such sections, multiple sections often have identical signatures.

May I ask about a thing that I'm strongly concerned about—will topic subscription be open to integration with user scripts? The architecture you described looks promising, so there could be no point to keep the section watching functionality in existing tools, including my CD, given that a third-party script (not an extension) would never have the capacity of a native tool with full support from backend. But for user scripts to embrace the native functionality, there should be convenient integration, for example the ability to read and write topic subscriptions using API.

(Actually, I wanted to ask this question in relation to various aspects of DiscussionTools, starting from the JSON for parser data that can be found at mw.loader.moduleRegistry['ext.discussionTools.init'].packageExports['parser/data.json'], but seemingly only after loading and executing Reply Tool—and ending with your planned format for hash links for comments which I will then need to make compatible with CD that currently uses the format yyyymmddhhmm_author[_id], if your format is different. But let's start with this.)

Matma Rex (talkcontribs)

Thanks, it's interesting to think about these corner cases. Right now we only plan to allow subscribing to toplevel sections. The backend could support subscribing to subsections or even to replies to individual comments, but it would be difficult to present this in the interface in an understandable way, so we're giving up on that for now.

We plan to implement all the new functionality by adding API modules for it, and then using them in our tools, so other tools should be able to use them as well (although I can't promise that this will be a stable interface, at least while we're actively working on new things).

I would recommend not accessing stuff inside the 'ext.discussionTools.init' module from your code, we keep changing it in incompatible ways. I'd be happy to make the things in data.json accessible in some other way (some of it already is, this just packages them up in way that's easier for us).

GhostInTheMachine (talkcontribs)

Revision IDs are absolute. Each section (and each reply) could be rendered to include the ID that created it. Each reply could state the revision ID of exactly what they are replying to. Any subscription would be to a specific revision ID - so you could subscribe to any part of a discussion - not just at the top section level. User scripts could highlight specific replies or chains of replies.

Matma Rex (talkcontribs)

Revision IDs would be nice too, but they're not quite the magical solution.

The big obvious problem is that we don't know the revision ID where a section or comment was added. We'd have to go through the previous revisions of the page to find that out (potentially hundreds on an active page like village pump), or have some database that gets updated whenever a section or comment is added (which is something I'd like to work on some day, but it does not currently exist).

Further less obvious problems include: handling reverts, handling revision deletion, handling sections being renamed, handling comments being transcluded from a different page than the one you're viewing, handling edits that add multiple comments… All of this is solvable, but I don't think it's less complex than what we're working on right now.

PPelberg (WMF) (talkcontribs)

@Jack who built the house seeing the approach you've taken with Convenient Discussions is helpful – thank you for taking the time to document this.

A follow up question for you, and I suspect @Enterprisey, related to what @Matma Rex shared above: Based on the experiences you've had developing tools for talk pages, how often have you encountered [i] two or more talk page sections that have identical anchors and timestamps?

Context: I ask the above as we weigh the tradeoffs associated with decoupling topics, and by extension comments, from the pages on which they exist. More details in T264885#6859503.


---

i. E.g. 1) you have never seen this happen, 2) you have seen this happen a couple of times, or 3) you have seen this happen on a weekly or monthly basis.

Enterprisey (talkcontribs)

I have never encountered this situation myself, but I designed section-watchlist as if it were possible. As an example, someone could start two RfCs at once, each with a "Support" and "Oppose" section. section-watchlist identifies sections using a combination of anchor and duplicate index, i.e. the index of this section among all sections of the page with the same anchor. Every time a section is renamed, all sections with the same anchor have to be re-identified.


That's a big drawback, so I just thought of another idea: use the parent section's anchor. I think it's just about impossible (among workflows on enwiki) for two sections to have the same anchor and parent anchor.

As a final note, I have thoughts about timestamps, if those end up being used. I think either the first or oldest timestamp should be used, but they both have issues: for the first timestamp, sometimes enwiki inserts another comment above the oldest comment, such as with closing statements or process notes ("this section has been moved from..."). For the oldest timestamp, sometimes people copy/paste older comments into their comment, bringing the timestamps. Even worse, sometimes this happens at the end of a line, in which case the comment is difficult to distinguish from one left naturally. However, searching the first N comments, or taking the first comment where both the previous and next comment have newer timestamps, might be more successful.

PPelberg (WMF) (talkcontribs)

It's helpful to know how you have yet to encounter a situation where two talk page sections have the same subject name and have been posted at the same time. We appreciate you thinking about this, @Enterprisey.

As for the "drawback" you are raising and the proposed design to resolve it, I think @Matma Rex is better positioned to add any thoughts, if he has any.

Jack who built the house (talkcontribs)

> with the same anchor
Do you mean the same headline? Because sections are assigned unique anchors (the id parameter) by the engine.

> For the oldest timestamp, sometimes people copy/paste older comments into their comment, bringing the timestamps.
Yup, that's a valuable note. Convenient Discussions excludes blockquote tags as well as elements with the classes defined in the wiki configuration from places where signatures should be searched for, but that could not be enough. As I can see, Reply Tool currently places its reply links right in blockquote tags, which I believe should be fixed. Created phab:T275881.

> taking the first comment where both the previous and next comment have newer timestamps
I'm not very familiar with the English Wikipedia customs; is it impossible for a discussion to emerge after the closing statement? Are you sure this method will be reliable? In Ruwiki, we often have multiple bot comments added one after another (for example), but the most recent comment is always added to the top, so your approach would work with that.

> use the parent section's anchor
Convenient Discussions uses the headlines of the whole ancestor chain, as I mentioned above. Imagine the following section structure:

== Proposition title ==
=== Opinions ===
=== Voting ===
==== Support ====
==== Oppose ====

== Other proposition title ==
=== Opinions ===
=== Voting ===
==== Support ====
==== Oppose ====

Using the whole ancestor chain would work with it. Although the project members already said they currently don't plan allowing subscribing to subsections.