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.
|Open||None||T201595 Mobile web (and Minerva desktop) does not present edit notices|
|Open||None||T45683 Create API to expose editnotices|
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:
And without JS:
With non-js these don't show on mobile at all (hidden by CSS):
and if you reveal them they take up the majority of the screen:
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.
@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?
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.
@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.
@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.