| TheDJ | |
| Aug 9 2018, 9:22 AM |
| F34975269: wiki.png | |
| Mar 4 2022, 3:52 PM |
| F31697148: Screen Shot 2020-03-21 at 1.57.14 PM.png | |
| Mar 21 2020, 9:04 PM |
| F31697153: Screen Shot 2020-03-21 at 1.58.10 PM.png | |
| Mar 21 2020, 9:04 PM |
| F31697146: Screen Shot 2020-03-21 at 1.56.34 PM.png | |
| Mar 21 2020, 9:04 PM |
| F31697160: Screen Shot 2020-03-21 at 1.59.41 PM.png | |
| Mar 21 2020, 9:04 PM |
| F31697162: Screen Shot 2020-03-21 at 2.00.29 PM.png | |
| Mar 21 2020, 9:04 PM |
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
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T278838 Mobile user communication issues ([[Wikipedia:Mobile communication bugs]]) | |||
| Open | None | T201595 Mobile frontend web does not present edit notices | |||
| Resolved | Feature | matmarex | T45683 Create API to expose editnotices | ||
| Resolved | matmarex | T201613 Unify 'edit notices' technology stack | |||
| Resolved | ppelberg | T291893 Show edit notices within the New Discussion Tool on mobile | |||
| Open | None | T313278 [SPIKE] Evaluate use of EditNotices across projects | |||
| Open | MNeisler | T313279 [Impact Analysis] Evaluate Impact of introducing mobile edit notices | |||
| Duplicate | None | T316177 [Config Change] Make upstream mobile edit notice implementation available at en.wiki | |||
| Resolved | Esanders | T312587 Show edit notices within mobile editing interfaces | |||
| Resolved | ppelberg | T312299 [SPIKE] Review EditNoticesOnMobile.js gadget | |||
| Resolved | ppelberg | T344465 Instrument edit notices (desktop + mobile) | |||
| Resolved | DLynch | T316178 [Config Change] Make upstream mobile edit notice implementation available at all wikis |
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?
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.
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.
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.
@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?
Mediawikiwiki relies on an edit notice to inform users that they release their contribution to a help page into the public domain.
@Jdforrester-WMF has kindly declared this issue a bug: https://www.mediawiki.org/wiki/Topic:Wpdtfqlirzzkbo02.
Please do not twist my words to attack colleagues. Remember that you are bound by the Code of Conduct.
I'm somewhat annoyed by longstanding open issues, but where's the attack or even the word-twisting for that matter? This task was still just a "task", you called it a bug so I changed the subtype. Now you change it back? Okay, so it's not a bug, in that case it's a feature request. May I change the subtype?
Either it's a bug and should only be discussed here as you said (in which case the mediawikiwiki thread can be closed again), or it isn't a bug and it should be discussed on mediawikiwiki. Can't be both.
I've provided possible solutions in T201595#5989526, this just never got prioritized
This made the wishlist, so if I might make a suggestion - it might be useful to vote for it, and get further support from it, rather than change tasks from "task" to "bug report" which only serves to irritate people on a Friday morning with an unnecessary ping:
https://meta.wikimedia.org/wiki/Community_Wishlist_Survey_2022/Mobile_and_apps#Show_editnotices_on_mobile
I didn't ping anybody (other than Jdforrester), I just improved the description/categorization based on a statement from a WMF developer. I personally don't believe in voting on the wishlist, but I won't stop others.
Just been directed here, because of this problem, and want to emphasise the editorial value of fixing this.
A number of mistaken good faith edits have quite problematic outcomes- misgendering transgender people, misinformation, discredited but popular media information re-added. Often there isn't much one can do as an editor or administrator - it isnt an attack or vandalism, its just misinformed edits months apart by random people who don't know otherwise. So protection isn't really a help, and "locking down" tools are a bit heavyweight. It just needs a nudge to anyone editing. But because of this bug and move to mobile/app, this is not reliably possible to display, when editing.
So I'm having to do this instead which is spammy and less than ideal. But it mostly prevents upset BLP subjects coming back with yet another upset on the issue in some months' time, and lacking editnotice functionality, its the only suitable "editor nudging" method I have in my toolkit as an editor or administrator, that is appropriate and reliably works for this sort of BLP-upsetting but sporadic issue.
Please fix!!
Just been directed here, because of this problem, and want to emphasise the editorial value of fixing this.
A number of mistaken good faith edits have quite problematic outcomes- misgendering transgender people, misinformation, discredited but popular media information re-added. Often there isn't much one can do as an editor or administrator - it isnt an attack or vandalism, its just misinformed edits months apart by random people who don't know otherwise. So protection isn't really a help, and "locking down" tools are a bit heavyweight. It just needs a nudge to anyone editing. But because of this bug and move to mobile/app, this is not reliably possible to display, when editing.
So I'm having to do this instead which is spammy and less than ideal. But it mostly prevents upset BLP subjects coming back with yet another upset on the issue in some months' time, and lacking editnotice functionality, its the only suitable "editor nudging" method I have in my toolkit as an editor or administrator, that is appropriate and reliably works for this sort of BLP-upsetting but sporadic issue.
Please fix!!
Already done, all you need is an interface admin: https://en.wikipedia.org/wiki/User:Alexis_Jazz/EditNoticesOnMobile .
This doesn't seem to be a Minerva desktop problem, just mobilefrontend (xx.m.wikipedia.org type) - in that MFE doesn't integrate edit notices.