Talk:Article feedback/Version 5/Testing

Welcome to our testing discussion page for the Article Feedback v5 project!

If you have any general questions or suggestions about this release of Article Feedback, you are welcome to post a comment on this discussion page. We will respond as soon as we can.

To report a bug, please post it here on Bugzilla.

Pressing enter still does not work

•  Done When I enter a comment ("add note") and I press enter the page reloads and my comment is not saved. I'm pretty sure this way mentioned before. My current browser is Opera.
•  Done The question mark in the "Activity Log" does nothing. Please remove it.
• Why can I click "no reason given"? I can not provide a reason there. It is just another link to the activity log. Why do we need multiple links for that?
• The link in "Marked as resolved by 31.212.178.10" in the right column leads to the non-existing user page. In most cases such links lead to the contributions page for that unregistered user.

--TMg 17:40, 15 February 2013 (UTC)

"no reason given": If you can add a note there should be a link "Add note" next to it. If theres a note "Read note" will be displayed.--Se4598 (talk) 22:32, 15 February 2013 (UTC)

Good point. We plan to remove "no reason given" altogether, as you suggest. Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)

"Marked as resolved by 31.212.178.10": Only registered users can resolve/mark useful/... feedback. But because feedback was imported from enwiki and the users didn't exist in this installation, Mediawiki displays the associated IP-adress. So normally IPs will never be appear in the messages, only registered Users--Se4598 (talk) 22:32, 15 February 2013 (UTC)

Se4595 is right, this is a temporary artifact caused by the import of comments from En-wiki, for testing purposes. Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)

Thanks, TMg, for testing the tool and posting your comments here -- and many thanks to Se4598 for answering some of TMG's questions! I have responded to some of these comments, both above and below.

• Pressing 'Enter' doesn't work when I add a note: Good point, which I have reported to our developer. Thanks!

• Question mark in "Activity Log" doesn't work: Duly noted. We'll remove it as you suggest.

Much appreciated! Fabrice Florin (WMF) (talk) 22:58, 20 February 2013 (UTC)

Hiding feedback without oversight?

Previously hidden feedback was hidden for editors. Now there only the inappropriate-option and the post will be still visible to editors. How administrators should deal with feedback that should be hidden for most users but is not serious enough to be normally oversighted? for example en:WP:Article Feedback/Feedback response guidelines#Hiding and unhiding feedback H1, H4, H5--se4598 (talk) 22:43, 15 February 2013 (UTC)

Thanks for bringing this up, Se4598!

To broaden the pool of moderators, the new 'Inappropriate' tool is now available to all editors, and we do not think there is a need for a separate 'hidden' category, besides this 'inappropriate' category. The rationale is that there is such a large amount of 'inappropriate' feedback that it would overwhelm monitors if they were the sole gatekeeper for this tool. We'd like to keep it that way, but are asking other colleagues and community members for their thoughts on this point.

We would also like to remove the gray mask that used to be shown over 'hidden' posts -- now called 'inappropriate' posts. It's unnecessary in our view, because a) readers can't see inappropriate posts and b) there is little risk of editors being exposed to this content inadvertently, since they have to click on 'More filters', then select 'Inappropriate' to see it; moreover, if an editor explicitly asks for inappropriate feedback to be displayed (by selecting the "Inappropriate" filter), then they would reasonably expect to see the inappropriate comments without any masks. Forcing you to click on every single post to see its contents is a bad user interface in our view, because it breaks the workflow for editors who want to check if "inappropriate" feedback was improperly classified (which can be done by skimming the list if the content is visible). This gray mask had initially been requested to be more consistent with the 'rev/del' practice used on English Wikipedia. But we don't think it's as relevant for the new tools in the context of reducing the editor workload, and may not matter so much to the international wikis that are actually planning to use the tool. From a user experience standpoint, fewer clicks will significantly reduce the editor workload, which is our main priority at this point.

With all this in mind, we have updated this access and permission matrix of user rights for Article Feedback, to reflect our latest developments. Is this updated access table accurate, as far as you are concerned? Do you have any questions about it?

All things considered, do you think that your community would be comfortable with this proposal? We are asking others as well, so we can all compare notes on this issue.

Thanks again for all your invaluable help in getting this tool ready for wider deployment. It's very much appreciated! Fabrice Florin (WMF) (talk) 00:51, 21 February 2013 (UTC)

