Topic on Talk:Talk pages project/Replying/Flow

Needs to ping

32
Summary by Whatamidoing (WMF)
Piotrus (talkcontribs)

This should auto-ping the person being replied to, using en:Template:Rto or such. It could be optional but 'default', like the reply-to scipt on en wiki.

Kusma (talkcontribs)

Or at least the "ping" button could be there in source mode. I was about to give up on this feature and go back to "reply-link.js" when I found out that you can insert the ping by clicking "visual", then typing "@" or use the person-plus logo to ping, then switch back to source. That's 3 more clicks than reply-link, which isn't great unless we want to discourage pings.

Tacsipacsi (talkcontribs)

It’s already there for a few weeks now, just it’s opt-in for now: turn on Enable experimental tools in the quick replying and quick topic adding features' source modes in your preferences to access the experimental reply tool’s even more experimental source mode toolbar.

Piotrus (talkcontribs)

A useful feature like this has to be default. I can see opt out as a preference option, but not the other way around.

Kusma (talkcontribs)

Thanks, that's great! The question seems to come up quite frequently. I wonder whether that means the default should be changed or that the preferences for the Reply tool should be on the page where you turn on the Reply tool.

Tacsipacsi (talkcontribs)

As I wrote, it’s opt-in for now. The plan is to make it opt-out, and eventually turned on without an opt-out, but the developers considered it too risky to turn it on for everyone right now. This is the place for all DiscussionTools preferences except for the beta preference; this separation is (as far as I know) necessary for technical reasons.

RoySmith (talkcontribs)
RoySmith (talkcontribs)

I just turned on the experimental features. The "Mention a user" menu is better than not having it at all, but the default really should be to ping whoever signed the section you're replying to. Then you can add other users from the menu if you want, but you shouldn't have to do a menu selection to get the default "ping the person you're replying to" behavior.

Nick Moyes (talkcontribs)

I'm not sure I agree that including the person's name by default so that they are automatically pinged is a good idea. It's quite simple just to type @ and then select who you want to reply to from the drop down. Pinging is great for replying to new users who don't know about watching pages, but more experienced editors hate being pinged on pages they're already watching. This looks set to be a tool everyone is going to use, and default pining would really irritate many people. Being selective about who you ping is best, and should be left to the replying editor.

Piotrus (talkcontribs)

I disagree that "more experienced editors hate being pinged on pages they're already watching". I am an experienced editor and I love pings. I have zillion watchlisted pages, many discussions I am participating in and I HATE it when people reply to me and don't ping me - I will usually miss their response. I hear anecdotes about people who hate being pinged but I haven't really met such a rare creature. If they exist, they should be able to opt out of being pinged and then they can be happy being ignored and forgotten about. But the existence of this rare species of editors should not damage the usefulness of the tool for the 99.999% of the rest of the community.

Kusma (talkcontribs)

Reply-link.js starts the edit box with a pre-filled ping and you can then decide to remove it if you don't think you need to ping, which is pretty nice. I disagree on "more experienced editors hate being pinged on pages they're already watching": I don't manage to follow all pages on my watchlist all the time. If your reply to me on a talk page is hidden on my watchlist by, say, an archive bot making the most recent edit, I might not notice it. Think of those of us who are lazy or otherwise bad people :)

RoySmith (talkcontribs)

I see Reply-link.js as doing things exactly how they should be done, with the big exception that it doesn't always work because it uses brittle wiki parsing which often fails. The big advantage I see for the reply tool is that it does the parsing in a robust way (I assume via parsoid). What would be best is this tool's robust parsing mated to reply-link's user-facing behavior.

That being said, I could see there being some user-settable option where somebody could set a "do not ping me by default" flag, which "more experienced editors [who] hate being pinged" could set. But the default should be automatic pings, so naive users automatically get the behavior which most enhances two-way communication.

Whatamidoing (WMF) (talkcontribs)

I believe that the toolbar for 'source' mode is available to everyone now (or maybe on w:en:WP:THURSDAY)

Whatamidoing (WMF) (talkcontribs)

About pinging folks, my question is about who controls it. The options are:

  • I decide that I will always ping everyone by default (or that I never will).
    • Your preference about getting pings or not has no effect on whether you get pings.
  • I decide that everyone will always ping me by default (or that nobody ever will).
    • Your preference about sending pings or not has no [default] effect on whether you ping me.

Which of these describes the type of control that you all would prefer to have?

RoySmith (talkcontribs)

Having the recipient control things would (I think) be very confusing. Let's say you turn off incoming pings. First, we have to figure out what that means. I'm assuming it means the {{FlowMention|Whatamidoing (WMF)}} template doesn't get generated when I reply to a message of yours. So, now I'm left with the behavior I can observe being altered by a setting that you've set and which I probably don't even know exists. That would just be confusing to me. All I'd see is that sometimes when I reply the template gets generated and sometimes it doesn't. Nondeterministic from my point of view.

