Usability issues:

• 
• The widget is not obviously scrollable, as most mobile devices do not show scrollbars. On mobile we would usually have a concatenated view, possibly with the content fading out at the bottom, with a "show more" button.
• The close button does not meet accessibility guidelines (click target size) nor does it match our style guide:
• The widget makes no attempt at re-styling the content, which isn't designed for narrow mobile devices, this leads to hard-to-read messages, and messages towards the bottom which are unlikely to get scroll to:
• 

Technical issues:

• The widget does not appear when launched from a section edit link other than the lede
• When editing the lede section in VE, we scroll past the infobox to the first paragraph, so the messages may never be seen
• VE carefully scrolls the read mode to the correct place so that when the editor loads there is a smooth transition and editors do not become disoriented. It is impossible to test this because of the bugs above, but I would imagine this would get broken by this feature.
• The widget is visible in the preview shown in the save dialog in source mode, almost completely hiding the preview (and maybe hiding it completely on a smaller device):
• 
• The widget is not visible after switching edit modes
• The widget is not visible in full page editing (#/editor/all), although this feature is not exposed in the interface yet

Without addressing a significant number of the above issues, I feel this feature will just disrupt the editing process with the vast majority of editors dismissing or ignoring the widget without reading it.

An implementation closer to what has been done on Android (T201597) would be far more likely to have an impact on editor behaviour, rather than just be a burden.

Wow, somebody should tell me about this task. You can't always rely on omnipresence, you know.

Wow, someone should tell us about the RFC. You can't always rely on omnipresence, you know. ;)

Peter is writing a response to the RFC that refers to the review above. We've posted it here publicly instead of in some private message because we're transparent like that, even though it is often inconvenient to be judged harshly for work in progress. We do appreciate people who check our work on Phabricator, though.

In T312299#8063864, @AlexisJazz wrote:

Wow, somebody should tell me about this task. You can't always rely on omnipresence, you know.

hi @AlexisJazz – if I were creating this task again, I'd be sure to make sure you were subscribed to it. I appreciate that it likely doesn't feel good to happen upon on it on your own. I'm sorry you had this experience.

At the same time, please know that we assume you are acting in good faith and I ask that you extend us the same courtesy.

With the above aside, as @matmarex mentioned above, tomorrow, you can expect a post from me in the RfC on-wiki that goes over what we – the Editing Team – are doing to make edit notices available to people editing on mobile as quickly, safely, and effectively as possible.

In T312299#8063925, @matmarex wrote:

Wow, someone should tell us about the RFC. You can't always rely on omnipresence, you know. ;)

Peter is writing a response to the RFC that refers to the review above. We've posted it here publicly instead of in some private message because we're transparent like that, even though it is often inconvenient to be judged harshly for work in progress. We do appreciate people who check our work on Phabricator, though.

Tell you about the RFC? Actually, Xaosflux pinged Jon Robson. So actually you were told about the RfC! (whether Jon passed on the message I don't really know, but that's your internal communication innit?) And if you're interested in that sort of thing, either keep an eye of proposal project pages (though across hundreds of projects that could be difficult) or literally tell the communities you want to be kept in the loop about this sort of thing so some method could be devised to keep you in the loop.

This task on the other hand is about reviewing a script - of which I am the author. Esanders said this:

Without addressing a significant number of the above issues, I feel this feature will just disrupt the editing process

Esanders, your feedback is very valueable to me (thank you!) and I actually am going to make improvements based on it, but I wish I had been made aware of this task right away. I found this 100% by accident and because I happen to be somewhat active here. Which isn't true for everyone.

In T312299#8063971, @ppelberg wrote:

In T312299#8063864, @AlexisJazz wrote:

Wow, somebody should tell me about this task. You can't always rely on omnipresence, you know.

hi @AlexisJazz – if I were creating this task again, I'd be sure to make sure you were subscribed to it. I appreciate that it likely doesn't feel good to happen upon on it on your own. I'm sorry you had this experience.

At the same time, please know that we assume you are acting in good faith and I ask that you extend us the same courtesy.

You've noticed yourself how this can come across. Finding a task with a bunch of subscribers and valueable feedback, but nobody told the author.

I don't assume bad faith, even though some on-wiki experiences could give me reason to, and somewhere in the back of my head the possibility will always cross my mind. Which isn't your fault, just stuff that happened.

What I do believe is that it's clumsy, or with a nicer word, suboptimal. When reviewing a script, the author(s) should be notified. If the script originates from a wiki, I'd recommend a user talk page message or a script talk page message. (if there is an active script talk page)

With the above aside, as @matmarex mentioned above, tomorrow, you can expect a post from me in the RfC on-wiki that goes over what we – the Editing Team – are doing to make edit notices available to people editing on mobile as quickly, safely, and effectively as possible.

Thank you.

Btw, as matmarex expressed interest, I'm hereby informing you about Bawl which, according to one review, "crushes DiscussionTools in every aspect" and according to another review is "the best-kept secret on Wikipedia". Still beta.

In T312299#8061699, @Esanders wrote:

Without addressing a significant number of the above issues, I feel this feature will just disrupt the editing process with the vast majority of editors dismissing or ignoring the widget without reading it.

An implementation closer to what has been done on Android (T201597) would be far more likely to have an impact on editor behaviour, rather than just be a burden.

Thank you for the detailed issues report!

I'm not a fan of popups as a general rule and tend to avoid them. But in this particular case, a popup is actually appropriate.

So, try again please.

The widget makes no attempt at re-styling the content, which isn't designed for narrow mobile devices, this leads to hard-to-read messages, and messages towards the bottom which are unlikely to get scroll to:

Almost forgot to respond to this! The best solution here would be if this "temporary measure" from 5 years ago by @Jdlrobson was canceled (so I no longer have to blindly murder every instance of nomobile) and apply nomobile sensibly.

The recent change fixes the usability issues round the messages being embedded in the page. The other issues remain. I also think the placement in the toolbar is not great, taking over the prime position of the save button:

Having had a chance to browse the code here are some more technical issues:

• The dialog "waits" for VE to load by repeatedly polling the DOM with a specific selector every 300ms (up to 15s) for the surface to become available, rather than listening to VE events. This is inefficient and fragile (could break if the DOM order changes).
• Because of the above, the edit notice popup shows immediately for logged out users, on top of the "anon warning" popup which prompts users to login. We should not show edit notices until the user has confirmed they don't want to log in. I'm not sure we emit any events at this point so it might be hard for gadget to fix this.
• Similarly the code is hooked up directly to edit link click events in the DOM, rather than editor initialisation events.
• Edit notices are fetched from ApiVisualEditor, paction=metadata. If VE is already loading it means this API call will unnecessarily be done twice.
• Edit notices are cached for 12 hours in local storage. I'm not sure this is necessary as we are making the API call for VE anyway. The source mode editor API calls could be extended to return edit notices (via $title->getEditNotices())
• JSON from local storage is parsed twice, the first time to see if there is an exception thrown. It need only be parsed once.
• The nomobile class is stripped using HTML string replacement, rather than DOM manipulation. This means nomobile in plain text would be removed. Although as noted elsewhere it would be better if this class was removed from the source template, rather than having to be removed here.

Features worth considering in a full implementation:

• Notices which load from the cache are not popped-up, this effectively means you only see one popup per 12 hours. Not showing the popup on subsequent loads seems like a good idea. This time limit could be extended if we ensure the popup is still shown if the list of edit notices changes at any point).