I agree, overall it's a good decision but you haven't answered my question: How administrators should deal with feedback that should be hidden for most users but is not serious enough to be normally oversighted? In my opinion It can't be oversighted because it would be in conflict with the Oversight policy but also it shouldn't be visible to editors. So admins are missing their Revision deletion-tool. It's a conflict with the OS-policy if they hide feedback that matches the actual 'hidden'-criteria (see en:WP:OS#Policy point #4 and #5 and note: These cases shouldn't be used any longer because of rev/del). The previous behavior of 'hidden' was rev/del but thats no longer the case. Thats the point. Maybe you should contact the enwiki-oversighter first to discuss it with them or implement the previous behavior for hide. Overall I think it is right to give users a option to handle vandalism but not by removing admin tools (for en:WP:Article Feedback/Feedback response guidelines#Hiding and unhiding feedback H1, H4, H5).--se4598 (talk) 16:01, 21 February 2013 (UTC)

The Germans are using a different OS-policy (the one on Meta - which has a narrower scope than the one on the English Wikipedia - but I agree that the area between oversight-able material and "transparent to all (editors)" is an issue that has to be addressed.

In a broader context: WMF legal is on record insisting (in short) that matured communities can't simply co-opt Administrators without proper process, because broadening the number of users - able to access legally sensitive material - carelessly could potentially increase liability risks. It strikes me that the planned (de.wp-)design of the tool

a) might qualify in several respects as doing just that indirectly (and unintentionally) by creating a novel administrative field without the tools necessary to take care of it

b) can't be fixed through "reasonable expectation" to being exposed to such material on the side of the non-administrative community-member, because it is not an sufficient argument (and it would surely also apply to co-opted administrators). The argument applying to co-opted administrators, in turn, strikes me pretty much as also applying to non-administrative community members supposed to review and mark the same material, regards --Jan eissfeldt (talk) 10:34, 22 February 2013 (UTC)

Hello se4598 and Jan eissfeldt, thanks for your thoughtful recommendations, which we have discussed with our team. You make some very logical points that the current tools would deprive administrators from a function which they need. On that basis, we propose to restore 'Hide this post' as a separate function from 'Mark as inappropriate', as described in this new feature requirement.

This 'Hide this post' text link would appear in the second moderation panel that is shown after a post has been marked as inappropriate, and would only be visible to monitors (administrators, rollbackers or reviewers) and oversighters. Clicking on 'Hide this post' would display a gray mask over that post, which would make it impossible for anyone but a monitor or oversighter to see the contents of that post. Monitors or oversighters would be able to click on that gray mask to reveal its contents -- as well as an 'Un-hide this post' text link, which would revert the previous action and reveal the post again.

This would provide administrators with the equivalent of a Revision deletion-tool, to remove from public view feedback that should be hidden for most users but that is not serious enough to be oversighted, as you requested. If the German Wikipedia wishes to restrict this feature to only administrators (leaving out rollbackers or reviewers), this could be easily done with a local configuration setting for monitor rights.

Would this work for you? In the interest of time, we would like to implement that feature right away, so we could have it in time for next week's deployment. Please keep in mind that new feature development has ended for this project, so we're squeezing this in at the last minute, but will not be able to do more than bug fixes and small tweaks going forward.

Thanks again for your good insights and understanding! Fabrice Florin (WMF) (talk) 02:55, 7 March 2013 (UTC)

Correct me if I'm wrong, but isn't this feature working exactly like you describe it above in the current version on dewiki? At least I have been hiding quite a few comments already. There hasn't been a big discussion about a hiding policy yet, but I handle it currently similarly to the revdel feature for articles. There are quite some cases where we hide revisions on dewiki that are not within the OS policy but are deleted for other reasons anyway, such as copyvios or illegal statements accoring to german law (i.e racistic comments)--PaterMcFly (talk) 16:49, 7 March 2013 (UTC)

Hello PaterMcFly, you are absolutely correct that the 'Hide this post' feature currently works as described on both English and German Wikipedia. However, we plan to deploy new moderation tools next week, and we had considered removing that feature at that time, because it is so similar to the 'Mark as inappropriate' tool. Thanks to this discussion, we now plan to keep it after all. While this introduces a bit more complexity in the user interface, it is limited only to posts marked as inappropriate and only to monitors, while filling an important gap, so I think this is the right decision. Thanks again to se4598 and Jan eissfeldt for pointing out the issues that this would have created! All the best. Fabrice Florin (WMF) (talk) 17:31, 7 March 2013 (UTC)

Still a lot broken in the current labs build

I'm not sure if all the previously reported bugs are fixed in the current labs build. However, here are some oddities I found while testing at labs today:

1. I was not logged in and wrote a comment. I can see my comment at http://ee-prototype.wmflabs.org/wiki/Special:ArticleFeedbackv5/Main_Page. But the numbers are odd.
   1. "0 featured comments (of 13)". Why 13? There is only 1 comment.
   2. "77% found what they were looking for". This does not make any sense no matter what numbers you use. 0 of 13? 1 of 13?
