In fact it behaves very unpredictably, see e. g. this screenshot, where it intruded the notes section dedicated to notes concerning the transcribed work,

or this screenshot, where it even intruded inside a proofread work:

{F59721684}

I am just reminding that Wikisource editors are very sensitive to anything that interferes with the original contents and layout of the transcribed work. I suggest moving it into a banner above the contents of the page.

In general, hacks like in T118475 can't work for all projects; what does it cost to just make it a banner? or at least, there could have been be deployment warnings or opt-outs. If this is only meant for wikipedia, then don't force it on every other project.

Other equally absurd insertion, here at WD (popping up in the middle of a statement):

@jsn.sherman, @YLiou_WMF

QuickSurveys appear in the middle of namespace 0 article text body.

The community wishes the article to remain readable and not to be disrupted or interrupted by QuickSurveys.

Solution possible: QuickSurveys can appear above or below the article.

See https://de.wikipedia.org/wiki/Wikipedia:Administratoren/Anfragen#Umfrage_wird_im_Flie%C3%9Ftext_eingeblendet for big discussion related to the problem.

@doctaxon: Why ping random folks?

@Aklapper They are not random but the survey deployers.

@Alien333 Thank you for reporting this issue. This is certainly not how surveys are supposed to appear. When I tried to reproduce and troubleshoot this issue by manually firing the survey prompt, I found that surveys are currently disabled somehow on en wikisource. When I looked at the deployment configuration, it still looks deployed. I'm not sure what to make of that. Do you have a quicksurveys section in your preferences page under the user profile section?

https://en.wikisource.org/wiki/Special:Preferences#mw-prefsection-personal
I am able to see this on other wikis where we've deployed surveys, but not on wikisource.

@jsn.sherman If you are looking for Extension:QuickSurveys at ENWS, I do not see it on the ENWS Special:Version page which lists all installed MW extensions, so I do not think it is actually deployed there. I also do not see it at MULWS Special:Version or DEWS Spezial:Version.

Here is further evidence that the extension is not deployed: ENWS load.php?modules=ext.quicksurveys.lib&debug=true

mw.loader.state({"ext.quicksurveys.lib":"missing"});

As this is an obvious user harassment issue, I added this to Trust and Safety Team which took over Anti-Harassment Tools where SecurePoll issues where addressed in 2021, see Anti-Harassment Tools/SecurePoll Improvements.

I also added the Web-Team which claim to own the extension as this might be an issue with their extension.

In T393436#10920154, @jsn.sherman wrote:

@Alien333 Thank you for reporting this issue. This is certainly not how surveys are supposed to appear. When I tried to reproduce and troubleshoot this issue by manually firing the survey prompt, I found that surveys are currently disabled somehow on en wikisource. When I looked at the deployment configuration, it still looks deployed. I'm not sure what to make of that. Do you have a quicksurveys section in your preferences page under the user profile section?

Many complaints were made by different users about how it barged in page content, and we did see it in our preferences. I suppose it was deployed and then removed (thanks to whoever removed it).

@jsn.sherman it looks you have yourself removed quicksurveys from ENWS two weeks ago: diff. Thank you for that. Please do not redeploy surveys until this issue is fixed.

@Uzume I understand the sentiment but this is not a user harassment issue rather a bug that will be fixed by the team(s) responsible for the feature. Untagging ourselves. Thanks.

@jsn.sherman QuickSurvey box is in the middle of namespace 0 page content text body. The best is to put it in the banner on top of the article into the banner body or below the article text body. See screenshot

The quick survey box is packed in div class="ext-quick-survey-panel panel panel-inline visible ext-quick-survey-undefined no-font-mode-scale"

In T393436#10921754, @Alien333 wrote:

@jsn.sherman it looks you have yourself removed quicksurveys from ENWS two weeks ago: diff. Thank you for that. Please do not redeploy surveys until this issue is fixed.

Okay, Thank you for that. I got a little mixed up as we deployed this survey in two rounds and I was fielding issues with the 2nd round as this came in.

In T393436#10922159, @doctaxon wrote:

@jsn.sherman QuickSurvey box is in the middle of namespace 0 page content text body. The best is to put it in the banner on top of the article into the banner body or below the article text body. See screenshot

The quick survey box is packed in div class="ext-quick-survey-panel panel panel-inline visible ext-quick-survey-undefined no-font-mode-scale"