In T312299#8065839, @Esanders wrote:

The recent change fixes the usability issues round the messages being embedded in the page. The other issues remain.

Which ones exactly? Pretty sure I fixed most if not all of the issues you reported.

I also think the placement in the toolbar is not great, taking over the prime position of the save button:

Yeah, I agree, I'll prepend it instead.

Having had a chance to browse the code here are some more technical issues:

• The dialog "waits" for VE to load by repeatedly polling the DOM with a specific selector every 300ms (up to 15s) for the surface to become available, rather than listening to VE events. This is inefficient and fragile (could break if the DOM order changes).

I'm aware that's not exactly pretty, but how/where can I find out about VE events, or even events in general? I don't see them on my browser console for example.

• Because of the above, the edit notice popup shows immediately for logged out users, on top of the "anon warning" popup which prompts users to login. We should not show edit notices until the user has confirmed they don't want to log in. I'm not sure we emit any events at this point so it might be hard for gadget to fix this.

I had already noticed that. But then again: is this really undesirable? Anon thinks "You got it all wrong!", clicks edit, is greeted with a popup that says "Sorry to burst your bubble, but that's a myth, don't bother." and whether they'd even consider logging in or signing up becomes irrelevant.

• Similarly the code is hooked up directly to edit link click events in the DOM, rather than editor initialisation events.