2. Now I login as "test-editor". The numbers do not change and are therefor still confusing. But at least I got a filter dropdown with a little more to do.
3. It tells me I "cannot review your own posts". I know it uses a cookie. However this feels strange. Like my IP adress is stored in the database besides my username. I know it is not. Warning: Some users consider this a tracking cookie. They will refuse the tool because of that. Also it's way to easy to fake votes. All I have to do is to delete the cookie. Even if I'm logged in.
4. The possibility to "Sort by" should completely disapear if there is only a single comment. At least disabled. But I prefer to make things invisible if there is nothing I can do with it.
5. I choose the filter "Helpful (1)" and yes, it displays 1 comment. But it is not marked as helpful. It is marked as non-actionable. Bug?
6. All empty feedback is blocked because of a filter "Extremely short post". This is extremely confusing because there is a button to "Post without a comment". Because of the filter the button is not only useless, it is frustrating. I'm not sure if this can be ignored because it is an odd test in the labs or if it is a bug that needs to be solved (solution: hide the button if such a filter exists).
7. Wow, this is strange. I tried to unarchive this post: http://ee-prototype.wmflabs.org/wiki/Special:ArticleFeedbackv5/Main_Page/697676f02877de9ad6f59958389022f3. It worked but one minute later a user called "Article Feedback V5" (which is neither a user nor a bot) undid my action and archived the post again. The bug is: Why is there a button to "Undo archive" if this action is blocked by the tool a few seconds later? I guess this happens because the post is marked as "inappropriate". If this is true then there needs to be a button "Undo mark as inappropriate" or "Undo archive and remove all markings". Not "Undo archive".
8. This auto-archive stuff also disturbs some user actions. For example I clicked "Unmark as useful" on a random post at the central feedback page. I waited a little bit. It got auto-archived in the background. I could not see this but now I know this is what happens. 30 seconds later I tried to mark it as "Useful". My click got ignored. Nothing happened. I tried to click "Resolved" or anything else. Nothing works. This is very easy to reproduce. There should be at least an "out of sync" error message.
9. There is still to much garbage at the detail page. Sorry. It's not bad but it's possible to make it better by removing more unneeded stuff.
   1. "(#697676f02877de9ad6f59958389022f3)". This is like displaying the page ID number in the Wikipedia projects. Remove it. It's in the adress bar of the browser. Thats enough.
   2. "using feedback form 6X". I guess this is intended because there are multiple versions of the tool used side by side. Please remove this in the final version. It does not add anything to the comment.

Don't get me wrong, it's not all bad. I'm simply focusing on the oddities. For example I like the new "View more actions...". I'm not sure but I think the previous version used a popup. The new version is much better. --TMg 14:11, 8 March 2013 (UTC)

Thank you, TMg, for taking the time to test the Article Feedback tool so thoroughly! We will go through the issues you reported and address the most important ones first, such as the number discrepancies noted at the top. As far as the auto-archive issue is concerned, it's due to the fact that on this test site we are archiving comments much faster than we will on production. Note that even if these issues are not solved in the first release, we will aim to address all critical bugs in coming weeks. Please be patient with us, as we have a lot on our plate getting this first test release out the door. :) Fabrice Florin (talk) 20:18, 12 March 2013 (UTC)

OK, thanks. I know archiving is much faster in the test wiki than it will be in production. But the issues remain the same. Why does it act like a bot? It's not a registered user. I can not see it's contributions log, for example. Why is it even necessary to mark archived posts in the database? Why is it necessary to distinguish between "resolved" and "archived" posts? What's the point if I can't even undo this? Why not simply make this a rule in the filters? (Like "show unreviewed posts that aren't older than 3 months".) I was so happy that you finally dropped some of the confusing duplicate flags. Why do you introduce a new duplicate flag the same time you drop others?

What if an article is edited very seldom, let's say once in two years. On the other hand you have articles that are edited every day. What auto-archive rule do you use? For the first article it will be bad to archive possible useful posts to early. But you need to archive different in very popular articles. How do you achieve this? Why not let the users decide by clicking "useful", "resolved", "no action needed", "inappropriate" or simply filter by "I don't care about old posts"? --TMg 13:57, 13 March 2013 (UTC)

It's indeed an account used by a bot/script, see de:Benutzer:Article Feedback V5. See Article feedback/Version 5/Testing at "Auto-archive comments" and Article feedback/Version 5/Feature Requirements#Auto-archive comments at "Timining". I think that should answer most of your questions.--se4598 (talk) 14:14, 13 March 2013 (UTC)

This answers a few question, thanks. When I wrote my initial post it told me the "User account is not registered." I thought this was intended but it seems it was a bug. My main question remains: Why is an "archived" flag needed in the database? Why not simply split the "unreviewed" filter into an "unreviewed new posts" and "unreviewed old posts"? This would do exactly the same ("reduce the moderation workload") without introducing an other confusing duplicate flag. Even worse: The flag increases the overall workload. We can "undo" the flag and we have to undo the flag for certain posts. Why should we check every single post if it needs to be unarchived or not? The intended feature is to split the "stream" into two parts: fresh and old. This belongs to the filters. Not to every single post. Twitter is used as an example. Twitter does not store an "archived" flag for every single tweet. This doesn't make sense because it depends on the user if a certain post is to old to be useful for the user. Same problem here: If I watch the central feedback page I want to review only posts written in the last few hours. If I watch the feedback by category (still not possible, I really don't understand why) I need the posts from a few days or weeks. If I watch a single article I may need the feedback from the last 5 years. In short: This clearly needs to be a filter. Not a flag stored with the post.

What's the problem? Users complaining about the workload? The solution is insanely simple: Remove most of the numbers. Especially remove the giant numbers from the top of the pages. Move the numbers to the bottom and make them light gray and very small. Compare with Google. Yes, it tells you the total number of results. But the number is very small and almost not visible. Nobody thinks "o my god I have to review gazillions of web pages". It doesn't matter. It's more like a fun fact. Do the same and help the users focus on whats important: the top few posts according to the filter. The total number doesn't matter. Don't increase the amount of numbers by introducing an other flag. Reduce the amount of numbers. --TMg 20:15, 13 March 2013 (UTC)

