@suffusion_of_yellow: Is one of these browser windows in private mode, or not?

For logged-in editors, it's almost as bad. All they get is an unexplained "1" in a circle, but still no banner.

That sounds totally correct to me and I expect many users used to social media that the "1" in a circle is a notification. That weird banner should not be shown.

If this ticket is about the lack of a "You have new messages" banner in the mobile interface for logged out users, then I do not see any bug here. Not sure as the steps are confusing and don't explicitly list an expected and an actual outcome, and if that was in mobile or desktop or in that one window or that other window.

In T240889#5745743, @Aklapper wrote:

@suffusion_of_yellow: Is one of these browser windows in private mode, or not?

For the IP test, I just used Tor Browser Bundle with the default settings. I imagine that's similar to private mode. Ideally someone who doesn't mind making their IP public should run this test with a normal browser.

In T240889#5745757, @Aklapper wrote:

If this ticket is about the lack of a "You have new messages" banner in the mobile interface for logged out users, then I do not see any bug here. Not sure as the steps are confusing and don't explicitly list an expected and an actual outcome, and if that was in mobile or desktop or in that one window or that other window.

Sorry, I guess I'm making it more complex than needed. Try:

1. Have someone leave your IP a message.
2. While logged out, in mobile view, visit [[Wikipedia:Sandbox]]. Click "edit".

The expect result is a "you have new messages" banner, or some other clue that another user wishes to talk to you.
The actual result no banner.

I believe, this is intentional, as such this is not a bug. You're just seeing it odd because you're using the mobile version (for the first time?) judging by your comments on enwiki. The "you have new messages" banner is for desktop. Mobile uses different notification and it's conspicuously colored and incremented per notifications (up to 99). It would be quite intrusive and poor design to send banner that will fills screen edge to edge to mobile users.

The notification shown for mobile users is big (in proportion of the screen) and strategically placed. You can only intentionally ignore it. It's of course even bigger and noticeable than comparable notifications from other services.

Twitter mobile	Facebook mobile	Wikimedia mobile

@Ammarpad: I only see the red circle when I'm logged in. I see no indication of any kind that there is a message, when logged out. Do you?

In T240889#5746752, @suffusion_of_yellow wrote:

@Ammarpad:.. I see no indication of any kind that there is a message, when logged out. Do you?

No. Notification is not shown for non-logged users (but remember there are also many things not shown on mobile, for example IP range edits are not visible on Special:Contribs). Also see my comment below, this task title is referring to all users not only non-logged.
(Comment edited after understanding the question more.)

