Page MenuHomePhabricator

Encourage users who are currently ignoring their talk pages to read them
Open, LowPublic

Description

As a Wikipedian patrolling changes I time and again run into the following problem:

  • An editor, usually a new one, repeatedly does something undesirable (though not necessarily disastrous). For example, marks a heading as bold ('''Text''') instead of properly marking it up ("==Text==").
  • Other editor point this mistake out on the editor's talk page.
  • The editor ignores the talk page comments and keeps doing that unwanted thing.

There is no proper solution for this. One possible way to draw the user's attention to the messages is to block him, but that may be too harsh, especially if the mistake is not terribly destructive. Also, blocking is accessible only to administrators, which adds another level of inconvenience.

Last time I checked, the AutoWikiBrowser tool did have a solution for that. It's a desktop application that makes semi-automated edits to a list of pages on a wiki, for example regular expression replacement. If a user running the tool receives a talk page message, it stops working until the user at least reads the talk page.

It would be nice if MediaWiki itself had some kind of a mechanism to gently get the user to read what other users tell him.

And if not in core MediaWiki, then at least in Flow ;)

Event Timeline

Amire80 created this task.Aug 24 2015, 3:11 PM
Amire80 raised the priority of this task from to Needs Triage.
Amire80 updated the task description. (Show Details)
Amire80 added subscribers: Amire80, Pginer-WMF, DannyH.
Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptAug 24 2015, 3:11 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
Amire80 updated the task description. (Show Details)Aug 24 2015, 3:12 PM
Amire80 set Security to None.

Just to confirm, when do you mean read you really mean read and not just opening the talk page?

Something like embedding a random "code" inside the latest message and force the user to input that code to allow dismiss the notification?

Just to confirm, when do you mean read you really mean read and not just opening the talk page?

Design and user research will give a better answer to this, but just forcing to open the talk page, and maybe scroll the newly posted message into view would probably be a good start

Something like embedding a random "code" inside the latest message and force the user to input that code to allow dismiss the notification?

No, that will likely be an exaggeration that would confuse newbies even more. It will like CAPTCHA, which everybody hates ;)

Mattflaschen-WMF renamed this task from A solution is needed for the users who just don't want to read their talk pages to Encourage users who are currently ignoring their talk pages to read them.Aug 24 2015, 6:43 PM

The old title made it sound like we should optimize for users who just preferred never to read them. :)

Note that currently, for wikitext, they should see an orange bar and a red square at first, then the orange bar should remain until they go to the talk page. (The red square will disappear when they open their alerts).

For Flow, they will first see the red square, then a message until they mark the message read (either by visiting the page or explicitly marking it read).

After T108760: Move "left a message on your talk page" Echo notification from Alerts to Messages, it will behave similarly to Flow. The orange bar will remain, but explicitly marking a message read will remove it.

The ticket seems to be based on a deeper problem for which "forcing" the user to read the corresponding notification may be just one possible solution. I think that this kind of approach, like forcing the user to scroll to the end of a license agreement or terms of use to make sure they "read" it, is not the most effective in practice (it introduces friction to the user experience for little benefit since users tend to learn the workarounds to skip them).

I think that a better approach would be to guide the user into making better contributions based on what other users have highlighted. For example, if a user contributions have been flagged as lacking references, we can emphasise the need of adding references as the user edits (e.g., showing a personalised to-do list of the actions to make a good contribution, by making the reference action more prominent or in other ways we can imagine).

In any case, my point is to encourage the identification of the core issue beyond some of its symptoms. In this case it seems something like: Help users not to make recurring editing mistakes that other editors already identified in the past. If that is the issue, it would be great to reflect it that way, and then look for the reasons that motivate that behaviour and possible solutions.

Catrope triaged this task as Low priority.Aug 26 2015, 11:27 PM
Catrope added a subscriber: Catrope.

I get a feedback from someone who has Flow enable on his talk page. He asks to have the orange bar back, to see when he has personal messages (which are more important than other Flow messages). I also use Flow on my talk pages, with both my volunteer and WMF accounts, and I support this idea :)