Hey TMg, thanks for all your thoughtful ideas for simplifying the user experience in future releases. You made some interesting suggestions, but we have now ended feature development and the work you propose goes beyond the scope of this long-awaited release. At this point, we are mostly looking for bugs for the current feature set, as described on these help pages. We'll then want to test that feature set with the community for a couple months before considering any final feature changes. For now, I encourage you to test the current version of the tool, here on WMFLabs. Some of the technical bugs your reported may already be solved in that new version. And the auto-archive settings can be tweaked locally by each wiki, based on feedback from the community after testing it thoroughly with different timings. We'll get back to you about your longer-term recommendations once this week's deployment is behind us (we expect to have the new version Friday on a limited sample of articles on en-wiki and de-wiki. Thanks again for your helpful feedback! Fabrice Florin (WMF) (talk) 09:07, 14 March 2013 (UTC)

Maybe I wrote to much. Sorry. Let's focus. Please answer the questions I asked by expanding the documentation (don't answer here, nobody reads this). Most important question: Why did you created a bot instead of tweaking the user interface to achieve the same or even better result? --TMg 14:24, 14 March 2013 (UTC)

I'm sorry, but I don't quite understand this last question. Can you clarify it a bit more, please? Fabrice Florin (WMF) (talk) 23:00, 14 March 2013 (UTC)

Why a bot? Why no other solution? I wrote a lot about alternative solutions above. Which other solutions did you tested? Why did you dropped all other solutions in favor of a bot? I find this very odd. Adding a bot as an integral part of the feedback tool makes everything a lot more complicated. It's a new party in the game. Users have to deal with the bot. Users will misunderstand and fight the bot. We have to review everything the bot does. Your task was simple: make the tool easier to use. Instead you made it more complicated. I don't get it. I'm very sorry, I don't want to be personal. I'm just confused and disappointed. --TMg 23:50, 14 March 2013 (UTC)

---

Simple moderation tools

The confusion continues at WMFLabs:

• I'm not logged in. I check the recent changes and click a feedback that was hid. I get an empty page. There is not even a message.
• I feel so damn stupid but I really don't understand what you are doing. Again, I'm not logged in. All feedbacks still have the old row of tools at the bottom. "Is this feedback helpful?" and "Flag as abuse". Is this a bug? Wasn't this supposed to be replaced by the simpler moderation tools on the right? Don't tell me this is supposed. What's the point in using a different set of tools for unregistered users? What's the point in providing a possibility to flag a "helpful abuse"?
• Even when I create an account and log in there is no way to see the missing 10 comments. It tells me there are 14 comments but it shows only 4. The filter selection is missing. As said above I think I understand whats going on under the hood. Please do not explain this to me, again. But at the same time I find this extremely confusing for all users that do not have the knowledge I have. As said above the solution is simple: Simply remove most of the confusing numbers. Change it to "36% of 14 users found what they were looking for". Remove everything else.

--TMg 15:05, 14 March 2013 (UTC)

Hi TMg, quick answers to your points above:

1. the first point is already resolved :)

2. the second point about reader tools is a known bug, which should be fixed by Tuesday :)

3. the third point raises a reasonable UI concern. I agree with you that the current numbers are confusing and we will mull over your recommendation to simplify that line. Perhaps we could adapt your suggestion to only say:

'36% of users found what they were looking for (from 14 posts)'

Either way, I will discuss this idea with our designer and we will consider it seriously. All the best, Fabrice Florin (WMF) (talk) 23:00, 14 March 2013 (UTC)

2. I see. Unfortunatelly we are talking about different issues. My problem is: Why are the old tools still active when I'm not logged in? Don't tell me this is intended. It does not make sense to have two different tools to flag a comment as helpful, two different tools for unhelpful comments and two different abuse flags. It's confusing and counter-productive to provide a possibility to flag a "helpful abuse". All the people do with the "abuse" flag is to abuse it. It doesn't add anything. It doesn't help with moderation. It's confusing. Remove the duplicate flags completely. Stick with the new set of tools. --TMg 16:55, 22 March 2013 (UTC)

I don't share your view. Why should be something confusing if they are for different audience and most probably never see the other side? I wouldn't give logged-out users the new moderation tools as they are moderating and not only give a tendency like helpful-votes and likely/sometimes get abused. I'm not a friend of the hiding-possibility of the abuse-flag but to remove all IP-tools would be IMHO locking this group out at helping us for distinguish between useful or not useful feedback. In dewiki it's maybe not problematic as we have only a small amount of feedback.--se4598 (talk) 14:48, 23 March 2013 (UTC)

Now that the duplicate interface is disabled it's a million times easier to distinguish between them. Unregistered users have a tool to vote. Registered user have a tool to moderate. The tools look different because they are different (voting vs. moderation). I can live with that. But one thing remains: Remove the "flag as abuse" voting. There is a dislike thumb. Thats enough. Nobody needs two buttons to dislike a comment. There is only one button to like a comment. All the unregistered people do with the "flag as abuse" button is to abuse it. It's useless. It does not help with moderation. It makes moderation more complicated. --TMg 20:24, 23 March 2013 (UTC)

Test results from the German Wikipedia

We collected a lot of information at de:Wikipedia:Artikel-Feedback/Notizen#Fehler in der neuen AFT-Version vom 20. März 2013 but it's all in German. I will try to write a short overview in English. I will add numbers to everything so you can respond very easy.