This task now seems inconsistent with the original enwiki post which my comment above (T240889#5746727) was originally written for. The initial bug description was "New messages" banner not showing on mobile?. And this task's name still reflects that, though with different description. Now please describe which issue you are reporting, (and if necessary create another task) as the issues are fundamentally different, and relate to different extensions, even though related.

Possible actions:

1. "New messages" banner should be shown on mobile. (feature request)
2. Notification is not shown for IPs on Mobile (bug) (probably intentional, I don't know though)

What to do:
If you decide to go for both, please open new task for 1 (and rename current task)
If you decide to go for 1 only, the task description should be amended.
If you decide to go for 2 only, the task name should be changed.

This will greatly simplify things, and allow teams from each extension to triage their own issue.

"New messages" banner should be shown on mobile. (feature request)

That feature request will be declined: We only display the orange bar of death if the Notifications extension is not installed on a wiki, as of T58834...

From test test in my prior comment and the other notes above, it appears that we are delivering newtalk notifications one way or another to:
Desktop users

But we are failing to deliver this to:
Mobile Website Users

@suffusion_of_yellow I suggest refining or splitting it to multiple tasks as well. Is your core concern communicating with "mobile editors" or "logged out mobile editors"? The former appears to have at least some form for notice they have new talk, while the later appears to have none.

@Xaosflux: Thanks! I consider the IP issue a high priority problem, the logged-in issue less so. I had assumed that the goal had been to deliver the banner to all users, in one form or another (as on desktop), and a simple bug was preventing the display. Now that I know that part of this is intentional, I will split the task.

@ovasileva: Why was this one marked low priority? I understand that people might disagree with me about T240976, and I'll respond to your question there later, but this one's a big deal. We literally have no way whatsoever to initiate a discussion with logged-out mobile users. Worse, we think we're talking to them.

There a whole lot that a new user could do, that's 100% allowable on other sites, but not here. Pasting copyrighted text. Speculating on the personal lives of celebrities. Using talk pages as a general forum.

We have arbitrary rules, that no one could ever guess until told about. 3RR. Not removing some kinds of deletion templates. Not blanking content without an edit summary.

The normal procedure is to leave a message on the user's talk page, informing them of our policies. If they ignore it, leave another ones. And so on. Eventually, it becomes obvious they're just ignoring us, so we block them.

So users engaging in perfectly good-faith behavior are being blocked for "refusal" to "listen" to our "warnings", that they don't even know exist. That's a terrible experience, for a new user , and it's completely unacceptable for this to go on.

Eventually, it becomes obvious they're just ignoring us, so we block them.

I'm curious how high the rate of IP users is that are not ignoring "their" talk page. Especially if they don't have a static IP. (Anybody having any numbers?)

In T240889#5751876, @Aklapper wrote:

I'm curious how high the rate of IP users is that are not ignoring "their" talk page. Especially if they don't have a static IP. (Anybody having any numbers?)

How would one measure that? You could check for IPs editing their own talk page, of course, but how do you distinguish an user who saw the message, thought "Oh, oops", and stopped, vs. one who didn't see it, but just became bored and went on to another site?

I agree that dynamic IPs are a problem, both for mobile and non-mobile IPs. Often the only way to communicate is the block message. That's a horrible solution, but we didn't create the problem, ISPs did. Maybe there needs to be a "range talk" feature, open to some privileged users, but that's another discussion for another day.

@suffusion_of_yellow regarding "range talk", lets assume for a moment that it did exist - how would you expect notification/clearing of such a notification to function?

In T240889#5752169, @Xaosflux wrote:

@suffusion_of_yellow regarding "range talk", lets assume for a moment that it did exist - how would you expect notification/clearing of such a notification to function?

I really don't know; I was just thinking out loud. There are other problems, e.g. where is the user supposed to reply? Maybe I'll start something at WP:IDEALAB,

Yup, this is definitely very important. How exactly are editors supposed to communicate with mobile IP editors if they receive absolutely no notification from talk page messages?

Recently I tried to contact an anonymous mobile user about their edits, and now after finding this task I realize it's nearly impossible for that user to get my message, and indeed to most other users it appears that anonymous user just ignores their talk page. The only workarond I can think of is to block given user and make reference to talk page in block reason (though I'm not sure if block reason gets accross either via mobile interface). This is particulary bad even if there was only one anonymous mobile user that doesn't get their messages, and so I also wonder why is this low priority.

I support raising the priority of this. Mobile IP users not being able to see user talk messages is a big deal on en-wiki. We use warning templates all the time. If they can't see the messages, then they can't fix their behavior, resulting in needless extra vandalism, warning templates, AIAV filings, blocks, and time expended.

I second the community members who asked for the increase of priority. Mobile edits are on the rise and this bug blocks the normal workflow the communities use to communicate with anonymous users without providing a replacement. Since this seems to be in the Growth team, I'd like to see what @MMiller_WMF thinks. What's the grand plan for edits on mobile?

@Strainu -- thank you for bringing this up. Deciding the amount of resourcing we provide for the IP editing experience is always a challenge. I'm going to ask a couple other product managers about this question to see if they've considered it, and I'll get back to you.

In the meantime, @Etonkovidova, could you please check the behavior described here on both desktop and mobile and verify that we see the same lack of notification for mobile IP users that others have reported?

In T240889#6959169, @MMiller_WMF wrote:

@Strainu -- thank you for bringing this up. Deciding the amount of resourcing we provide for the IP editing experience is always a challenge. I'm going to ask a couple other product managers about this question to see if they've considered it, and I'll get back to you.

In the meantime, @Etonkovidova, could you please check the behavior described here on both desktop and mobile and verify that we see the same lack of notification for mobile IP users that others have reported?

@MMiller_WMF - Yes, the behavior has been confirmed and, as far as I could see the feature (notifications) behavior is intentional (e.g. from the documentation[[ https://www.mediawiki.org/wiki/Notifications| "Anonymous, unregistered users will not receive notifications at this time." ]]

Notifications/Feature_requirements#Message_indicator informs that the orange bar is "available to all logged-out or anonymous users" but never was present on mobile (T58834#614255).

The issue reported here is a bigger issue - how to provide better notification to anon users and, specifically, to the anon users on mobile?

In T240889#6973641, @Etonkovidova wrote:

The issue reported here is a bigger issue - how to provide better notification to anon users and, specifically, to the anon users on mobile?

Not better notification, but any notification. It's a significant difference!

In T240889#6973641, @Etonkovidova wrote:

from the documentation "Anonymous, unregistered users will not receive notifications at this time."

To be clear, this intentional behaviour concerns notifications by means of Echo extension. Anonymous desktop users however still get new message alert (orange bar) that isn't Echo-based. I suppose solution here necessarily doesn't have to be Echo-based either?

While I agree that this bug is really serious (being able to communicate is possibly the most important thing in a community), I'd also like to point out that the underlying issue is not just "we're not showing notifications to logged out users on the mobile version". The real issue is: "The mobile version doesn't show any notification if Echo is not installed". That is, without Echo, even registered users won't get any notification on the mobile version.

I'm not entirely sure why the notifications-related code in MinervaNeue is strictly bound to Echo. Couldn't it just use a fallback?

In T240889#6959169, @MMiller_WMF wrote:

@Strainu -- thank you for bringing this up. Deciding the amount of resourcing we provide for the IP editing experience is always a challenge.

Reading between the lines: are you asking the community to have a vote to disable IP editing?

Completely bonkers that this and T240976 are low priority. And T95396 was marked as fixed without being fixed.

Hi @AlexisJazz -- no, I'm not suggesting any sort of vote or judgment around IP editing. That's a much bigger and more complicated question than I think we're talking about here. I think for the issue on this task, we just want to figure out whether/how to close this hole of mobile IP editors receiving no notification. I've talked about it with a couple other product managers, and we have some ideas:

• Show a notification on mobile similar to the orange bar that gets shown on desktop for IP users when they have pending messages.
• But since we expect mobile IPs to be less stable than desktop (i.e. more likely that someone other than the intended recipient of the message would visit the site from the same IP), we were worried of showing these notifications to lots of people for whom they were not meant. Therefore, we were thinking of:
  • Only showing the messages on pageviews that are not article-reading views. In other words, show them in the Wikipedia, Talk, User, User Talk, and perhaps right after a user taps to edit. This would cut down on how often unsuspecting readers see notifications about messages that aren't meant for them.
  • Let the notification expire after a certain amount of time -- like, say, a week. The idea here is that after some time, mobile vandals and other people who need to see their messages may well be off that IP address. By expiring the notification, we would be keeping the next users of that IP address from encountering it.

We're still talking these ideas over and scoping them for feasibility. We're interested to hear what people think!

At the very least, including the notification when attempting to start a new edit or action seems at least somewhat better.

In T240889#7108934, @MMiller_WMF wrote:

Hi @AlexisJazz -- no, I'm not suggesting any sort of vote or judgment around IP editing. That's a much bigger and more complicated question than I think we're talking about here.

Personally I'd support it. I'm now dealing with an IP editor who changes IP every day. So if I leave them a message, they won't see it because their IP often changes between me leaving the message and them visiting Wikipedia. I need to tell them about using reliable sources, but can't. Also I could stop worrying about accidentally leaking my own IP. (it HAS happened)

So now we have sysops blocking community consensus in the name of the WMF (and they still are, ptwiki created ugly workarounds to make IP-editing more difficult to override the sysops) while the WMF says "Deciding the amount of resourcing we provide for the IP editing experience is always a challenge". Finding resources for it is a challenge but if a community wants to get rid of it they get told it's "not gonna happen". You either find the resources (in which case I suggest using the salary of two executive management members) or you respect the wishes of communities who want to disable IP-editing. You can't have your cake and eat it too.

In T240889#7113694, @AlexisJazz wrote:

In T240889#7108934, @MMiller_WMF wrote:

Hi @AlexisJazz -- no, I'm not suggesting any sort of vote or judgment around IP editing. That's a much bigger and more complicated question than I think we're talking about here.

Personally I'd support it. I'm now dealing with an IP editor who changes IP every day. So if I leave them a message, they won't see it because their IP often changes between me leaving the message and them visiting Wikipedia. I need to tell them about using reliable sources, but can't. Also I could stop worrying about accidentally leaking my own IP. (it HAS happened)

So now we have sysops blocking community consensus in the name of the WMF (and they still are, ptwiki created ugly workarounds to make IP-editing more difficult to override the sysops) while the WMF says "Deciding the amount of resourcing we provide for the IP editing experience is always a challenge". Finding resources for it is a challenge but if a community wants to get rid of it they get told it's "not gonna happen". You either find the resources (in which case I suggest using the salary of two executive management members) or you respect the wishes of communities who want to disable IP-editing. You can't have your cake and eat it too.

For what it's worth, my experience with MMiller (from some of the Growth Team's requests for input on enwiki) is that they're a prudent product manager who cares about engaging with the communities. So I don't think it's particularly helpful or fair to take it out on the person who's actually trying to move the ball on the issue.

In T240889#7113952, @Proc wrote:

For what it's worth, my experience with MMiller (from some of the Growth Team's requests for input on enwiki) is that they're a prudent product manager who cares about engaging with the communities. So I don't think it's particularly helpful or fair to take it out on the person who's actually trying to move the ball on the issue.

I mostly just find it frustrating that these messages are effectively contrasting each other. If it's considered essential, finding resources shouldn't be an issue. And if it's not essential, ptwiki should have had its wish granted. MMiller, it's nothing personal, it's just confusing.

Thanks for explaining the background, @AlexisJazz. I'm going to continue gathering opinions on the specific improvements we're discussing here, and we'll also be gathering some detail from the engineers on our team on which changes are the most feasible to make in the near term.

Another example: This problem (that is, funnily enough, still triaged as of Low interest by the team) also means that in Russian Wikipedia, if a bot reverts an IP user’s edit using ORES (which can be erroneous), they do not see the boilerplate proposal to restore the edit offered via talk page. I even made the bot’s message responsive thinking it would be displayed to IP editors, but no. It is pretty bad that the only way to communicate with an IP user right now on mobile is the block button.