Andrew Gray, 30/04/2014 21:47:
It's certainly simpler to implement, but anything that involves on-wiki recording has two main problems:
- friction in saving the entry (eg edit conflicts, login required,
user IP blocked)
Edit conflicts are supposed to be avoided, when appending text to a page via API. Please file a bug if this is not working, we have some reports but they're all quite incomplete. The rest may skew a survey from a scientifical point of view, but won't significantly spoil a simple collection of comments IMHO.
- privacy problems (comments are public and effectively attributed)
On the other hand you don't have to worry about private data, you're left only with public data. Of course users need to be informed.
This isn't much of an issue for things like "please give us feedback on the new fancy upload tool" - where everyone can be expected to have a functioning account and aware of how the wiki works,
Sure. In fact the goal is «capture user feedback about Upload Wizard as soon as they have completed their upload, while it’s still fresh on their minds» and that's exactly what mediawiki.feedback.js does currently within Special:UploadWizard, just not very prominently. (Even MoodBar does/did that I suppose.)
but if you're going to be gathering feedback on reader-focused things it breaks down.
True. However the surveys we're talking about here are in the order of 10³ respondents. It's a lot compared to e.g. the few hundreds per year in http://vs.aka-online.de/cgi-bin/wppagehiststat.pl?lang=commons.wikimedia&page=Commons:Upload_Wizard_feedback, but not so explosive. pl.wiki's http://vs.aka-online.de/cgi-bin/wppagehiststat.pl?lang=pl.wikipedia&page=Wikipedia:Zgłoś_błąd_w_artykule, fed by a popup in sidebar, seems to work well.
Nemo