1. Broken functions
   1.  Done Some administrators reported that the hide function does not work at all (bugzilla:46892).
   2. When I reload the central feedback page (with F5) the filter is always set to something I don't want.
   3.  Done Click "Add note". The focus must go to the input field.
   4.  Done Entering a note and pressing enter simply reloads the page. The note is lost (bugzilla:44376). I consider this a major bug because it wastes the users time for no reason.
2. Confusing translations
   1. Luckily we are able to fix the German translations ourself.
   2. The English messages are also confusing (bugzilla:35026). For example there is "Helpful" and "Useful". It's impossible to tell the difference just by reading the message. Same problem with many other messages ("Unhelpful" vs. "Flagged" vs. "Inapropriate", "Featured" vs. "Relevant", "Feedback" vs. "Comment" vs. "Note").
   3. In the German translations I tried to make it more obvious that some of these things are votings (done by unregistered users) and some are moderation flags (done by registered users). For example instead of just "Helpful" and "Unhelpful" it says "Überwiegend hilfreich" and "Überwiegend nicht hilfreich" ("Mostly helpful" and "Mostly unhelpful"). Instead of just "Flagged" it says "Als Missbrauch gemeldet" ("Reported as abuse").
   4. I completely removed the "(of x)" parts from all German translations (by adding <!-- -->). I'm very happy with this change. Nobody missed it so far. It reduces pressure and confusion.
3. Synchronization issues
   1. It's very hard to reproduce these issues. Each issue feels like a different bug. But I think most issues are caused by the same few bugs. Probably (more) missing purges or other reasons why database instances or local caches go out of sync. All I can do is to give some examples.
   2. Sometimes clicking one of the thumbs or one of the moderation tools simply does nothing. Like the server does not respond at all. The problem is that there is no feedback when I click. Nothing. The first feedback is shown when the server responds. A possible solution is to change the icon I clicked into a spinning wheel.
   3. Percentages and counts jumping around. This can't be reproduced any more because the reader tools are removed for registered users. But I guess the issue is still around. For example a single click on "Helpful" results in "200% found this helpful". In other cases I got "-100%" multiple times. This always goes away a few minutes later. I already suggested this: Add code to limit all counts and percentages to never show negative numbers or more than 100%.
   4. Multiple users reported the "Unreviewed" filter broken. It shows a mixture of unreviwed and reviewed comments.
   5. Basically this happens with all filters all the time. Choose the "All comments" filter. Do a moderation. Switch to an other filter. Switch back to "All comments". It shows the previous list without the change you just did (bugzilla:46797).
   6. Multiple users reported missing notes (bugzilla:46499). They added a note but the "Add note" link is still shown (bugzilla:46796).
   7. It's possible to hit "Add note" multiple times. This deletes the previous note. This is not shown in the log ([1]). I'm able to reproduce this. Here is what I did: Use the central feedback page and add a note. Go to the detail page. The link "Add note" reapears. Not you can change the note as many times as you want. It will also go out of sync because of that (see File:AFTv5 duplicate hint bug.png).
4. Permanent data loss
   1. Possibly related to the synchronization issues above. But the following issues don't go away after some minutes.
   2. At [2] click "Featured (0)". You will see 4 comments instead of 0. Not done. The "Featured" filter shows comments that are not featured.
   3.  Done [3] shows "440% found this usefull" (bugzilla:40613).
5. UI improvements
   1. Remove the "flag as abuse" function completely, please. Keep the two thumbs. That's enough. We don't need two identical function to downvote a comment.
   2. What happened to the numbers? Previously it was "#5000", now it is "#04f63536bac6e88ed84e842b2b7828a7". Either change this to the previous short numbers or remove it from the UI. The number is still in the URL. That's enough. No need to show it in the UI.
   3.  Done Notes are truncated (bugzilla:44826) but there is no indicator how many characters are left when entering a note (bugzilla:44827).
   4. The CSS uses bad position code. Try to shrink the browser window. At about 1100 pixels some parts will start to overlap. This is because some parts are positioned from the bottom. This should never happen. Here is a very good way to reproduce this: Use Firefox. Enable the menu. Look for the "Zoom Text Only" function and enable it. Zoom in. The layout will break very, very fast.
   5. Remove the "(of x)" from all headlines. It's useless and confusing. Nobody understands why this number is different from the "all comments" number. It impossible to understand because this is not a number of comments but a number of feedback votes. But the headline is talking about a number of comments. This is wrong. Instead add a tooltip "Based on x votes" to the percentage.
   6. Remove the two "x featured comments" headlines completely. The number of featured comments is in the filter below the headline. No reason to show it twice.
   7. Unregistered users need to be able to use at least some of the filters and the "Sort by" function.
   8. Most filters like the "Flagged" filter are completely pointless. Nobody needs this. Instead we need a "Reported as abuse and not moderated yet" filter. Same for most other filters.
   9. It's pointless to show the "Sort by" function if there is only one comment.
   10. It's pointless to show the "Show feedback page" link if there is only one comment. Especially if it's the one I just wrote.
   11. A full text search is needed. For bot registered and unregistered users. For example to be able to find their own comment again.

--TMg 10:07, 3 April 2013 (UTC)