Same as above, tell me where to find the documention of these events or how to detect them in a running browser. If I knew the name of one event I could maybe google it, but I don't.

• Edit notices are fetched from ApiVisualEditor, paction=metadata. If VE is already loading it means this API call will unnecessarily be done twice.

Um.. um.. when you say this, you do realize that.. you.. right? You know?

1. You are correct, there is an API call when opening VE on mobile that does in fact include edit notices. Which you are downloading, every single time VE is opened on mobile, for years, without having any interface to show them. You want to talk about waste?
2. I learned it from @Dbrant at https://phabricator.wikimedia.org/T201597#7409365. I really do wonder if the Android app isn't also making a redundant request.
3. How do I get access to the data from that request? You completely sandbox your stuff, making it hard to get anything in or out. I see many people struggling with this, for example https://phabricator.wikimedia.org/T1092#7964437 which had a worse solution before. It's probably good practice from a technical point of view, but for practical reasons I always ensure that effectively everything in my scripts can be accessed at any time. In this case for example, enter "enom" on the console and everything is just there.

• Edit notices are cached for 12 hours in local storage. I'm not sure this is necessary as we are making the API call for VE anyway. The source mode editor API calls could be extended to return edit notices (via $title->getEditNotices())

Um.. modifying the source mode editor API calls.. that's not something I can do. I can't even be certain my script is loaded at all before that API call happens. (if you visit a #/editor URL directly this can happen)

• JSON from local storage is parsed twice, the first time to see if there is an exception thrown. It need only be parsed once.

Presumably you're saying the validity check can return the JSON itself, or so I guess. I'll try. Wouldn't call that a showstopper though.

• The nomobile class is stripped using HTML string replacement, rather than DOM manipulation. This means nomobile in plain text would be removed. Although as noted elsewhere it would be better if this class was removed from the source template, rather than having to be removed here.

Yeah, some leftovers from previous hacks. The occurence of "nomobile" in plain text in an edit notice is really extremely unlikely.

Also, I suspect the string replacement is potentially faster than DOM manipulation. It probably no longer matters anyway, Xaosflux removed Jdlrobson's nomobile addition from enwiki so I'll be getting rid of any remaining references to nomobile.

Features worth considering in a full implementation:

• Notices which load from the cache are not popped-up, this effectively means you only see one popup per 12 hours. Not showing the popup on subsequent loads seems like a good idea.

Um... I'm sorry, but.. Why are describing exactly what EditNoticesOnMobile already does?

This time limit could be extended if we ensure the popup is still shown if the list of edit notices changes at any point).

Will need access to the data of that API call for that.

@Esanders

• I switched back to the smaller API parse request for now as the VE API request is actually massive due to its inclusion of content. If somebody explains how to get access to the notices VE already downloads and the API call for the source editor is modified to also includes notices (which is beyond the reach of a userscript) and it's also explained how to get access to that I could switch to that. By access I mean: just tell me what to enter in the browser console to have the object returned.
• The validity test returns the JSON now and it uses that.
• All references to nomobile have been removed.
• No more DOM polling. Replaced with ve.init polling (probably not ideal but beats DOM polling) and listening for a surfaceReady event.
• As a result the button vanishes now when switching editors, but how popular is revisiting notices anyway? And you said yourself at T312587#8065558 that users find it difficult to switch editors. It would be nice to fix it, but I don't consider this a showstopper. This was never meant to be more than an interim solution, and if we actually get a native solution sometime this calendar year we should be good IMHO. If somebody has pointers to fixing it I'll look, but I'd rather not spend many hours on a low priority issue if we'll soon-ish get a native solution. After a nap I realized what caused it. Solved.
• Button placement changed, no longer taking over the prime position of the save button
• style.background from editnotices gets emptied now. (not appropriate in a popup)
• Code is still "hooked up directly to edit link click events in the DOM, rather than editor initialisation events". First, I don't believe this a serious issue. It greatly improves transparency. I tried countless times on many occasions in different situations to figure out what code from the WMF does. It's open source, but when you look at it in a browser it's often closer to a black box. My scripts (not just this one) and various other user scripts are far more transparant in that sense, you can often see right through them. Second, I wonder what the issue is anyway. Maybe a theoretical performance gain, but I see such massive waste in other areas that if that's the issue it's penny wise and pound foolish. Third, unless there's some serious problem with it, it's plenty good enough for an interim solution. If some hints (or better yet, examples) could be given for the relevant events (and there's an actual advantage) I'll happily look into it though.
• "notice popup shows immediately for logged out users" remains unchanged, I think this is actually desirable behavior, we should tell the user we already know Goofy is not a cow before they potentially bother signing up or logging in.