Thanks for that. To be clear, I'm not one of the maintainers of the quicksurveys extension, but I do want to help get this written up in a way that is most likely to solve the problem. We are kind of talking about two related, but different, things in this thread.

• The quicksurvey panel sometimes breaks / occludes content layout - problem
• A request to change where the survey is inserted into the page markup - requested solution

I would suggest that we focus on the problems first before trying to choose a solution since any solution will have tradeoffs that need to be evaluated. The proposed solution would certainly fix the reported issue, but would likely come with it's own layout issues that would need to be addressed.

@Alien333
I would be happy to create a parent task for quicksurveys layout bugs. We could attach this task for wikisource and then add other layout bugs as child tasks as well. This would help the maintainers come up with a solution that best addresses layout issues in total.

I changed the title to reflect the reality of the issue.

In T393436#10924092, @Trizek-WMF wrote:

I changed the title to reflect the reality of the issue for Wikisource

The new title describes the specific issue for Wikisource, but not the other examples (Wikidata, German Wikipedia) mentioned in this task, where users also asked to put the survey box outside the page content

@Trizek-WMF : I oppose the rescoping of this task, for the following reason: as I said above, it is absurd to hope to catch the edge cases for the thousand-ish projects individually one by one, like you did for one in T118475. QuickSurveys just should not be in a place where there is also page content.

In T393436#10925684, @Johannnes89 wrote:

In T393436#10924092, @Trizek-WMF wrote:

I changed the title to reflect the reality of the issue for Wikisource

The new title describes the specific issue for Wikisource, but not the other examples (Wikidata, German Wikipedia) mentioned in this task, where users also asked to put the survey box outside the page content

That's why I changed the issue title a little bit.

In T393436#10921857, @Niharika wrote:

@Uzume I understand the sentiment but this is not a user harassment issue rather a bug that will be fixed by the team(s) responsible for the feature. Untagging ourselves. Thanks.

That is an interesting determination that is the exact opposite of what was determined for SecurePoll which proactively sought help from Anti-Harassment Tools before deployment.

In T393436#10924092, @Trizek-WMF wrote:

I changed the title to reflect the reality of the issue.

Your change, in addition to narrowing to just Wikisource (which has already been commented on by others), also seems to imply it is alright to impede on page content so long as there is an acceptable workaround for the observed "shrinkage" but I do not think it is okay for polls and surveys to impede on such main content to begin with. I am not saying there is no place for such things but they should be injected into the surrounding UI not the content. The UI is translated based upon user preference, the main content in general is not (there are a few multilingual exceptions like Commons but such things are known to cause performance issues and should be avoided). Short of being annoying and more cumbersome for people to accomplish tasks, why would anyone want to inject such things into the main content to begin with?

I frankly see polls and surveys being injected in the the main content as a user harassment issue as that is not how things have been done in the past. It can be compared to other forms of vandalism that attack the main content of WMF projects. I am opposed to WMF deploying any extensions that allow and condone such behavior even if they were created and developed in good faith. We have enough tools that do such things for the benefit of editors (content developers) that can be abused and need to be monitored/moderated with permissions and the like; why add another one that can be so easily and badly abused to begin with?

@ovasileva : I'm a bit curious: why did you remove web team? The extension page on mw says "This extension is maintained by the Web team", so I would expect that it is also the team that should fix this problem in the extension.

@Alien333: If a team does not plan to work on something, then the team tag should be removed so the valid open task does not show up in the team backlog.
Not everything that gets reported will get fixed by a WMF team, that's just unrealistic.

In this very case, Reader Experience Team was added. So probably https://www.mediawiki.org/wiki/Developers/Maintainers needs an update at some point.

In T393436#10955080, @Alien333 wrote:

@ovasileva : I'm a bit curious: why did you remove web team? The extension page on mw says "This extension is maintained by the Web team", so I would expect that it is also the team that should fix this problem in the extension.

As of today, July 1, the web team will now become two teams the Reader Experience Team, and the Reader Growth team. We'll be updating the Maintainers page promptly

I've updated the Maintainers page to reflect the new team structures.
@Samwalton9-WMF It looks like this bug has surfaced due to T381984 Patroller tools survey.