I almost forgot the most important result from our tests and discussions:

6. Opt-in
   1. You really, really need to make this opt-in. At least provide a very easy way to opt-out certain articles from the tool. For example the tool is almost completely pointless at high-traffic articles. There is enough feedback at the regular discussion page. Sometime even this is to much feedback. Nobody needs more repetitive feedback for such articles. This is not a bug, this is a distress call to the WMF. Don't force the German community to reject the tool as a whole. Let the users decide on a per-article base.

--TMg 11:58, 3 April 2013 (UTC)

Responses and notes

re 6) already possible: for opt-out, use de:Kategorie:Wikipedia:Artikel-Feedback/Ausschlussliste ($wgArticleFeedbackv5BlacklistCategories). opt-in via the other cats ($wgArticleFeedbackv5Categories). But thats something we have to discuss locally--se4598 (talk) 12:04, 3 April 2013 (UTC)

I don't consider this "easy to use". It must be a single click reachable from the article discussion page. Not by adding or removing a category to or from the article. Also the current settings seem to be for categories only. We need this for single articles. --TMg 13:28, 3 April 2013 (UTC)

It is working for single articles (and only direct on articles or included via template). It's as easy as enabling AFTv5 on a article by setting de:Category:Wikipedia:Artikel-Feedback/Zusätzliche Artikel. To disable simply remove this (or equivalent cat). There is only a blacklist category because of the random selection based on pageid, everything else is via the opt-in categories (for dewiki: 1,2,3,4). Further information: Article feedback/Version 5/Moderation guidelines##Enabling feedback and following section.

I don't consider a "easy" link on the talkpage for suitable because it could be misleading (ex. only disable for me personally). If you want such a link this could be a task for a user-written gadget--se4598 (talk) 17:05, 3 April 2013 (UTC)

OK, I misunderstood the documentation. Unfortunately my problem remains: Why should we change thousands of articles to enable a discussion tool? A bot run that adds an opt-in category to all 1.5 million articles is out of the question. But it's almost the same problem the other way around. If we do an opt-out approach we need to add an opt-out category to all high-traffic articles! I think this is a very bad idea. This will cause insane discussions and hate. Sometimes it's not possible at all because some of these articles are blocked. You always need an admin to do this. This is not easy. My conclusion: Enabling and disabling the tool for a certain article must be done in the tool. Not by changing the article and not by changing the discussion page (but reachable from the discussion page). --TMg 19:07, 3 April 2013 (UTC)

normally (for enwiki as replacement for aftv4) there would be no need of categorys because it would be enabled on all/most articles via the "lottery"/random-page set to 100%, no need to edit 1.5 million times. But you're right changing many pages doesn't seem right, but also an "internal" management of the activated pages must be somewhere visible and not hidden. This will be adressed by your idea on the talkpage but changes must be inserted into e.g. the watchlist, so people would get aware of changes (currently this is the case via the needed category-change). I don't agree on your high-traffic-article (definiton?) argumentation. In my opinion this should be done on a case by case basis (not via bot) depending if the page is really excellent and if there are many not useful feedbacks (as for any page, not only high-traffic).--se4598 (talk) 20:11, 3 April 2013 (UTC)

Sure, this must be done case by case. High-traffic articles are an example. They get plenty of feedback on the regular discussion page. Nobody needs more feedback for such articles. Nobody reads this. Nobody uses this. It's a waste of time for everybody. Readers are wasting their time writing feedback nobody reads and nobody answers. Users are wasting their time with moderation, most probably by clicking "nothing to be done" for 90 % of the feedback. Therefor the tool needs to be disabled for such articles. Yes, adding and removing the tool must be visible in the watchlist. But not by actually editing the article or discussion page. This must be done with a log entry similar to when the protection level of a page is changed. This is not new. For example: Changing the "move" protection level enables or disables the right to move a page for certain user groups. This is shown in the log and in the watchlists of the users. Simply do the same: Changing the "feedback" level enables or disables the feedback tool. Store this in a log entry and show it in the watchlists. --TMg 20:50, 3 April 2013 (UTC)

Thanks a lot for collecting this detailed feedback, that's awesome! If you can identify good steps to reproduce, please file bug reports (see How to report a bug) if issues have not been filed yet. For 4.3, that's bugzilla:40613. In general I wouldn't call this data loss, but incorrect or confusing statistics. --AKlapper (WMF) (talk) 12:18, 3 April 2013 (UTC)

Thanks, I added bug 40613 above. As I said I don't want to fill bug reports. If you think this will help you please simply copy and paste my text to a bug report. I will try to add missing information here if you ask. Please ask! --TMg 13:28, 3 April 2013 (UTC)

Note: 1.1 This is now bugzilla:46892 and has a patch attached. --AKlapper (WMF) (talk) 15:32, 4 April 2013 (UTC)

4.2) This is in fact not a bug, because "featured" now includes helpful (up-voted) and useful (moderated) feedback which is not done/resolved in another way.--se4598 (talk) 10:15, 18 April 2013 (UTC)