The alternative is that the template gets generated, but you just don't receive any notification. I think that would be even more confusing. I ping you, you don't respond, I assume you're just ghosting me.

Piotrus (talkcontribs)

OVerall I recommend focusing on what most people want and not to worry to much about the 0.1% who will always be unhappy with whatever feature exists (or doesn't). 99.9% people want to be pinged (or at least don't care enough to protest if they want). If you want to code in exceptions, controls, etc., go for it, but the priority should be to deliver the basic improved functionality (i.e. this tool, with ping being the default mode) to the community, and do it yesterday. The concerns of 0.1% should not cause a second of delay. If you try to make everyone happy you will make no-one happy as you'll never finish this.

Xover (talkcontribs)

This is a really complicated problem to solve fully because the correct answer is in the intersection of the preferences of all the people involved in each conversation and the nature of the conversation itself. I don't think it is actually solvable within the current constraints.

But the limited subset that can reasonably be addressed: the reply tool should always by default insert a @user: link for the user being replied to, in order to make it easy by default to ping when you reply and still let me adjust who I'm pinging (add someone else, for example) or remove the ping altogether if I know they prefer not to be pinged for whatever reason. A separate preference might be provided to disable the by-default ping for those users who prefer to not ping others, but beyond that I don't think any preference except the existing blunt one (don't notify for links to my user page) is merited.

In order for any more sophisticated system to be feasible we would need to move to a fully controlled discussion system (ala LiquidThreads or whatever it's called now), where notifications were not contingent on a link to the user page (essentially taken out of the user's control and given to the software). With such a system you could start distinguishing between automated and manual notifications, and let both senders and recipients set granular preferences for these. Before we get there (and I am not advocating we go there: the communities generally wanted to keep talk pages as wikipages for good reason) I think the cruder manual pings and notification control is all that is practical.

I don't understand the implications of the two specific option you list (they are not all conceivable options, so they clearly represent a tradeoff and technical choices which I do not necessarily endorse). But to the degree I can address them directly: in the general case I want to always be pinged when someone replies to me, irrespective of their preference; and when I reply to someone I want to always ping them but I want them to be able to opt out of receiving notifications about my pings. I think that aligns most closely, but definitely not perfectly, with your second option.

Nick Moyes (talkcontribs)

I’m just returning to withdraw my concerns, and now agree that default pinging for the user one is directly replying to would be the most logical and helpful for any new editor.

Whatamidoing (WMF) (talkcontribs)

Let me add another layer of complication. As you've all noticed, this system (which is Flow/Structured Discussions) notifies you whenever someone replies in this discussion. You can get notifications about new threads (sort of like new sections?) on this page by clicking the star at the top of the page to put the whole page on your watchlist. You can get notifications about new replies in this thread by clicking the start at the top of this individual thread. If you comment in this thread, you are automatically subscribed to ("watching"?) this individual thread. (You can unsubscribe if you want.)

If Talk pages project/Notifications reaches the point of auto-subscribing everyone to every ==Section== they Reply in, would you still want to be pinged? Or is it annoying to get a ping and get a (separate) notification about a new comment in this thread?

Xover (talkcontribs)

Hmm. A new reply is one event, and someone mentioning me is a different event. Someone replying directly to me is a sort of amalgam of both, but still a distinct event semantically. Ideally all three would be distinct and separately controllable. But since we're not designing a perfect system from scratch with infinite resources available to do so… :)

The at-mention at the beginning of a reply is overloaded (serves multiple functions) so I would want to keep that, and I would personally probably prefer to live with double notifications (but I think a lot of people would probably absolutely hate that). It is possible that the reply tool should insert unlinked at-mentions in some cases to preserve the on-page function it has (signalling who is being addressed) without generating a possibly-redundant notification.

For Flow (which I have barely used), reply notifications show up as a notice and mentions show up as alerts. Double notifications that you have to visit both menus to dismiss are going to be extra annoying. How does Flow deal with busy threads? Is there one separate notice for each reply, or are they coalesced into "There are 15 new replies"? If the notices are coalesced and at-mentions are delivered as separate alerts, the result might make enough sense to not be annoying.

But, yes, having notifications from non-Flow talk page sections definitely changes the calculation for the reply tool's behaviour. And I am not sure I am able to predict how that calculus shakes out for me, much less speculate what any significant subset of the community at large would think of it.

Not sure that was of any help, but it was the best I could come up with. Sorry.

Whatamidoing (WMF) (talkcontribs)

> How does Flow deal with busy threads?

Replies in a single thread are bundled. For example, today I have a note about 10 new replies in this thread. If someone had pinged me, I would have received a separate ping (in the other menu) for the ping. (This is also the plan for notifications on plain wikitext pages.)


> Not sure that was of any help, but it was the best I could come up with. Sorry.

Thank you for your comments, and to all of you for really thinking this through. There are lots of moving pieces here.

RoySmith (talkcontribs)

To be honest, I'm not sure what the answer is. One of the big problems I have with the classic watchlist is that you can only watch a page, not a thread. And of course, in the classic environment, there really isn't any concept of a thread per-se. As you note above, what most people call a thread is really just a section. It's entirely possible that what I'm about to say here doesn't make a whole lot of sense in the new Flow way of looking at things. I'll just dive in anyway, and feel free to filter this through "No, you just don't get how Flow is supposed to work".

My watchlist is a terrible way to get my attention. If you want to get my attention, you have to ping me, which makes it show up in one of the random tabs at the top of the page (it's either an alert or a notification, I'm not sure which and as an aside, I don't really understand why alerts and notifications are two distinct things). It sounds like the star at the top of a thread will put something on my watchlist. Which means I'm likely not to see it. Right now, I've got 6,482 pages on my watchlist. Mostly stuff just gets lost in the clutter. So, I don't think subscribing to a thread is really a replacement for being pinged.

The other argument I can make is that reply-link.js is the de-facto standard for how this works. If you're going to replace it with something, I'm OK with fixing broken behavior (more than OK, actually; that's the only way we make progress), but if you're going to change something, I think the onus is on the person making the change to show that it's clearly better. For sure, the fact that Flow can reliably parse complicated threads while reply-link.js often fails to do so is a killer reason to switch to Flow. But I haven't seen that level of certainness around changing the ping behavior that everybody's used to now.

To answer your specific question, "is it annoying to get a ping and get a (separate) notification about a new comment in this thread?", yes, that would be annoying. In the same way that when somebody pings me on my talk page it's annoying that I get double-notified with "You have a new Talk page message" and alert bell lighting up. But the answer to both of those is the same; the notifications should be du-duplicated automatically.

Xover (talkcontribs)

I am not aware that Flow as such is a factor in this discussion, beyond being an example of a parallel system that exhibits some behaviours one can use for comparison. Neither the new reply tool nor the "subscribe to threads" thing linked up above have anything to do with Flow as such (AIUI), except in the way that Flow has features similar to that which a lot of people think are good even if they don't like Flow as a whole.

RoySmith (talkcontribs)

Hmm. I wasn't even aware this wasn't part of Flow. I've just sort of grouped them both into "Things which use the Visual Editor to edit talk pages".

Tacsipacsi (talkcontribs)

The plan is to distribute these new comment notifications through Echo (the blue/red notifications at the top of the page), not through the watchlist. So if you can keep up with that, you’re good to go.

Whatamidoing (WMF) (talkcontribs)
Kusma (talkcontribs)

I fully agree with RoySmith: I like to be pinged (using my bloated watchlist is rather hit and miss) but please find a way to merge double notifications into one. As this thread is on a wiki where I have never used my watchlist, I rely on crosswiki pings to even notice the conversation is still alive. But on my home wiki, I might want to be notified only when I get direct replies, but not for every time someone posts in the thread.

If you don't want to auto-ping (with opt out as in reply-link) the user being replied to, maybe we need separate "reply to comment" and "reply to thread" links, one with ping and one without?

(As an aside, crosswiki notifications used to really annoy me on my phone because I got the number in the tray without the ability to tell what it is until I managed to find a workaround for an annoying bug, see Topic:Wbnqf9bb8xtcbs3s for the problem description. Am I the only person who gets crosswiki pings on their phone?)

Piotrus (talkcontribs)

@Kusma You use Wikipedia on your phone? "O_O", as the youngsters say :D

Kusma (talkcontribs)

@Piotrus For reading and participating in discussions, the responsive mode Desktop Monobook skin is surprisingly tolerable and far superior to the "mobile" version. No idea why that is not the default.

Piotrus (talkcontribs)

The mobile version is hardly superior in anything, except general readability. Which, granted, is kind of important. But if you try to look for details like categories or, god forbid, participate by editing or commenting, mobile is an atrocity.

Nick Moyes (talkcontribs)

I use mobile a lot for editing and admin work (via a tiny iPhone 5 screen) but only ever in ‘desktop view, and don’t encounter problems apart from a lack of a proper keyboard.

Kusma (talkcontribs)

@Nick Moyes Can you figure out crosswiki pings on your phone?

Reply to "Needs to ping"