Btw, I wonder what "[SPIKE]" in the title signifies on Phabricator. I've seen it here and there, but haven't seen like a legend anywhere.

Edit: to be clear, normally I'd be running harder to absolutely perfect my work, but after 5 years of a whole lot of nothing on this particular issue I suddenly see increased interest and some actual progress from WMF developers, making me think that maybe there'll be a native implemention somewhere this year. And if that's the case it doesn't make sense to invest loads of time in absolutely perfecting the interim solution, so that reduces my drive for perfection of the script. However: it must be safe, should not cause errors, should not hamper users in unexpected ways and should be a solid improvement over the current situation of no editnotices at all. I personally think it does meet those criteria.

I just remembered addEventListener('hashchange',function(){window.alert('foo')}) which could be another way, but I'd need to obtain the page title some other way in that case probably.

In T312299#8066006, @AlexisJazz wrote:

• The dialog "waits" for VE to load by repeatedly polling the DOM […], rather than listening to VE events. […]

I'm aware that's not exactly pretty, but how/where can I find out about VE events, or even events in general? I don't see them on my browser console for example.

The monitorEvents(document) function exists in browser devtools to monitor DOM events in the console.

The equivalent for mw.track is:

mw.trackSubscribe( '', console.log );

To find all mw.hook you can check doc.wikimedia.org for ones emitted by MediaWiki core, or Codesearch: mw.hook across deployed extensions.

Thanks!

After some updates the button comes back now after switching editors.

I've searched but could not find any usable events for the mobile source editor. The only event I see with Krinkle's code is mf.schemaEditAttemptStep which triggers multiple times and also when closing the editor. Maybe I can use it anyway, not sure, I'll have to try. Currently the script uses a dumb 1s wait.

At <767px screen width the button to revisit the edit notice is hidden. (CSS rule adapted from when button labels are hidden)

I could swap out lz-string for pako. But pako is some 12.5K heavier than lz-string. (after min and gzip) It'd do a better job at compressing the localStorage and faster too. T235237 / T312720 aren't a reality yet.

Realistically if I did that I would uncouple the event listeners from the rest of the script. Currently the script is ~4K after min and gzip. Splitting it would somewhat complicate development and testing, add network overhead for anyone who presses "edit" and possibly increase the likelihood of the main script falling out of cache. And as I'd probably swap out lz-string for pako in this case the main script would grow significantly.

On the other hand, the download for non-editors would shrink several K. If the WMF devs would consider this a good tradeoff I'll look into this. Bear in mind though that this solution was always meant to be an intermin solution. Decoupling is not a small ask.

Edit: I tried the mf.schemaEditAttemptStep event, doesn't seem to work for this purpose. Instead I now try to add the button three times with different delays. If the button is already there it doesn't get added again.

hi @AlexisJazz – per the task description, we plan to publish a summary of the discussion and progress made in this ticket in the en.wiki RfC so that volunteers can decide on next steps with this information in mind.

Before doing that, I wonder: would you be up for reviewing a draft of what we're planning to post so that you can A) point out anything I might've omitted, misunderstood, etc. and B) respond – if you'd like – to the two usability concerns we've identified? I've included this draft below.

Ideally, we'd be able to publish a version of the draft I've shared below before 1:00am UTC tomorrow, 14 July. Although, if you are willing and able to review the draft and would value more time, please let me know and I'll make a quick post on en.wiki informing people that the response we planned to share, will be a bit delayed.

Regardless of whether you decide to review what's below or not, we appreciate you responding to, and addressing, many of the concerns raised in T312299#8061699 and T312299#8065839.

EditNoticesOnMobile.js Investigation