There are 9 "helpful" comments. But only two are shown when I click "featured". Even if others have a better percentage. This does not make sense. Must be a bug. Additionally I don't understand why anybody would need these confusing duplicate filters? I said that multiple times now. I find almost all filters confusing and useless. Most filters don't make sense any more since the moderation tools are introduced. Other filters that can actually be used for moderation are missing. Now we have a filter to show only up-voted comments (no matter if they are moderated ot not), an other filter to show comments that are moderated as "useful" and a third filter that does an unexplained mixture of both? Why? Who should use this and for what purpose? How should a user understand the difference? My conclusion: We need to remove every second filter. --TMg 13:20, 18 April 2013 (UTC)

ok, that can be confusing filters if theres no explanation. But it's not a display bug that there are 2 "featured" and 9 "helpful" comments because 7 of them are resolved or marked as "no action needed", so only two are open and needs to be addressed by article writers. So i think it's a good filter for open tasks writers can work on. And I think thats the reason why this filter is prominent on top of the page and not somewhere hidden behind a drop-down menu (for more advanced editors, who want more control and would also review old already processed posts). Or do you mean that the documentation must be improved, which is linked in the top right corner of each aft-page? I think that would be sufficient.--se4598 (talk) 13:37, 18 April 2013 (UTC)

I don't belief in documentation. Nobody reads it. I belief in self-explanatory interfaces. It does not make sense to be "unreviewed" (= nobody ever looked at it) and "featured" the same time (= somebody looked at it and highlighted it). Is this just me? Or is this confusing for everybody? --TMg 18:56, 18 April 2013 (UTC)

View activity link stops working

Steps to reproduce:

• Choose an unmoderated feedback and open it in two browser windows side by side.
• In the first window click a moderation button, e.g. "No action needed".
• In the second window click an other moderation button, e.g. "Inappropriate". Result: Me, happy. :-) The second moderation action is simply ignored. That's fine. No need to show an error message. It will not help. Instead it simply reloads the feedback and displays "No action needed". Perfect.
• Now go back to the first window and add a note.
• In the second window also add an other note. Result: The second note overwrites the first. I'm not sure if this is a bug or an intended behavior. It kind of makes sense. Let's call this a no-op.
• Now click "View activity" in both windows. It does not work. This the first bug. It just jumps to the # anchor. There is no error in the JavaScript console.
• The second bug can be seen on the left. There is a "Details" link that shouldn't be there. All the link does is reloading the detail page. So it's not a problem to have it there but it's useless.

--TMg 21:46, 4 April 2013 (UTC)

Response to TMg

Hello TMg, thanks so much for all your great testing and thoughtful suggestions, which are much, much appreciated!

Our developer Matthias Mullie has already addressed a number of the issues you reported, and I will let him address technical issues from sections 1, 3 and 4 above. In this response, I would like to focus on some of your feature requests from sections 2, 5 and 6, as outlined below. We have discussed these requests with our designer Pau Giner, and we will post more notes once we get his recommendations.

2.2 Confusing messages

We are sorry for any confusion, but this is a sophisticated system which needs to provide different tools for readers and editors. This is why we had to use different words for functions that appear similar but that do not have the same effect (e.g.: "Helpful" is a voting tool for readers and "Useful" is a moderation for editors). In our view, they should continue to have separate labels, so we can refer to them by name. But in your translations, you are welcome to use the words 'reader' and 'editor' (or 'vote' and 'moderate') to help differentiate them further from each other. Note that to make things simpler for end-users, readers can only see the tools assigned to them (e.g.: 'helpful', 'unhelpful' and 'flag'), and editors can only see the other moderation tools (e.g.: 'useful', 'resolved', 'no action required' or 'inappropriate'). As for other wordings, you can use 'feedback' and 'posts' interchangeably, but keep in mind that not all posts have 'comments' (as we allow readers to post only a helpfulness rating, without a comment).

5.1 Remove the "flag as abuse"

We respectfully disagree with your recommendation on that point. This feature is a very standard component of most public comments or feedback systems on the web today, and is intended to let readers report abuse, which sadly happens often enough to be required for this type of application. This allows moderators to find out right away if there are potentially abusive comments, and immediately remove them from public view, if necessary. The 'unhelpful' function is not recommended as a substitute for the 'flag' function, only as a way to say the comment was not particularly helpful. Also note that the 'flag' function has some unique characteristics, such as automatically marking the post as 'inappropriate' and removing it from view, if more than 5 people flag it as abuse.

5.2 Post numbers

You make a good point that the new post ID numbers are pretty long, which makes them somewhat overwhelming. That said, we believe that there is still value in showing them in the Details/permalink page, so people can refer to that unique ID; you are correct that the number is already included in the URL, but we still need it on the Details page, because not everyone will notice that they are. Our proposal is to only show that number in the Details page, and make it much smaller, below 'Info about this post'. Pau will give us a design recommendation for this. We will definitely remove it from the 'View activity' log, where it is clearly not needed.

5.5 Remove "(of x)" from headlines

You make a very reasonable point, and we have been considering this change for a while now, ever since you brought it up. Based on your recommendation, we are prepared to remove this confusing number and show it instead as a tooltip over the percentage ("Based on x posts"), as you suggest. Pau will give us a design recommendation for this.

5.6 Remove the "x featured comments" headlines

You make a good point about this as well, and we agree that this information is now redundant with the filter number below. We are now considering removing this line from both the central feedback page and the article feedback page. The design challenge is that this would make the percentage line more prominent, which could require some tweaks. Pau will give us a design recommendation for this as well.