@Uzume I can appreciate the need for maintaining content integrity, but I don't think it's reasonable to describe this issue as harassment. The QuickSurvey extension is used for legitimate research purposes to order to gather community feedback on how to improve Wikimedia projects, in this case, for volunteers with patroller privileges.

I am not saying there is no place for such things but they should be injected into the surrounding UI not the content.

I agree that this should be possible and it may be worth configuring this on a per-project basis. The code that injects the survey is very brittle so this would require some refactoring, but it's worth considering if other WMF teams are planning on running surveys on non-Wikipedia projects.

Looking into this some more, it appears that it is possible to inject a quickSurvey onto a customizable element, via the embedElementId configuration option.

embedElementId - When this field is present, the survey can only be injected into a page with a DOM element matching the configured value by ID. For example, a survey with embedElementId: "survey-embed-point" will be displayed on a page with HTML <div id="survey-embed-point"></div>, immediately after that element.

@jsn.sherman I think we can look at injecting the survey into a different DOM element, using that config option, as a potential solution here. I'm not sure where exactly that would be though, It could vary per-project. We could potentially add an element like that at the skin level as well if necessary.

In T393436#11030318, @Jdrewniak wrote:

Looking into this some more, it appears that it is possible to inject a quickSurvey onto a customizable element, via the embedElementId configuration option.

embedElementId - When this field is present, the survey can only be injected into a page with a DOM element matching the configured value by ID. For example, a survey with embedElementId: "survey-embed-point" will be displayed on a page with HTML <div id="survey-embed-point"></div>, immediately after that element.

@jsn.sherman I think we can look at injecting the survey into a different DOM element, using that config option, as a potential solution here. I'm not sure where exactly that would be though, It could vary per-project. We could potentially add an element like that at the skin level as well if necessary.

I think that sounds very reasonable.

Thinking out loud: I could see setting up a config var that maps skins at the top level, so that a different parent could be defined for each skin. The embed point could be inserted into the parent via javascript at initialization time and fire a hook for the vue app to then mount. I haven't looked at the code in a while, so I don't know if that makes sense or not.

In T393436#11028957, @Jdrewniak wrote:

@Uzume I can appreciate the need for maintaining content integrity, but I don't think it's reasonable to describe this issue as harassment. The QuickSurvey extension is used for legitimate research purposes to order to gather community feedback on how to improve Wikimedia projects, in this case, for volunteers with patroller privileges.

I am not saying there is no place for such things but they should be injected into the surrounding UI not the content.

I agree that this should be possible and it may be worth configuring this on a per-project basis. The code that injects the survey is very brittle so this would require some refactoring, but it's worth considering if other WMF teams are planning on running surveys on non-Wikipedia projects.

I am sure every advertiser considers their advertisements to be used for legitimate purposes in order to gather feedback from would-be viewers but if you are blanketing groups of people that haven't opted-in for such things and placing such in places where it is not expected, that is basically the definition of harassment.

I assure you I have not opted-in for such things to be injected into the main content of WMF sites. And though I expect some announcements/advertisements in the UI for things like annual donation requests etc., I certainly do not expect them within the main content block and doing so likely messes up quite a few pages/sites since the injection and the content do not align.

If you inject it into the UI elements, I have no real qualms with that as they are pretty much known to be stuff that is outside the main content. If you persist in trying to inject it into the main content, I am going to consider it harassing advertising and recommend site administrators find ways to "deal" with it. For example, if you inject it into an element with id=survey-embed-point and that is an element within the content, I will recommend administrators place such an element and then hide it or somehow otherwise find a way to deal with such problems.

I still recommend you follow the example of SecurePoll. It also solicits user feedback and does not cause such issues.

@jsn.sherman : supported, yes, but not mandatory: there are still surveys that barge into page content.

Therefore the point of this task still stands: such surveys should not exist, because they break on-wiki content.

Also, embedding is only supported on internal survey types, it should probably support external surveys as well.

Change #1180614 had a related patch set uploaded (by Jsn.sherman; author: Jsn.sherman):

[mediawiki/extensions/QuickSurveys@master] [WIP] Enhance survey embed flexibility

https://gerrit.wikimedia.org/r/1180614

Change #1193925 had a related patch set uploaded (by Jdlrobson; author: Jdlrobson):

[mediawiki/extensions/QuickSurveys@master] Allow project-level customization of surveys

https://gerrit.wikimedia.org/r/1193925