Technical Review
The Editing Team did not identify any significant technical issues (e.g. introducing errors, creating new vectors for abuse, or degrading performance) within the gadget that we think would warrant blocking it being deployed in the time between now and when the Editing Team implements the longer-term solution we are working on in T312587.

User Experience Review
The Editing Team has concerns about two aspects of the user experience the EditNoticesOnMobile.js gadget introduces.

• The gadget causes the edit notices to cover the entirety of the editing interface at phone-size screen widths. We are concerned that completely obfuscating the content in this way will cause good faith volunteers to become disoriented and abandon the edit they initiated the editor seeking to make. We also worry that people seeking to make edits across multiple pages in quick succession will tire of the editing interface being gated behind a dialog and could contribute to them completing fewer edits than they otherwise would have.
• The gadget causes edit notices to appear before the anon dialog/warning is presented. This is concerning to us because we think that the first thing people ought to decide before investing any additional time into an edit is whether they are comfortable with their IP address being publicly visible to others.

@ppelberg thank you!

We might need slightly more time.

For the first part of the first issue:

• It's an OO.ui.alert('edit notice goes here',{size:'larger'});. I've considered the issue, at the same time, if a user insists on using a phone in portrait mode, what is the lesser evil here? Having no border but a message that can be read more comfortably or having a border so it's clear you're dealing with a popup but potentially at the cost of being able able to read it comfortably? Also, might this be an issue with OO.ui.alert itself? Either way I have no overly strong feelings about this, if you can suggest some more appropriate parameters for OO.ui.alert I'll most probably use those. Keep in mind though that some edit notices are big (IMHO often too big, but improving that has to be a community effort) so simply switching to "small" won't do. I see no "force windowed" option on OO.ui.MessageDialog-method-getSetupProcess but maybe I overlooked it.

For the second part of the first issue: (this should have been a separate bullet point maybe?)