5.7 More filters for unregistered users

We have discussed your proposal to give more filters to unregistered users. As a rule of thumb, we prefer to keep the user interface as simple as possible for anonymous readers, and our approach has been to only give them what they absolutely need. So we would need to hear some really compelling use cases for why this request would be necessary. Why would a reader need more filters when they are not required to visit this feedback page in the first place? That said, we agree with you that the "Sort by" function could be useful to readers, which is why this feature is already available to them.

5.8 Most filters are pointless

Again, your perspective does not match at all what we have heard from other users, who specifically requested many of these filters. (I'm also puzzled why you think these filters should be available for unregistered users, if you think they are pointless.) These filters are intended for users who have specific tasks to perform, and want to view different queues by category. If we find out that some filters are not being used at all, we are prepared to remove them, but would not make that decision until later this year.

5.11 A full text search is needed

This is on our to-do list for future releases, but due to limited development resources, we are unlikely to implement this request this year, unless it is recommended as a top priority by a lot of community members.

6 Opt-in / opt-out tools

Yes, we agree with you that we need to provide better tools for enabling or disabling the feedback form on a per-article basis. We currently have a tool for doing that, but it is only available to administrators as part of this 'Protect' feature. Pau Giner is going to prepare some design recommendations for making it easy for any editor to enable or disable feedback, rather than the complicated category method we are now using. This is something that is needed for the English Wikipedia, regardless of what the German or French communities decide to do regarding opt-in for their sites.

TMg, thanks again for your amazing work on this project! It is invaluable for helping us improve the product and better meet the needs of our users! --Fabrice Florin (WMF) (talk) 00:39, 10 April 2013 (UTC)

Thanks you all very much so far. Just some notes:

• My list above is a summary from the German discussions. It's my wording, obviously, but not only "my" feature requests.
• I know that some of the ideas are out of scope for now. But it would be nice to create Bugzilla entries for ideas like the full text search and set them to "later".
• 2.2 "editors can only see the other moderation tools". This is true for the tools. But editors can see both "helpful" and "useful" in the filters, for example.
• 5.1 "is a very standard component of most public comments or feedback systems". Wikipedia is not like these systems. All I can say is: I consider the current public "flag as abuse" voting completely useless. It is misused by the unregistered users and not used for moderation by the registered users. As far as I know.
• 5.1 "automatically marking the post as 'inappropriate' and removing it from view, if more than 5 people flag it as abuse." I thought we agreed that this is a bad idea and should be removed?
• 5.2 "the new post ID numbers are pretty long". But why? Was there a problem with using a sequence?
• 5.2 "only show that number in the Details page, and make it much smaller". Very good solution, thanks.
• 5.7 "Why would a reader need more filters when they are not required to visit this feedback page in the first place?" I'm sorry? Why would a reader need a "flag as abuse" function when he is not required to visit this page? I thought the use case is obvious. Let me explain: Let's asume a reader wrote a longer feedback. The same day his feedback was done and moderated as "done". The moderator even added a note. A few days later the reader comes back to the article and checks the feedback to see if he got an answer. But his feedback is gone. Like it's deleted. The reader is unable to find it. It's impossible to read the note. This happens with every moderation except for the "Helpful" moderation because that's the only filter the reader haves.
• 5.8 "These filters are intended for users who have specific tasks to perform". I'm not sure what these tasks are. A few sentences before you told me the "flag as abuse" voting can be used for moderation. But it can't because there is no filter for this task. If I choose the "flagged as abuse" filter all I get is feedback that is already moderated. I have to sroll a lot to find some unmoderated feedback. Switching the order does not help much. I can moderate a few new feedbacks and a few old feedbacks but never the majority inbetween. Same problem with the "helpful" and "not helpful" votings. My task is moderation. I can not perform it with the current filters. This is also one of the reasons why I consider the "flag as abuse" voting useless (besides being a duplicate to the thumb down). Currently all three votings are almost useless because there are no proper moderation filters.

--TMg 16:55, 10 April 2013 (UTC)

Greater visibility of feedback/information requests?

(Am I doing this right? Is this Where I should be doing this? So confused!)

I understand that Feedback can be a huge section (cluttered page) on hot-topics and that the editors can only do so much, but perhaps there is a way to make questions about a given page/topic more visible to casual readers?

The way things are now you have to go to another page to find out if there are questions (requests for more information on a topic) which most casual readers do not do. One of those casual readers might have the answers, but not realize that anyone wants the information.

But again, to avoid page clutter, my first thought was a link, opposite the [edit source] link, at the far righthand side above the same line, that would be something like [Additional Information Requests]... or something shorter than that.

This would at least put the notion of additional information requests in very visible locations.

Also, to avoid information overload, perhaps have each section expandable? Have the usual basic information always visible, but have a [more] button/link to view the nitty-gritty details or answers to specific questions that the casual reader might not be interested in hidden until [more] is clicked on.

Or, perhaps even simpler, would be to have all of it (additional information and questions) linked to a [Additonal Information] button/link opposite the [edit source] link, with questions and the ability to ask them/answer them being prominently featured on that page. Leaving Feedback where it is and how it is.