Page MenuHomePhabricator

Mobile web (and Minerva desktop) does not present edit notices
Open, Needs TriagePublic

Description

Editnotices are an important part of educating users and trying to prevent them from making mistakes when creating and/or modifying content. These notices are currently not presented in the mobile interface.

See also: https://en.wikipedia.org/wiki/Wikipedia:Editnotice
Related: T201596: iOS app does not present edit notices and T201597: Android app does not present edit notices

Event Timeline

Is this about mobile apps, or the mobile frontend in browsers, or both? :)

TheDJ renamed this task from Mobile web does not present edit notices to Mobile web (and Minerva desktop) does not present edit notices.Aug 9 2018, 9:46 AM
TheDJ added a project: MinervaNeue.
This comment was removed by HairyDude.
Liuxinyu970226 added a subscriber: Jdlrobson.
在T201595#4490981中,@Aklapper写道:

Is this about mobile apps, or the mobile frontend in browsers, or both? :)

I'm afraid, affecting all parts

Is this about mobile apps, or the mobile frontend in browsers, or both? :)

I had already created the sibling tickets for the app platforms and mentioned them in the task description ;)

The inability to see edit notices on mobile is something we suspect is a major contributing factor to the messiness we're seeing at [[w:2019-20 coronavirus pandemic]]. This seems like an important issue to address — is there anything we can do to get this unstalled and prioritized?

Jdlrobson changed the task status from Stalled to Open.Mar 21 2020, 9:04 PM
Jdlrobson added a project: covid-19.
Jdlrobson added a subscriber: dr0ptp4kt.

The inability to see edit notices on mobile is something we suspect is a major contributing factor to the messiness we're seeing at [[w:2019-20 coronavirus pandemic]]. This seems like an important issue to address — is there anything we can do to get this unstalled and prioritized?

I can certainly tag it with covid-19 and raise it to my director of engineering.

Context for those joining... an edit notice looks like this in VisualEditor:

Screen Shot 2020-03-21 at 1.56.34 PM.png (1×830 px, 257 KB)

And without JS:

Screen Shot 2020-03-21 at 1.57.14 PM.png (1×2 px, 553 KB)

With non-js these don't show on mobile at all (hidden by CSS):

Screen Shot 2020-03-21 at 1.58.10 PM.png (1×2 px, 401 KB)

and if you reveal them they take up the majority of the screen:

Screen Shot 2020-03-21 at 1.59.41 PM.png (1×824 px, 249 KB)

On the mobile editor where revealing these would likely be the most impactful they do not show at all.

Ideally in that editor they could show up in a similar fashion to the "you are not logged in" warning however that requires an API which is why this was stalled as none exists.

Screen Shot 2020-03-21 at 2.00.29 PM.png (1×796 px, 97 KB)

@dr0ptp4kt Maybe getting an API is something that the parser team/platform team could investigate? I think if there was an API this could be quite trivial to implement.

Hi all. Would it be possible for someone to disposition recent mobile edits relative to a desktop baseline?

https://en.wikipedia.org/w/index.php?title=2019–20_coronavirus_pandemic&offset=20200324000000&limit=500&tagfilter=mobile+edit&action=history

For those following along, by opening the "prev" link for each entry in a new tab you can get a sense of the edits looking backward starting from today. The rendered pages for those diffs are big and complex, so you may need to wait a few seconds for each page to open even on a reasonably powerful computer. You can delete the mobile edit tag filter text at the top of the screen to see all other edits.

We're generally interested in surfacing good guidance to users about the editing workflows, the theory being that suitably informed users are more likely to do the right thing. In the iOS app, for example, we've been exploring concepts on how to ease users into editing with suitable framing (cf. onboarding).

In the particular case of this article, one thing we have going here is that it's semi-protected, so that may tamp down on drive-bys or good faith but damaging (or inconvenience inducing) edits.

I realize the task is referring to the general case, though, and reliance on semi-protected article status isn't ideal. It's nice to get edits from more casual, but editorially-nudged, people irrespective of their autoconfirmed status for non-protected articles.

Anyway, @cmadeo do you know if we have an edit notice affordance task? I ask in case we want to de-duplicate the iOS task @TheDJ created.

@Jhernandez do you happen to know if there's a transform in mobile-html that extracts the edit notices for compatible clients? I'm wondering if that can be factored out to its own method if so. We may want to partner up with our CPT colleagues in case we determine the UX treatment ought to mirror the edit notice and therefore create a standard and reusable REST route.

I see that w:Template:Pp is available on about 57 languages, so I'm wondering if there's some sort of generic way to express the general guidance for page protection that we can inject directly into the edit flow on the different mobile UXes, rather than potentially having to tango with the corresponding parsed HTML of the edit notices.

We already notate semi-protection status with a toast on click in our mobile interfaces, so what if we created interface text to at least simplify things over all for the edit flow when the user is already logged in? We all get the point of allowing for local UGC to express different customs for page protection on different wikis (and the template parameters of the template invocation), of course, just thinking out loud about possible approaches to solve for the underlying desire to provide useful nudges to the AC users.

Most of the guidance of the referenced article's edit notice on enwiki is useful stuff, some of it is ignored without too much peril.

  • Many elements of this article reflect prior consensus. Please check the talk page before making any major edits to see if the content you wish to edit has been discussed there or is under discussion. If so, please do not makes changes until consensus has been reached.
  • Due to the high volume of edits to this page, it is especially important to use good edit summaries describing concisely the change you are making and the rationale for making it. For big or controversial changes, the rationale should be a link to the specific talk page section where consensus for such a change was achieved.
  • All information added to this article must be supported by a reliable source (further info: WP:MEDRS) and presented from a neutral point of view; otherwise it will be removed.
  • Please use past tense and British English in this article.
JTannerWMF moved this task from Untriaged to Next Quarter on the Editing-team board.
JTannerWMF added a subscriber: JTannerWMF.

The Editing Team is unlikely to get to this right now but we are going to queue it up.

As touched on my @Jdlrobson another major issue here is that on wiki edit notices can be extremely verbose, and are mostly designed to be viewed on desktop. Even if we use the whole screen, many of these messages won't fit.

on wiki edit notices can be extremely verbose

I guess we can create mobile versions of edit-notices which are shorter / better designed for mobile.

on wiki edit notices can be extremely verbose

I guess we can create mobile versions of edit-notices which are shorter / better designed for mobile.

@Proc possibly, but the community has not done so in over 12 years in which they had the opportunity to do so and were repeatedly pointed at how useless many of these banners were.... And retroactively modifying any templates/message etc inside the community tends to be a laborious and draining operation that most ppl able to do this do not wish to engage with. Aka.. it's a challenge.

This is also a chicken and egg problem. Because it is not shown on mobile, the notices definitely do not get adapted to mobile. But because the notices are unsuited for mobile, no effort is being made to add them to the mobile interfaces either.

I'll second everything TheDJ just said — streamlining things like edit notices is a task I've been working on, but it's often quite difficult to build consensus. One alternative might be to create some parameter that'd allow designation of which edit notices are essential enough to be needed for mobile and which can be desktop-only.

@TheDJ regarding "were repeatedly pointed at how useless many of these banners were", do you have links to a few past discussions by any chance?