• Please note that pages that don't have a notice shouldn't be getting a popup at all. I've also encouraged the community to consider using the nomobile class in notices where appropriate and review the content of edit notices in general: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Considerations_for_edit_notices_on_mobile
• I just added (but this hasn't been synced to the MediaWiki namespace yet, only in the userspace version right now) a check for any elements with the "nopopupnotice" class in the edit notice. If found, the popup is suppressed but the button to open the notice is still added, it's treated like a cached notice. This should be useful for edit notices that are informative in nature and don't contain warnings. (see also T312999)
• Also not synced yet: the cache expiry is now configurable for veterans by specifying "enomCacheExpiry" in their common.js as a number of ms to hold on to notices. So one could set that to 691200000 (8 days) so if a page is edited with 1-week intervals the notice won't show if unchanged. This isn't useful for non-technical users, but at least it's there if someone feels like it's driving them mad.
• Users who are logged in can disable the gadget in Special:Preferences.

For the second issue:

• Accepting your IP to be visible isn't the only option there. While it depends on the page/notice in question, I think we shouldn't let users potentially go through the trouble of signing up (captcha!)/logging in and only tell them after all this that whatever they planned to add isn't welcome. Do you know how many times I visited a website, was told I had to sign up to view the link in question, only to be served a 404 once I did?

If the community shares the concern that "The gadget causes edit notices to appear before the anon dialog/warning is presented" there is now some code (only in the userspace version) that can be uncommented to make the popup appear when the "Edit without logging in" button is pressed. Personally I think the current behavior is better, but if somehow this would be perceived as a problem that code can be uncommented.

In T312299#8076305, @AlexisJazz wrote:

We might need slightly more time.

Agreed and sounds good to me, @AlexisJazz.

I've posted a message in the en.wiki RfC informing folks that we're talking here and that we'll post a summary of this discussion once we figure out whether it's possible to control the size of the OO.ui.alert dialog so that it doesn't cover the entire editing interface for people editing on a phone, in portrait mode.

In the meantime, some comments below...

For the first part of the first issue:

• It's an OO.ui.alert('edit notice goes here',{size:'larger'});. I've considered the issue, at the same time, if a user insists on using a phone in portrait mode, what is the lesser evil here? Having no border but a message that can be read more comfortably or having a border so it's clear you're dealing with a popup but potentially at the cost of being able able to read it comfortably? Also, might this be an issue with OO.ui.alert itself? Either way I have no overly strong feelings about this, if you can suggest some more appropriate parameters for OO.ui.alert I'll most probably use those. Keep in mind though that some edit notices are big (IMHO often too big, but improving that has to be a community effort) so simply switching to "small" won't do. I see no "force windowed" option on OO.ui.MessageDialog-method-getSetupProcess but maybe I overlooked it.

Understood. It's helpful to hear what approaches you've considered and the decisions you've made that have led to the current implementation.

Maybe @matmarex and @Esanders have ideas for how the size of the OO.ui.alert can be constrained...

For the second part of the first issue...

• Please note that pages that don't have a notice shouldn't be getting a popup at all. I've also encouraged the community to consider using the nomobile class in notices where appropriate and review the content of edit notices in general: https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(technical)#Considerations_for_edit_notices_on_mobile

Understood.

• I just added (but this hasn't been synced to the MediaWiki namespace yet, only in the userspace version right now) a check for any elements with the "nopopupnotice" class in the edit notice. If found, the popup is suppressed but the button to open the notice is still added, it's treated like a cached notice. This should be useful for edit notices that are informative in nature and don't contain warnings. (see also T312999)

Assuming edit notices that contain the "nopopupnotice" class are relatively common, it sounds like the check you added will lower the likelihood of people seeking to make edits across multiple pages in quick succession running into pages that are gated behind a dialog. Nice idea.

• Also not synced yet: the cache expiry is now configurable for veterans by specifying "enomCacheExpiry" in their common.js as a number of ms to hold on to notices. So one could set that to 691200000 (8 days) so if a page is edited with 1-week intervals the notice won't show if unchanged. This isn't useful for non-technical users, but at least it's there if someone feels like it's driving them mad.

Understood. As you mentioned, I don't think this fully resolve the concern we named. Tho, it does give a segment of people a way around it.

• Users who are logged in can disable the gadget in Special:Preferences.

Understood.

For the second issue:

• Accepting your IP to be visible isn't the only option there. While it depends on the page/notice in question, I think we shouldn't let users potentially go through the trouble of signing up (captcha!)/logging in and only tell them after all this that whatever they planned to add isn't welcome. Do you know how many times I visited a website, was told I had to sign up to view the link in question, only to be served a 404 once I did?

I hear the perspective you are representing here. Tho, I continue to think presenting the edit notice after the IP dialog provides people with a better experience.

With the above said, I agree with what you proposed in T312299#8076714: inviting people in the RfC to weigh in on this.

In T312299#8076824, @ppelberg wrote:

Assuming edit notices that contain the "nopopupnotice" class are relatively common, it sounds like the check you added will lower the likelihood of people seeking to make edits across multiple pages in quick succession running into pages that are gated behind a dialog. Nice idea.

That functionality is an original idea so right now this moment there are zero, bupkis, nada, zilch, diddly-squat.

Which is why I created T312999 to ask the Android app developers to either implement the same or suggest something better. I think I'll wait for their answer before I start making edit requests to get that class added to existing notices. First candidate for me would be https://en.wikipedia.org/wiki/Template:Editnotices/Namespace/File. Pops up for every file description page and file pages are actually something one might edit in quick succession.

For such notices I actually did consider not showing a notice if the same notice is cached for another page. However, that's not a good idea: if there is, for example, some ArbCom ruling that affects a group of pages and they all receive the same edit notice, it actually should popup once for every single one of those pages as otherwise you can't reasonably know which exact pages are covered by that ruling.

Understood. As you mentioned, I don't think this fully resolve the concern we named. Tho, it does give a segment of people a way around it.

Did the introduction of popup edit notices in the Android app have any significant effect in this area? If it did, what did they do about it?

Users can now also define window.EnomNeverPopup as true in their common.js to treat every notice as if it's cached which is less drastic than disabling the gadget entirely. For this as well: not useful for non-technical users, but gives a segment of users the ability to customize the behavior.

@ppelberg: please have one more look, also at the source. I swapped out some delays for MutationObserver. The OO.ui.alert has been swapped out for an OO.ui.confirm which is essentially the same as the alert, but when a notice is revisited (using the alert button) it gets an extra button to disable automatic popups.

If the user decides to do this there are two confirmation popups before it's accepted. You've seen the response to the RfC and the wishlist entries, I couldn't make it too easy. But it is generally accessible (no need to mess around with common.js) so your concern of users editing less should be at least somewhat alleviated.

In T312299#8076896, @AlexisJazz wrote:

In T312299#8076824, @ppelberg wrote:

Assuming edit notices that contain the "nopopupnotice" class are relatively common, it sounds like the check you added will lower the likelihood of people seeking to make edits across multiple pages in quick succession running into pages that are gated behind a dialog. Nice idea.

That functionality is an original idea so right now this moment there are zero, bupkis, nada, zilch, diddly-squat.

Oh, I see!

Which is why I created T312999 to ask the Android app developers to either implement the same or suggest something better. I think I'll wait for their answer before I start making edit requests to get that class added to existing notices. First candidate for me would be https://en.wikipedia.org/wiki/Template:Editnotices/Namespace/File. Pops up for every file description page and file pages are actually something one might edit in quick succession.

Understood. I've also added an open question to T312587 as reminder for us to decide whether to build this kind of functionality as part of the implementation we'll be working on.

For such notices I actually did consider not showing a notice if the same notice is cached for another page. However, that's not a good idea: if there is, for example, some ArbCom ruling that affects a group of pages and they all receive the same edit notice, it actually should popup once for every single one of those pages as otherwise you can't reasonably know which exact pages are covered by that ruling.

Agreed and this makes sense. I appreciate you sharing the thought behind this decision. I hadn't considered the ArbCom ruling case.

Understood. As you mentioned, I don't think this fully resolve the concern we named. Tho, it does give a segment of people a way around it.

Did the introduction of popup edit notices in the Android app have any significant effect in this area? If it did, what did they do about it?

I'm not sure. Tho, I will check with the Android Team and share what I learn.

In T312299#8080015, @AlexisJazz wrote:

@ppelberg: please have one more look, also at the source. I swapped out some delays for MutationObserver. The OO.ui.alert has been swapped out for an OO.ui.confirm which is essentially the same as the alert, but when a notice is revisited (using the alert button) it gets an extra button to disable automatic popups.

If the user decides to do this there are two confirmation popups before it's accepted. You've seen the response to the RfC and the wishlist entries, I couldn't make it too easy. But it is generally accessible (no need to mess around with common.js) so your concern of users editing less should be at least somewhat alleviated.

Is there anything I need to do to the script I've saved to en:User:PPelberg_(WMF)/common.js in order to try out the changes you're referring to above? It'll be easier for me to understand what you're saying by trying it out for myself, if possible.

Meta: Posting an update in the en.wiki RfC
Tomorrow, I'm planing to post a summary of the discussion we've had here as well as the plans we have for T312587.

I'm going to ping you in the message I post so that you have an opportunity to fill in anything I might've missed.

If anything about the plan above is concerning to you, please let me know.

In T312299#8080135, @ppelberg wrote:

In T312299#8080015, @AlexisJazz wrote:

@ppelberg: please have one more look, also at the source. I swapped out some delays for MutationObserver. The OO.ui.alert has been swapped out for an OO.ui.confirm which is essentially the same as the alert, but when a notice is revisited (using the alert button) it gets an extra button to disable automatic popups.

If the user decides to do this there are two confirmation popups before it's accepted. You've seen the response to the RfC and the wishlist entries, I couldn't make it too easy. But it is generally accessible (no need to mess around with common.js) so your concern of users editing less should be at least somewhat alleviated.

Is there anything I need to do to the script I've saved to en:User:PPelberg_(WMF)/common.js in order to try out the changes you're referring to above? It'll be easier for me to understand what you're saying by trying it out for myself, if possible.

Replace what you copied with {{subst:User:Alexis Jazz/EditNoticesOnMobile.js}}?

Or try:

• https://commons.m.wikimedia.beta.wmflabs.org/wiki/User:AJ/Sandbox4?withgadget=EditNoticesOnMobile#/editor/all (has "nopopupnotice" class)
• https://commons.m.wikimedia.beta.wmflabs.org/wiki/User_talk:AJ/Sandbox4?withgadget=EditNoticesOnMobile#/editor/all
• https://commons.m.wikimedia.beta.wmflabs.org/wiki/User:AJ/Sandbox5?withgadget=EditNoticesOnMobile#/editor/all

---

Meta: Posting an update in the en.wiki RfC
Tomorrow, I'm planing to post a summary of the discussion we've had here as well as the plans we have for T312587.

I'm going to ping you in the message I post so that you have an opportunity to fill in anything I might've missed.

If anything about the plan above is concerning to you, please let me know.

Sounds good. :-)

The RfC to enable the EditNoticesOnMobile gadget by default on English Wikipedia has passed. Deployment details are now being discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile.

In T312299#8081388, @AlexisJazz wrote:

The RfC to enable the EditNoticesOnMobile gadget by default on English Wikipedia has passed. Deployment details are now being discussed on https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile.

@AlexisJazz: Thank you for making us aware of the outcome and for sharing the concerns we've been talking about in the this ticket in the resulting on-wiki discussion [i][ii].

Next week, you can expect an update from us about:

1. The OO.ui.alert question we were talking about in T312299#8076824
2. The plan we have for building and deploying a "native" mobile edit implementation

I'm going to post a message about this on-wiki as well.

i. The edit notice being presented as full-screen when using a phone in portrait mode
ii. The edit notice being presented before the anoneditwarning

Maybe @matmarex and @Esanders have ideas for how the size of the OO.ui.alert can be constrained...

When you use OO.ui.alert(), the default size is 300px, you're currently overriding it to be wider by using size:'larger'. At 300px this wouldn't usually be a problem. But there's currently no way to make it wider than that without it becoming fullscreen when it would exceed the width of the screen.

In T312299#8082183, @matmarex wrote:

Maybe @matmarex and @Esanders have ideas for how the size of the OO.ui.alert can be constrained...

When you use OO.ui.alert(), the default size is 300px, you're currently overriding it to be wider by using size:'larger'. At 300px this wouldn't usually be a problem. But there's currently no way to make it wider than that without it becoming fullscreen when it would exceed the width of the screen.

300px ain't gonna cut it for edit notices. Unless that's the size of your screen, but if you have more room (landscape mode, big phone, tablet) the window should be bigger. It's okay if it would always be constrained to a window (never becoming "full"), but apparently that's not an option without the window having an absolute size.

If this is perceived as an issue (and it seemingly is), I'd say it's an OO.ui issue. I specifically swapped out the 2010 Wikitext editor-like inline div for an OO.ui dialog to essentially guarantee accessibility for the dialog. See T313140.

It really should cut it, because that's the size of screen of real devices used by real users. If the notices on en.wp are not suitable for mobile devices, then they should be adjusted. In desktop VE, we show notices in a 320px popup and in my experience for the most part that works just fine (I've seen some bad ones, but they're a minority).

In T312299#8082415, @matmarex wrote:

It really should cut it, because that's the size of screen of real devices used by real users. If the notices on en.wp are not suitable for mobile devices, then they should be adjusted. In desktop VE, we show notices in a 320px popup and in my experience for the most part that works just fine (I've seen some bad ones, but they're a minority).

It really shouldn't. Edit notices are often warnings. They shouldn't be teeny-tiny on larger screens.

But hey, I fixed it! So there's another concern to cross off your list.

I shouldn't have had to fix it.

EditNoticesOnMobile now stores CRC32 checksums of edit notices in localStorage and only keeps the notice text itself for 2 hours instead of 48 hours. This made sense because the notice was only served from cache without an API request if it was less than 2 hours old. The checksums are stored for 2 weeks as they are much smaller. So unchanged notices can be detected for 2 weeks now instead of 2 days.

@ppelberg as the RfC to enable EditNoticesOnMobile was closed I'd suggest you create (if you still think it's important) a new RfC to make the edit notice show after the anoneditwarning. If the feedback from testing would indicate this should be done I may change the behavior myself. I don't count on feedback on this topic though.

Btw, is the anoneditwarning always displayed? Or could it be skipped, like after a successful edit? I don't want to make anon edits myself so I can't test. The code which could be uncommented to change the behavior (if the community shares that concern) assumes the anoneditwarning is always shown.

FYI: English Wikipedia is getting ready to start enabling the javascript gadget for users as opt-out, in waves (by user groups, anons will be last). If there are any significant blocking items please let us know at https://en.wikipedia.org/wiki/Wikipedia_talk:EditNoticesOnMobile#Getting_ready_for_launch as soon as possible.