Article feedback/Version 5/Feature Requirements

This page describes new features to be developed for the Article Feedback Tool Version 5 (AFT V5), during phases 1.0 to 1.5 of this project (Oct. 2011-Jan. 2012). Other features for phase 2 (Feb.-Mar. 2012) are only referred to here in outline form. (See sample feedback forms on the right)

See also: project overview page, testing page, interactive prototype, as well as technical design page, data and metrics plan and our live metrics dashboard.

Overview
Key features for AFT V5 will include: In phase 1.0 of this project (Oct.-Dec. 2011), we will create and test three different types of feedback forms:
 * new feedback forms
 * calls to action
 * feedback page
 * administration tools
 * Option 1: Basic feedback
 * Option 2: Make a suggestion
 * Option 3: Review this page

We plan to A/B test these options against each other, to find out which is most effective for engaging readers, supporting editors and improving article quality (see data and metrics page).

In phases 1.2 to 1.5 (Jan.-Feb. 2012), we will also test these additional options: In phase 2 (Feb.-March 2012), we plan to develop more features, such as expanded feedback. Other phase 2 features are outlined in the sections below.
 * Feedback links
 * New calls to action (such as Option 4: Edit this page)
 * Feedback page

For a preview of what these forms and pages might look like, read below, or check our project slides.

Phases
Here's our phased development plan for AFTv5 features from Oct. 2011 to Mar. 2012:

Phase 1.0 Features Phase 1.1, 1.2, and 1.3 Features Phase 1.4 and 1.5 features: Phase 2.0 features: 
 * 3 feedback forms:
 * option 1 - did you find what you were looking for?
 * option 2 - suggestion / praise / problem / question
 * option 3 - review this article
 * CTA 1: Edit call to action
 * CTA 2: Learn more (if you can't edit)
 * help tool tip + help page
 * bucketing via cookies
 * data collection of stage 1 metrics
 * small set of articles
 * 4 feedback forms:
 * same 3 forms as above, plus:
 * option 4: edit this article
 * add overlay capability
 * add minor copy tweaks
 * 2 placement options for feedback link:
 * option A - article title bar left
 * option D - horizontal button at bottom right corner
 * CTA 3: survey call to action (like AFT v4)
 * simple survey form (like AFT v4, separate table?)
 * CTA 4: sign up or login (like AFT v4)
 * CTA 5: email capture form (adapted from AFT v4)
 * data collection of stage 2 and 3 metrics
 * larger set of articles
 * basic feedback page
 * simple listing of full posts (most recent comments by default)
 * overall article ratings (e.g.: % who found what they were looking for)
 * sorting (by date / by rating / by helpfulness)
 * basic filtering (e.g. comments-only, flagged only)
 * flag for abuse
 * hide/show this post (editors only - rollbackers?)
 * delete this post (oversight administrators only)
 * community policies for access, hide and delete features
 * no feedback page links (only accessible if you know the URL tag)
 * advanced feedback page
 * expanded filtering (helpful only, by user group, editor filters, by tags)
 * rate posts (was this post helpful?)
 * tag this post
 * editor tools (add to talk, resolved issue)
 * better layout and pagination
 * abuse/spam filters
 * add links to feedback page
 * feedback link on talk page
 * partial talk page integration (feedback section)
 * full talk page integration (add best posts to discussion)
 * add comments to feedback posts
 * add in to-do list (link in editor tools)
 * to-do list display and management
 * expanded feedback

Feedback forms
The feedback form interface will appear on every article selected for our phase 1 test, as the current AFT does now on Wikipedia (unless disabled in user preferences). There will be several options of the user interface, for A/B testing. Ultimately, one option will be selected for production use on all articles. The following 4 options shall be implemented, along with a fifth option 5, where we will not display any feedback form at all. For a quick demo, see this interactive prototype.

Overall Features
Overall Functionality
 * During the first testing phase, new feedback forms will only be shown on a subset of articles in the english encyclopedia (e.g.: Obama). They will not be shown for articles that are newly created, or which do not include any significant content, or which include geo-tags.
 * Feedback forms and feedback links will not be shown either if the user has selected to hide the AFT (checked 'Don't show the Article feedback widget' in Preferences > Appearance >)
 * The feedback form option to display shall be selected randomly, as per the current AFT mechanism. See this bucketing flowchart.
 * The "bucketing" mechanism will work as described in this flowchart and the technical design page. It will not be configurable, but should be easily changeable in code.
 * For testing purposes, an override parameter shall be supported in the bucketing mechanism (e.g.: a URL tag specifying which form to show).
 * All feedback forms will be displayed at the bottom of the article pages by default.
 * We are also planning to test three different 'Feedback' text links higher up in the browser window, as described in the section below. If a user clicks on one of the feedback links described in the Placements section below, the feedback form will be shown as a modal overlay next to the feedback link (or at the very least provide a jump link to the form at the bottom, if overlays cannot be implemented on certain browsers). Overlay forms will include a close 'X' button and the page background will be grayed out.
 * Comments can be as long as 5,000 characters (no countdown will be shown for now, but we will simply not allow the user to type any more text beyond that limit)
 * For returning users (registered & logged in, already provided feedback for this article): the form will be blank, even if you provided feedback earlier. But this text link will be shown: 'See your last post >>' with a link to your last post(s) on the feedback page, sorted by user. Unlike with the AFT v4 form, users will not be able to edit previous feedback.
 * when calculating overall ratings (or yes/no answers), only count the last post rating, not an average of all ratings by that user for that article
 * Feedback forms may not be shown either if a user (or IP address) has been permanently blocked from editing on Wikipedia (exact policy TBD)
 * Anyone can post as many feedback items as they want for a given article (TBD: to prevent spam, do we want to set a limit of 10 posts per user per day?).
 * In phase 2.0, we may also give the users 30 minutes or so to go back and edit their feedback, in case they make a mistake they want to correct. This may be done by adding an edit link next to your posts on the feedback page.

Overall Visual Design Font Sizes: We will aim to use the following font sizes, with this proposed hierarchy across all forms:
 * The feedback form interface shall follow the Mediawiki style guide, as well as the look and feel of WMF's latest Call to Action assets and buttons.\
 * The 'Post your feedback' buttons will be shown on the left of the form (where it is most likely to be clicked on than on the right).
 * All text prompts in comments to be gray, not black, as commonly done on other sites. The user comments themselves should be black, not gray.
 * A close 'X' button will be shown at the top right corner of all overlay versions of the feedback forms. This close button would not be shown on the bottom versions of the forms, where only the help icon would appear. Both the help and close buttons should be consistent in shape and size, with the '?' and 'X' as the primary differentiators.
 * When a feedback form is shown as a modal overlay, let's gray out the background, as done in the WikiLove feature (but perhaps using a lighter shade of gray).
 * The forms should survive and degrade gracefully in a visual manner within three design styles: Normal web page (580 px minimum, grow horizontally with grace); Tabletized web page (580px); Mobile (max 320 px, give 5 on each side, for 310)
 * All links will be underlined on hover (as per the style guide). External links and links that open in another window shall have an appropriate icon next to them.
 * Feedback forms should also display summary statistics. For Option 1, this could be "% found what they were looking for" and # of total comments.
 * To discuss: Should these statistics should ideally be hidden behind a click so as not to influence the reader (e.g., reader needs to click a "view stats" button)? Or does having the statistics in plain view suggest activity on the site?
 * Title: 1.4 em / 16 pt (e.g.: 'Help improve this article')
 * Subtitle: 1.2 em / 14 pt (e.g.: 'Did you find what you were looking for?')
 * Button Labels: 1.2 em / 14 pt (e.g.: 'Yes / No', or 'Post your feedback')
 * Comments: 1.0 em / 12 pt (for both gray text prompts -- and for actual user comments)
 * Small text: 0.8 em / 10 pt ('By posting, you agree to transparency under these [terms]')

Note: For final text copy, please refer to the text descriptions below, rather than the graphic wireframes and mockups, which could be out of date.



Option 1


To see this version of the feedback form in action on Wikipedia, click here. (The picture above is a mockup - see also earlier prototype screenshot and wireframe for this feedback tool.)

This feedback form includes these design elements, from top to bottom, left to right: 'Your comment will be shared on this [feedback page]. (phase 1.5) By posting, you agree to transparency under these [terms]' (phase 1.0)
 * Title: 'Help improve this article' (instead of earlier titles: 'What do you think?' or 'Share your feedback')
 * Help button (link to static page or FAQ with tips on how to give feedback)
 * Question: 'Did you find what you were looking for?'
 * Yes/No Buttons:
 * The yes/no buttons shall have a button appearance, but function as radio buttons.
 * Clicking a yes/no button shall toggle the yes/no switch state, but not submit the form.
 * The yes/no answers shall be stored in a separate field, as well as mapped to 4 and 2 overall ratings
 * Clicking on yes/no buttons will cause a context-sensitive text prompt to appear in the comment box (see below)
 * A comment box (multiline text area)
 * A gray text prompt inside the comment box (after user clicks yes or no, e.g.: 'What's missing? Any suggestions for improvement?' - see below)
 * Small disclaimer text with links:
 * Post button: '[ Post your feedback ]'

Context-sensitive text prompts: The prompts in the text area are context-sensitive, so you get a different message if you click on Yes, rather than No.
 * Yes: "What did you like most? Share your praise with the editors."
 * No: 'What's missing? Any suggestions for improvement?' (as shown in this wireframe)
 * If neither Yes/No button is selected, do not show text prompt.
 * To give users maximum freedom in option 1, we will allow a user to enter a comment in that form, even if they don't want to click on the Yes or No button. So the 'Post your feedback' button should become blue as soon as the user types in the comments box (instead of forcing them to use the Yes/No buttons).
 * Similarly, a user should have the option to click 'Yes' or 'No' and post without any comments.
 * As soon as a 'Yes' or 'No' button is clicked or a comment is typed, the 'Post your feedback' button will become blue (instead of the default gray).

"By posting, you agree to transparency under these ". foundation‏‎:Feedback_privacy_statement
 * The small legal text at the bottom of all forms will link to this privacy statement (on all forms):



Option 2


To see this version of the feedback form in action on Wikipedia, click here. (The picture above is a mockup with new face icons from Brandon - see also earlier mockups with color icons, with only one tab selected and with all color hilites.)

This second variation of the feedback form focuses on the text comment and its label (tag). Interface functional details:
 * The title of the form shall be "Help improve this article" (used to be context-sensitive)
 * Label selection (default selected is 'suggestion')
 * Comments box (multiline, with different prompt depending on selected label)
 * Post button (caption shall reflect the selected label).
 * Links to the feedback page (1.5) and privacy policy (1.0)
 * The labels selection shall function as tags selection, only one can be selected at any time.
 * Selecting a label shall change the default placeholder text for the comments box, only if no text had been entered yet
 * If text had been entered in the comment box, it shall persist through label changes.
 * To further clarify, there is only one text input box.

Context-sensitive text prompts: The prompts in the text area are context-sensitive, so you get a different message if you click on Suggestion, Praise, Problem or Question.
 * Suggestion: "Make a suggestion! How can this article be improved?"
 * Question: 'Ask a question about this article. '
 * Problem: 'Report a problem. How can this article be improved?'
 * Praise: "What's most useful to you? Share your praise with the editors."

Context-sensitive button labels: Ideally, we would have different button labels for each type of feedback, if easy to do: If this is hard to do, we will just have the button say: "Post your feedback"
 * "Post your suggestion"
 * "Post your question"
 * "Post your problem"
 * "Post your praise"

Note: This form design is inspired in part by GetSatisfaction.com.



Option 3


To see this version of the feedback form in action on Wikipedia, click here. This version of the feedback form provides the users with the ability to give an overall rating to the article (see rating functionality above), and a comment. Labels/tags input are not provided on this form. The visual appearance shall be the same as option 1, but have 5-star rating widget instead of the yes/no buttons.

Updated text: 
 * Title: 'Help improve this article'
 * Subtitle: 'How would you rate it, overall?'
 * Comments prompt: 'Add a comment. How can this article be improved?'
 * Small text: 'By posting, you agree to transparency under these [terms]'

Option 4


(streamlined mockup for this call to edit.)

This variation will be tested in phase 1.4 and does not provide feedback options. Instead it is a direct call for the readers to edit the article.
 * The "Edit" button takes the reader to the article's edit page.
 * The "learn how to edit" link takes the reader to this New Wikipedia Tutorial].
 * Both registered and anonymous users shall be able to edit the page, as per current Mediawiki functionality.
 * If the article is not editable by the user (according to its protection level), another interface option is to be displayed instead (options 1-3 or 5)
 * If the user has been blocked from editing by Wikipedia, another interface option will be displayed as well.
 * Wikimedia's standard CTA button with arrow is used in this mockup.

Here is the text copy for this option:

"Help improve this article

Did you know that you can edit this page?

Wikipedia works because anyone can edit its articles. Go ahead, give it a try. Be bold!

Learn how to edit >>

Edit this page  => "



Option 0
The last option we will give to users during the test in December will be no feedback form at all. (option 0)

Calls to Action (CTAs)
After readers post their feedback, they will see one of these calls to action (CTAs):
 * edit this article (for unprotected pages only - anyone can edit, even if they are not logged in)
 * take a survey (link to survey page) - this call to action may be postponed for a week
 * sign up or login (if logged out) - this call to action may be postponed for a week
 * get email notifications (if my post is used) - this call to action may be postponed for a week

Call to action selection criteria:
 * We will start the phase 1.0 test in December with only the 'Edit' call to action
 * After we have enough edit conversion data, we will introduce more CTAs in phase 1.3, on a random basis, with equal selection chances
 * If a page cannot be edited, we will display the 'get email notifications' CTA instead (or the survey CTA, if 'get email' CTA is not ready yet)
 * If a page cannot be edited and no other CTA is available in phase 1.0, we will display 'Saved successfully' in green text next to the 'Post your feedback' button (as AFT v4 does now)

CTA 1: Edit this page


This 'thank you' confirmation is shown after a user posts feedback, and includes a call to action (CTA). This CTA invites the user to try editing the article they just gave feedback (see earlier mockup for 1.3). We will start the test in December with only this call to edit for phase 1.0, but plan to add more CTAs in phase 1.3.

This a direct call for the readers to edit the article.
 * The "Edit" button takes the reader to the article's edit page.
 * The "learn how to edit" link takes the reader to this New Wikipedia Tutorial].
 * Both registered and anonymous users shall be able to edit the page, as per current Mediawiki functionality.
 * If the article is not editable by the user (according to its protection level), another call to action is to be displayed instead
 * If the user has been blocked from editing by Wikipedia, another interface option will be displayed as well.

Here is the text copy for this CTA:

{checkmark} Thanks! Your feedback has been.

Did you know that you can edit this page?

Wikipedia works because anyone can edit its articles. Go ahead, give it a try. Be bold!

Edit this page  =>

View Feedback Page >>

Learn how to edit >>

en:Wikipedia:Tutorial
 * The "learn how to edit" link takes the reader to the Wikipedia Tutorial:


 * Wikimedia's standard CTA button with arrow is used in the above mockup, which uses small versions of the button and arrow graphics.

CTA 2: Learn more


This a call to action for readers who can't edit this article -- to learn how they can contribute to Wikipedia.

This 'thank you' confirmation is shown after a user posts feedback on a page that is protected or semi-protected. It includes a call to action (CTA) that invites the user to learn more about improving Wikipedia. In phase 1.0, this CTA will be shown when a user cannot edit the page they gave feedback on, because it is protected (instead of showing the call to edit this article). More CTAs will be added in phase 1.5.

Here is the text copy for this CTA:

{checkmark} Thanks! Your feedback has been.

Help improve Wikipedia

This encyclopedia is created by people like you. Can you give us a hand?

Learn more =>


 * The "Learn more" button takes the reader to this New Wikipedia Tutorial].


 * Wikimedia's standard CTA button with arrow is used in the above mockup, which uses small versions of the button and arrow graphics.

CTA 3: Take a Survey


This call to action will be implemented in phase 1.2, after the first calls to action have been released. New images will be added later (a screenshot of current version from AFT v4 is provided here for reference, but the graphics will be changed to match the look and feel of CTA1 and CTA2 above).

The purpose of this Survey Call to Action (CTA3) is to learn what readers think about this article feedback tool, overall. We also want to find out which feedback form is most helpful to participants. This short survey will include three elements:
 * A. a call to action asking them to take the survey (CTA3)
 * B. a quick survey form
 * C. a thank you message

The survey CTA3 will be shown after filling the feedback form, and will be implemented using the same visual and experience style as other AFT5 calls to action. The quick survey form will be shown after they click 'Start the Survey', and will be implemented by Wikimedia using Survey Monkey, using a neutral style (see first version on Survey Monkey). The thank you message will also be implemented with Survey Monkey, using the same neutral style, linking to the tutorial on how to edit Wikipedia.

Starting on Jan. 25, this Survey CTA3 will replace the Edit CTA1 as our primary call to action, until we have collected a couple thousand responses in Survey Monkey's database. We will then switch back to the Edit CTA1 for the rest of the month, before alternating between more CTAs.

Here is our proposed copy and functional elements for each touch point below:

A. Survey Call to Action (CTA3):

√ Thanks! Your feedback has been saved.

Please take a quick survey It only takes a minute and will help improve Wikipedia.

[ START THE SURVEY ]

[this big blue button will link to one of the Survey Monkey forms -- one for each feedback option]

B. Survey Monkey - Quick Survey Form:

1. Why did you fill in the article feedback form today?

I want to: (check all that apply) [ ]  improve the article I was reading [ ]  make a suggestion [ ]  ask a question [ ]  give praise [ ]  report a problem [ ]  share my opinion [ ]  other [ ________ ]

2b. What do you think of that feedback form? I liked it. It helped me contribute to Wikipedia. I did not like it. I am not sure

3. Why? How can we improve that feedback form?

_________________________________

__________________________________

__________________________________

By submitting, you agree to transparency under these 

[ SUBMIT ]

C. Survey Monkey - Thank you Message

√ Thanks! Your survey response has been saved.

Help improve Wikipedia This encyclopedia is created by people like you. Can you give us a hand?

Learn more =>

[link to the tutorial on how to edit Wikipedia]

CTA 4: Sign up or login


This call to action will be implemented in phase 1.2, after the first calls to action have been released (a screenshot of the current AFTv4 version is provided here for reference).

We will adapt this current version of this CTA from AFT v4, with only minor changes to the wording, as well as look and feel.

CTA 5: Get email notifications
This CTA would only be displayed to anonymous users ("anons") or logged in members for whom we don't already have an email address. If such a user posts a comment, we will invite them to enter their email address, so we can notify them if their comment is used. We should also have a checkbox to make this message dismissable (e.g., "Don't show this again").

This is a new call to action, which doesn't already exist, though we may be able to adapt the post-survey CTA from AFT v4, with some minor changes to the wording. (We think the current CTA functionality allows dismissing, but only for a certain period of time.)

This call to action will be implemented in phase 1.3, after the first calls to action have been released (a screenshot of a current AFTv4 email capture form is provided here for reference).



Other calls to action
Other optional calls to action we are considering for phase 2 include:


 * discuss this article
 * view feedback page

Specs to be added later on, if we decide to include any of these in phase 1.5 or later.



Help Tool Tip


When you click on the question mark icon on any of the forms, you get a small tooltip that will link to the upcoming AFTv5 help page.

Here is the updated text copy for this tool tip:

"What's this?

Wikipedia would like to hear what you think of this article. Share your feedback with the editors -- and help improve this page.

Learn more >>"

'Learn more' should link to this correct URL for the help page link: w:en:Wikipedia:Article_Feedback_Tool/Version_5/Help

(this is what you would get when you click on the question mark icon in the feedback forms, then click 'Learn More')

Feedback links
To invite more user feedback, we recommend adding a prominent 'Feedback' link or button above the fold on article pages.

We also propose adding a prominent 'Feedback' link on talk pages, so that editors can quickly view feedback collected about a given article.

Feedback links on article pages
The purpose of this prominent feedback link on the article pages is to:
 * let readers know they can provide feedback, even if they are not yet ready to edit
 * increase the overall number of feedback posts (particularly for low-traffic articles)
 * increase the quality of feedback (assuming that we get more experts to respond as a result)

For discussion purposes, we explored 8 different placement ideas on article pages, as shown in this mockup of AFT5 feedback link options. Here are some of the options we have mocked up individually and discussed for this feedback link:
 * Option A: add feedback link below the article title (after Wikipedia slogan)
 * Option B: add feedback link below the article title bar (top right corner of page)
 * Option C: add vertical button in the right margin of the browser window
 * Option D: add horizontal button in the lower right corner of the browser window
 * Option E: add prominent horizontal button (see below) in the lower right corner of the browser window

Based on our current evaluation, only a couple of these ideas appear practical to implement at this time: Option A and Option E. (Option B has serious collision issues with geo-tags, Option C either overlaps with content or requires adding an extra margin, we had issues with all the options on the left side of the page (F and G), because they don't relate to the article and obscure these links and Option H introduces a lot of visual clutter by repeating the same long link for each section (for consistency, we want to use the same 'Improve this page' label as the form itself).

We started by testing Option D first, because it appeared the most practical and could give us an immediate boost to collect more data so we can measure the effectiveness of the forms. However, it generated fewer posts than the feedback form at the bottom of the page, because it was too small and hard to see. Next, we plan to test a more prominent version of that button, called Option E,  (a.k.a D2) with a larger font and a stronger color background, as shown below. We will be testing this option E against option A) and no links at all. The goal is to see which of these options generates the most responses with the least disruption, then implement the best of these solutions in the final version, based on test results.




 * Gallery of Option E elements:

Feedback Button 'X' Close box The Feedback button 'X' close box is a little [x] link or icon that will appear for logged in users only, when they mouse over the feedback button.

The purpose of this feature it to enable users to remove this button (as well as the article feedback forms), by changing their AFT user preference.

For logged-in users, this will display a flyover panel inviting users to change their user preference to disable the Article Feedback Tool (this disables both AFT4 and AFT 5). In the first version of this feature, logged-out users would not see the 'X' close box at all.

Feedback Close Box The feedback button at the lower right of the screen will include an 'X' close box when the mouse rolls over the button, as so: " Improve this page   X "

Flyover Panel When the user clicks on 'X' in the feedback button, this flyover panel will appear, as specified below.

"Remove this tool?           X To remove this Article feedback, go to  "My Preferences > Appearances," then check, "Don't show the Article feedback widget"

[ Go to my preferences ]   "

Flyover Links These links will be used when the user click inside the flyover panel:

- Go to my preferences / My Preferences > Appearances: http://en.wikipedia.org/wiki/Special:Preferences#mw-prefsection-rendering

- X: Close this flyover panel.

Story and Scenario for SCRUM development Here are the story and scenario for this feature, using the SCRUM method for agile development.

Story: User closes feedback button "As a Wikipedia logged in user, I want to make the feedback button go away, so that it doesn't clutter up my screen."

Scenario: "Given the user is logged in, and mouses over the feedback button to reveal 'X' box, when the user clicks on the 'X' box, then a flyover panel appears ('Remove this tool?') - When the user clicks on 'Go to my preferences', then the current browser window should display the user preferences (Appearances tab) - When the user checks (' [ x ] Don't show the Article feedback widget on pages'), then the feedback button (or form) should no longer appear when this user is logged in, until their user preference is changed again."

Note: We considered a more complex close box which would enable us to support logged-out users through cookies, but chose to postpone that feature until a later phase, once we get community feedback after we deploy the first version.

Overlay form
By default, the the feedback form would appear at the bottom of all article pages. Once a user clicks on a feedback link, the feedback form would appear as an overlay, moving from the bottom of the page to a location near the link, while the background is grayed out. If this proves difficult on some platforms, a fall-back option is to simply include a jump link to the feedback form at the bottom of the page.

Feedback links on talk pages
We are also discussing placement options for a new feedback link on article Talk pages for phase 1.5 or later. This shows three different ways in which a feedback link could be placed on the Talk page, linking to the feedback page where all reader posts are listed. It appears that this can be implemented via gadgets or hooks, and may not require Mediawiki core code changes are required for this requirement.



Feedback page
The feedback page will show feedback posts for a given article. Its contents will vary for different user groups, as outlined below:
 * Reader's view (basic feedback page)
 * Editor's view (intermediate page 1 for auto-confirmed editors)
 * Monitor's view (intermediate page 2 for rollbackers, reviewers or admins)
 * Oversighter's view (advanced feedback page)

Readers will get fewer tools than monitors or oversighters. Different views for different user groups are shown below. To learn more about proposed access and permissions to feedback features by user group, read the Access section below.

NEW: We are now planning another release of the feedback page in April 2012, which will provide additional features not included in our first release (e.g.: Feature this post, Mark as resolved), as well as tools for a new user group [auto-confirmed editors]. For a quick overview of our goals, check out these.

''Note: the features on this page are currently under discussion. The actual nature of the feedback we receive from readers (e.g., signal-to-noise ratio, what users actually comment on, etc.) will influence the design of the feedback page, so this preliminary design is likely to evolve once we start testing the first feedback forms.''



Basic Feedback Page - Reader's view


About this page The feedback page will display a list of the feedback posts for an article, as shown in the updated mockup above (see also earlier mockup, earlier Balsamiq wireframe, as well as earlier mockups and wireframes). Note that this reader view of the feedback page doesn't show editor tools - see separate wireframe in next section.

Who can use this page Anyone will be able to view this feedback page, as well as filter or sort its posts. Most users will also be able to indicate if the posts are helpful or not, as well as flag posts they find abusive or inappropriate. But only trusted editors with special access (e.g. admin, rollbackers, oversight) would be able to use special tools enabling them to hide or permanently delete some of the posts on this feedback page (see Access section).

Page Location The feedback page will be a stand-alone page, much like the Moodbar Dashboard (and will aim to borrow as much code as possible from that Moodbar extension). For the duration of our tests, this special page will not be connected to any of the standard tabs from the article page (Article | Discussion ... Read | Edit | History). However, we will provide text links to the article and talk pages at the top of that special page. (read more below).

How to get to this page This feedback page can be accessed in two primary ways: by clicking on the text links in the feedback forms and their calls to action, or clicking on a link to be added on the talk page. During an initial testing phase, these links will not be available to the public.

Overview panel The feedback page will include an overview panel at the top of the page, to provide overall info about the feedback posts for this article:
 * Page label ('Special page' for now)
 * Page title (e.g.: 'Feedback: Golden-crowned Sparrow')
 * Number of posts (excluding any hidden or deleted posts)
 * Feedback icon (e.g.: happy, sad or confused face based on rating average)
 * Feedback summary (e.g.: '75% found what they were looking for' for option 1)
 * Links to other related pages:
 * View article
 * Talk
 * Help

Icons We will use updated the happy/sad face icons from the Moodbar Dashboard, for consistency. They have a flatter background color, instead of the earlier version, which was more shaded.

Toolbar The feedback page will provide a toolbar allowing users to sort or filter the list of feedback posts. This toolbar will have a flat background color, with no gradients.

Filters This feature (labeled 'Showing') will filter the feedback page to only show posts that match certain pre-defined tags. This will be a predefined set of options, to be determined after we analyze the feedback stream. (Note that we are now proposing to display 'Showing' before 'Sorting', see monitor's view below for updated mockup). Here is a preliminary list under review: Each filter option above will include a counter showing the number of posts tagged with that filter -- e.g: 'Hidden (6)'.
 * Basic filters (available to all readers)
 * Comments only (only show posts that have a comment -- this would be checked by default at launch)
 * Helpful (only show posts which users found helpful -- by clicking on the 'Yes' button)
 * All visible (show all posts which have not been hidden or deleted)
 * Monitor filters (only available to 'monitors' -- editors with rollbacker, reviewer, admin and/or oversight access)
 * Unhelpful feedback (only show posts which users found unhelpful -- by clicking on the 'No' button)
 * Flagged for abuse (only show posts flagged by readers as abusive)
 * Hidden (only show posts hidden by editors)
 * Un-hidden (only show posts recently un-hidden by editors)
 * Oversight requested (only show posts for which oversight has been requested by editors)
 * All (show all posts, including hidden, but not oversighted)
 * Oversight Filters (only available to users in 'oversight' group)
 * Oversighted (only show posts permanently deleted by oversight)
 * All (show all posts, including hidden and deleted)

Sorting The 'Sort by' function will provide a predefined set of sorting options. These will be simple text links with up/down arrows next to links, which would only be shown after the user has selected one of these options. The currently selected sort item will be bolded for clarity.
 * Date:
 * Newest - show the most recent posts first (default)
 * Oldest - show the earliest posts first
 * Helpfulness
 * Helpful - show the posts with the highest helpfulness score first (based on a score equal to the number of 'Yes' answers minus the number of 'Nos')
 * Unhelpful - show the posts with the lowest helpfulness score first (based on the same score from 'Yes/No' responses)
 * Rating:
 * Highest - show the posts with the highest article ratings first
 * Lowest - show the posts with the lowest article ratings first (e.g.: average of 'Yes/No' responses for feedback form option 1)

Feedback contents Each feedback post listed on this page will display these content items:
 * Logged user name (or IP address), with link to user page
 * Article rating icon (happy/sad face next to user name, based on user's article feedback)
 * Article rating label (e.g.: 'found what they were looking for', based on user's 'Yes/No' answer for option 1)
 * Comment (truncated comment -- show first 500 letters, then click 'More' to see the rest -- current average is 113 letters or 23 words per post)
 * 'More' button (if comment is over 500 letters) showing expandable sub-section with full comment (collapsed by default)
 * Timestamp (show 'x days, hours, minutes ago' -- all the way up to 48 hours, then just show date and time -- also acts as perma-link to that particular post)
 * View article revision (previously called 'View original version' or '152 edits since this post', linked to an earlier revision of the article at the time the feedback was posted.)

Helpfulness At the bottom of each feedback post, readers will be invitee to evaluate its helpfulness with a few simple pre-defined tagging functions:
 * Helpfulness Flags ('Is this feedback helpful?' with 'Yes/No' buttons mapped to 'helpful' and 'unhelpful' tags)
 * Response counter (e.g.: '4 yes / 2 no', shows number of responses to helpfulness question, could eventually use color coding to indicate if the post was found helpful [green] or unhelpful [red])

Flag as abuse At the bottom of each feedback post, readers will have the option to flag abusive feedback. We are now showing it on the same line as the 'Is this helpful?' buttons, right-aligned, in smaller font, but with blue highlight, so people know it's clickable. This is a toggle button, so on your first click, the label changes to 'Flagged as abuse' and on your second click, it changes back to 'Flag as abuse.' A counter is shown as soon as one person has flagged a post. Once 3 people have flagged a post, the link color becomes red; once 5 people have flagged the post, it is automatically hidden. This function includes these elements:
 * Flag as abuse (a text link for flagging inappropriate posts -- works as a toggle, tagging the post on the first click, untagging it on the second click)
 * Flag counter (number of flags from users, shown in parenthesis)

Tools Editor tools would be shown on rollover in the right margin -- and would only be visible to authorized editors. (see next section)

Show more posts At the bottom of the page, a wide button would let you load more feedback posts. The feedback page would display up to 50 feedback posts by default (this number could be changed by Wikimedia based on user feedback, but no need to give user control of number of posts right now.) Initially the "Show more" button at the end of the list would load additional posts, same amount, and, again, display the "show more" button at the end of the list. In a later stage, better pagination may be provided, as needed. (see below)



Intermediate Feedback Page 1 - Editor's view


About this page NEW: This intermediate version of the feedback page includes special tools which would only be visible to 'auto-confirmed editors', as shown in the new mockup above. Note that the basic version in the previous section doesn't show these editor tools. Auto-confirmed editors would have access to the 'Feature this post', 'Mark as resolved' and 'View Activity' tools below (but would NOT have access to 'Hide' and 'Request oversight' tools, which would be reserved for monitors -- or the 'Oversight' tools, which would be reserved for oversighters -- see sections below).

To learn more about proposed access and permissions for these editor tools by user group, read the Access section below.

Tools If you are an 'auto-confirmed editor', a 'Tools' panel will be shown on the right of each post. Each panel will be set against color background, such as the light blue in the current mockup.

These editor tools will include these features for each post:
 * Feature this post - promote useful feedback to editors
 * Mark as resolved - check off completed tasks in the featured list
 * View activity - track actions taken by other editors or community members for this post

These tools are described one at a time below. This Tools panel will only be visible to auto-confirmed editors, monitors and oversighters. And this Tools panel will show more tools if you have a higher access level, so the oversighters will see a different view (see next section).

Feature this post The 'Feature this post' function's purpose is to enable 'auto-confirmed editors' to promote useful posts to community members, as well as add a note about why they are featuring these actionable posts. This note will be listed in the activity panel, so other editors can track the status of this post as a group.

When people click on the 'Feature this post' link, a small flyover sub-panel opens up, with a text box and 'feature' button, to let you add a note at the same time as you feature this post.



Here are the contents of this 'Feature this post' panel:

Feature this post                                                  X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Add a note:

[ Why are you featuring this post? . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ]             (text field) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ Feature this post ]                 Learn more                          (button)

Note that the ability to add a note is an important requirement from the community. For Moodbar, community members specifically asked for a feature that would let editors leave a note explaining why they chose to hide. So we need to make sure that every time we have a feature/hide/oversight action that the editor can provide a note. This design allows us to do that effectively.

Here's what happens when a user clicks on 'Feature this post' in the flyover panel:
 * the feature flyover panel closes.
 * the 'Feature this post' link is replaced with 'Un-feature this post' link, which acts as a toggle.
 * a new text link appears: 'Marked as resolved (below the 'Un-feature this post' link), only available for featured posts.
 * a green line of text is shown at the top of the post: 'This post was featured by on . '.
 * a gray 'Featured' label appears after the date (or link to old article) for each post that has been featured, to make readers aware of its status.
 * this post is tagged as 'Featured' (so it is added in the 'Featured' drop down filter).
 * this featured activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below).
 * featured posts are shown more prominently in the default view of the home page.

If you click on 'Learn more', a new tab or window opens with the matching help page for editors, moderators or oversighters, depending on your user status.

If you click on 'X' (or click anywhere outside the feature panel), the flyover panel closes.

To un-feature a post, click on the 'Un-feature this post' link, which will revert to the previous state and settings.

Mark as resolved The 'Mark as resolved' function's main purpose is to enable 'auto-confirmed editors' to identify feedback about issues that have been resolved, as well as add a note about why they are marking a post as resolved. This note will be listed in the activity panel, so other editors can track the status of this post as a group.

When people click on the 'Mark as resolved' link, a small flyover sub-panel opens up, with a text box and a 'Mark as resolved' button, to let you add a note at the same time as you mark this post.



Here are the contents of this 'Mark as resolved' panel:

Mark as resolved                                                 X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Add a note:

[ Why are you marking this post as resolved? . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ]             (text field) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ Mark as resolved ]                 Learn more                          (button)

Here's what happens when a user clicks on 'Mark as resolved' in the flyover panel:
 * the 'Mark as resolved' flyover panel closes.
 * the 'Mark as resolved' link is replaced with 'Un-mark as resolved' link, which acts as a toggle.
 * a green line of text is shown at the top of the post: 'This post was marked as resolved by on . '.
 * a gray 'Resolved' label appears after the date (or link to old article) for each post that has been marked as resolved, to make readers aware of its status.
 * this post is tagged as 'Resolved' (so it is added in the 'Resolved' drop down filter).
 * this 'Marked as resolved' activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below).
 * Mark as resolved posts are shown less prominently in the default view of the home page.
 * Note that 'Mark as resolved' does NOT remove the post from the 'Featured' list (only 'Un-feature this post', 'Hide' or 'Oversight' can remove it), but it moves it to the bottom of that 'Featured' list.

If you click on 'Learn more', a new tab or window opens with the matching help page for editors, moderators or oversighters, depending on your user status.

If you click on 'X' (or click anywhere outside the feature panel), the flyover panel closes.

To un-mark a post as resolved, click on the 'Un-mark as resolved' link, which will revert to the previous state and settings.

To learn more about 'View activity', read the next section below.

Intermediate Feedback Page 2 - Monitor's view


About this page This intermediate version of the feedback page includes special tools which would only be visible to 'monitors' (rollbackers, reviewers, administrators and/or oversighters), as shown in the updated mockup above. (See also, as well as earlier Balsamiq wireframe, earlier mockup] and [[:commons:File:Article-Feedback-Page-Simple-Wireframe-Admin-Tools-V5-11-10.png|earlier wireframe). Note that the basic version in the previous section doesn't show these editor tools.

NEW: Auto-confirmed editors would have access to the 'Feature this post', 'Mark as resolved' tools described above (and the 'View Activity' tool below), but would not have access to 'Hide' and 'Request oversight' tools (reserved for monitors), or to the 'Oversight' or 'Decline oversight' tools (reserved for oversighters).

To learn more about proposed access and permissions for these editor tools by user group, read the Access section below.

Tools If you are a 'monitor', a 'Tools' panel will be shown on the right of each post. Each panel will be set against color background, such as the light blue in the current mockup.

These monitor tools will include these features for each post:
 * Feature this post - promote useful feedback to editors (see above section)
 * Mark as resolved - check off completed tasks in the featured list (see above section)
 * Hide this post - remove the post from view and mark it as hidden
 * Request oversight - ask that this post be 'oversighted' (permanently deleted), if it is illegal or highly inappropriate
 * View activity - track actions taken by other editors or community members for this post

These tools are described one at a time below (except for ''Feature this post' and 'Mark as resolved', already described in the previous section). And this Tools panel will show more tools if you have a higher access level, so the oversighters will see a different view (see next section).

Feature this post See previous section for feature description.

Mark as resolved See previous section for feature description.

Hide this post The hide function's purpose is to enable 'monitors' to hide a post, as well as add a note about why they are hiding that post. This note will be listed in the activity panel, so other editors can track the status of this post as a group.

When people click on the 'Hide this post' link, a small flyover sub-panel opens up, with a text box and 'hide' button, to let you add a note at the same time as you hide.



Here are the contents of this 'Hide this post' panel:

Hide this post                                                  X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Add a note:

[ Why are you hiding this post? . . . . . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ]             (text field) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ Hide this post ]                 Learn more                          (button)

Here's what happens when a user clicks on 'Hide this post' in the flyover panel:
 * the hide panel closes
 * the hide link is replaced with 'Un-hide this post' link, which acts as a toggle
 * A red line is shown at the top of the post: 'This post was hidden by on . '.
 * a gray mask covers the 'Hidden' post, as described in the next section below
 * this post is tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter)
 * this hiding activity is recorded in this post's activity log, as well as on other site logs (new requirement, see below)
 * hidden posts are no longer visible to anyone but hiders or oversighters

If you click on 'Learn more', a new tab or window opens with the Revision/Delete policy page (WP:RVDL). In a later stage, we plan to provide an interstitial page to explain to users what the 'Hide' function does and how it relates to Wikipedia's Revision/Delete policy, so they do not get confused with a page that is largely about deleting pages on Wikipedia.

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To un-hide a post, click on the 'Un-hide this post' link, which will revert to the previous state and settings.

Hidden Post Once a post is hidden, it is covered by a light gray opaque panel, so that its contents are not visible by default.



A red line is shown at the top of the post: 'This post was hidden by on. '.

A large label says: 'Feedback hidden by administrative action. View contents >>                          Post #24,862'

To see the hidden post, click on 'View contents' or click anywhere.

This removes the gray panel, revealing the post as it was before it was hidden, except that it is still grayed out with a translucent mask.

A post ID number is provided, so that a user can search for it or refer to it. It links to the permalink for that post.

Note: When a hidden post is shown by itself on the permalink page for that post, it will include a prominent text link below the gray mask: 'Go to feedback page'. Clicking on that link will cause the feedback page to reappear.

Request oversight The 'request oversight' feature's main purpose is to enable hiders to request oversight from a small group of oversighters, asking them to permanently delete illegal or inappropriate content (what Wikipedians call 'oversight').



Only hiders can see or use this 'Request oversight' feature. When they click on the 'Request oversight' link, it makes a small flyover overlay appear:

Request oversight                                                 X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Add a note:

[ Why are you requesting oversight? . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ]             (text field) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ Request oversight and hide ]   Learn more               (button)

The 'Request oversight' feature works pretty much the same as 'Flag for abuse', with these specific requirements: Here's what happens when a user clicks on 'Request oversight' in the flyover panel:
 * We will now use the word 'oversight' throughout the extension (instead of 'delete' or 'delete/oversight'), to avoid confusion with the word 'delete', which is used in a different context on Wikipedia.
 * Any 'hider' (admin/rollbacker/reviewer) will have the right to 'request oversight' (readers can use 'flag for abuse' to report inappropriate feedback, or just email the permalink to an oversighter).
 * We will not show the number of requests in the counter (based on Philippe's observation that it might encourage oversighters to only oversight posts based on how many people have requested it, when they should be oversighting them all).
 * This link will be a toggle, so you can 'un-request oversight' if you think the problem has been solved. This only cancels your own request, not other requests for oversight, though.
 * Clicking on 'Request oversight' also has the effect of 'hiding' the feedback post, pending further review.
 * Note: WMF's legal department would like 'oversight-requested' posts to only be visible to oversighters (and to the persons who requested oversight), but not to hiders. We are investigating this request, and trying to determine the most effective way to implement it.
 * the 'Request oversight' panel closes
 * NEW: the 'Request oversight' link is replaced with 'Un-request oversight' link, which acts as a personal toggle switch for the user(s) who requested the oversight.
 * NEW: for all other monitors, the 'Request oversight' link is replaced with 'Oversight requested'
 * For oversighters only: the 'Request oversight' link is replaced with 'Decline oversight' link, to enable oversighters to decline requests for this post.
 * the 'Hide this post' link is replaced with 'Un-hide this post' link, which acts as a toggle (requesting oversight also hides the post)
 * A red line is shown at the top of the post: 'Oversight was requested and this post was hidden by on . '.
 * a gray mask covers the 'Hidden' post, as described in the section above
 * this post is tagged as 'Oversight requested' (so it is added in the 'Oversight requested' drop down filter)
 * this post is also tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter, if not already hidden)
 * this oversight request and hide activities are recorded in this post's activity log, as well as on other site logs (new requirement, see below)
 * an email is sent to the oversight list, with a link to this post's permalink (new requirement, see below)

If you click on 'Learn more', a new tab or window opens with the Revision/Delete policy page (WP:RVDL).

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To undo a request for oversight, click on the 'Oversight requested' link, which will revert to the previous state and settings.

View activity The purpose of the Activity log is to enable trusted editors to track article feedback moderation and coordinate their activities as a group.

A 'View activity' link in the Tools panel opens up a special overlay panel, which lists the activity for that post, in reverse chronological order, like History. This panel shows who did what to this post, listing each action with a user name/ID, as well as when they did it and why (if they left a note).



The Activity panel includes these elements:

Activity                                              (?)  (X) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Feedback post <postID> by Posted on [permalink] - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 10 actions for this post - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - deleted this post on [red] requested oversight on hid this post on [red] un-hid this post on <AFT extension> auto-hid this post on [red] flagged this post on flagged this post on  flagged this post on  flagged this post on  flagged this post on - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Show more actions >>

By default, we would list the last 25 actions on this activity panel, to be viewed using the scrollbar. When a user gets to the bottom of the scroll, they can click "show more actions", we simply show another 25 actions.

Here are some of the data requirements for this activity log: a. Actions to be tracked: flag as abuse, unflag, hide, unhide, request oversight, unrequest oversight, oversight, un-oversight, decline oversight b. Data needs to be tracked for each action: User name, Post ID, article ID, action date, action taken, action note (if any) c. Retention time for activity: Forever -- or whatever policy Wikipedia now has for tracking edits on its articles (there may be some archiving going on after a few years).

<br style="clear: both" />

Advanced Feedback Page - Oversighter's view


About this page This advanced version of the feedback page includes special tools, which would only be visible to a small group of 'oversighters', as shown in the updated mockup above (see also ). Note that the other views of this tool in the previous sections don't show these oversighter tools. To learn more about proposed access and permissions for these editor tools by user group, read the Access section below.

The proposed workflow for oversight practice for the Article Tool Feedback is described in (see thumbnail to the right) and detailed in  (Option 4 is the recommended solution supported by the requirements below).

Tools If you are part of the Oversight group, you will see these tools, which are described in more depth below:
 * Hide this post (or 'Show this post' if it has already been hidden)
 * Oversight this post
 * Decline oversight
 * View Activity

Oversight this post The 'oversight this post' feature's main purpose is to enable a small group of oversighters to permanently delete illegal or inappropriate content (what Wikipedians call 'oversight').

Only oversighters can see or use this oversight feature. When they click on the 'Oversight' link, it opens a small flyover panel:

Oversight this post                                                 X - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Add a note:

[ Why are you oversighting this post? . . . . .  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .  ]             (text field) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [ Oversight this post ]   Learn more                                  (button)



Oversighters are requested to add a note about why they are oversighting (permanently deleting) a post. These notes are listed in the activity panel, so other editors can track the status of these posts as a group.

Here's what happens when a user clicks on 'Oversight this post' in the flyover panel:
 * the 'Oversight this post' panel closes
 * the 'Oversight this post' link is replaced with 'Oversighted' link (which acts as a shared toggle switch, just like 'Hide/show this post')
 * the 'Hide this post' link is replaced with the 'Show this post' link (oversighting also hides the post, if not already hidden)
 * A red line is shown at the top of the post: 'This post was oversighted and hidden by on . <View activity>'.
 * a gray mask covers the 'Hidden' post, as described in the next section above - only visible to oversighters
 * this post is tagged as 'Oversighted' (so it is added in the 'Oversighted' drop down filter)
 * this post is also tagged as 'Hidden' (so it is added in the 'Hidden' drop down filter, if not already hidden)
 * this oversight and hide activities are recorded in this post's activity log, as well as on other site logs (see below)
 * oversighted posts are no longer visible to anyone but oversighters

If you click on 'Learn more', a new tab or window opens with the Oversight policy page (WP:Oversight).

If you click on 'X' (or click anywhere outside the hide panel), the flyover panel closes.

To undo an oversight, click on the 'Oversighted' link, which will revert to the previous state and settings.

Even when a post is oversighted, its permalink still works, taking you to a page with only that post, covered by a gray mask (note that you need to be an oversighter to open it).

Decline oversight If an oversighter clicks on 'Decline oversight', all previous oversight requests are cancelled, if any -- and the link name changes to 'Oversight declined'

At that point, any hider can choose to hide, or request oversight again -- and any overnighter can still choose to oversight, as needed.

Oversight states: The 'oversight' feature has these four main states:
 * original state (blank)
 * oversight requested
 * oversighted (and hidden)
 * oversight declined => original

If oversight is declined, the state goes back to original state, and wipes out all oversight requests, if any.

Oversight behavior:
 * Multiple people can request oversight
 * Requesting oversight sends an email to OTRS (Open-source Ticket Request System), which emails oversighters
 * The email to oversighters will be plain text, and include a link to the post (but doesn't need to have the user's email address in the "from" field).
 * It's okay to have multiple oversight email notifications, each time an oversight request is made
 * Requesting oversight automatically hides --> only hiders can request oversight
 * Oversighting simply means hiding from everyone without oversight privileges -- they will not see oversighted posts at all
 * Oversighters will see "hidden by administrative action" and need to click through to view, where they can oversight
 * We will emulate the workflow for Feedback Dashboard, but use different visuals (Fab to send OmniTI screenshots separately)
 * The 'Staff user' group (and a special 'aft5test' group) would enable members of WMF's team to oversight posts during a limited testing period

Advanced Filtering Oversighters will have access to more filtering options than regular users in the 'Showing' drop-down menu on the toolbar.

So the drop-down menus should read, for each user group:

Readers/Anonymous/Autoconfirmed: - Comments only - Helpful - All visible

Hiders (Rollbackers, reviewers, admins): - Comments only - Helpful - All visible - - - - - - - - - - - - - - Un-helpful - Flagged as abuse - Hidden - Un-hidden - Oversight requested - Oversighted - Un-oversighted - Oversight declined - All

Oversighters (and 'afttest' group): - Comments only - Helpful - All visible - - - - - - - - - - - - - - Un-helpful - Flagged as abuse - Hidden - Un-hidden - Oversight requested - Oversighted - Un-oversighted - Oversight declined - All (with oversighted)

Related Features
Here are a couple related features related to the Feedback page, but which take place in other parts of the site.

Article feedback log  (sitewide) The purpose of the Article feedback log is to provide a central listing of all actions taken on feedback pages, from across the site. It will enable oversighters and WMF staff to track all this activity on a single page, which we hope will make their lives easier and the tool more useful.

It will be based on the exact same technology used by Wikimedia for its other log pages, such as this one for the Moodbar Feedback filter: http://en.wikipedia.org/w/index.php?title=Special%3ALog&type=moodbar&user=&page=&year=&month=-1&tagfilter=&hide_patrol_log=1&hide_review_log=1

A special 'Article feedback activity log' item will be added to the drop down menu on this page, to filter only log events related to AFT5 (as done now with Moodbar 'Feedback').

This log will track the following actions: hide/unhide, oversight/un-oversight (as well as 'request oversight' and 'decline oversight').

For each such action, it will provide these data: action date, user name of person who took the action, action taken, user name of person who posted the feedback, article name, post ID, action note (if any).

No special look and feel is needed for this simple log page, all we need is to do is provide the data and integrate it with the public log system.

NEW: Only oversighters and staff will be able to access to the central Article Feedback Activity log. This restriction will be implemented by using the log_type='suppress' for this oversighter log. This should hide the log, because $wgLogRestrictions = array( 'suppress' => 'suppressionlog' ); is set in DefaultSettings.php, meaning that log entries with log_type='suppress' can only be viewed by users with the 'suppressionlog' right. We will also remove the 'del/undel' function now shown to oversighters/staff in the current version of the Article Feedback Activity log, since it isn't really needed for this type of content. However, if this is not easy to do, or would take a long time to do, we can live with it for this release.

Here is our proposed new format for this centralized AFT5 activity log for oversighters:

"18:54, 6 March 2012 Okeyes (WMF) (talk | contribs | block) flagged as abuse feedback posted by User:Philippe (WMF) at Special:ArticleFeedbackv5/Golden-crowned Sparrow/480"

... instead of old format:

"(del/undel) 18:54, 6 March 2012 Okeyes (WMF) (talk | contribs | block) flagged the feedback Special:ArticleFeedbackv5/Golden-crowned Sparrow/480 as abuse."

Oversight Request Emails The purpose of the Oversight Request Emails is to provide oversighters with email notifications whenever anyone requests oversight on any feedback page, from across the site. It will enable oversighters to respond more quickly to requests from trusted editors (admins, rollbackers, reviewers, oversighters, and/or WMF staff), using the 'Request oversight' function described above.

No special look and feel is needed for this plain text message, all we need is to do is provide a simple message with a unique link and integrate it with WMF's email notification system.

<br style="clear: both" />

Access and permissions

 * Any user can post feedback about an article, whether they are logged in or not.
 * Users can post multiple comments per article, if they have several suggestions. We may consider throttling is spam becomes an issue.
 * For logged in users, feedback is posted under their user account (the IP address shall still be recorded, but available only to users with CheckUser permissions).
 * For anonymous or logged out users, feedback is posted under their IP address.
 * Anyone can view the feedback page, including blocked users.
 * Anyone can rate any post on the feedback page ('Was this feedback helpful? Yes / No').
 * Readers can flag a post for abuse, but cannot hide or delete posts unless they have rollback or oversight privileges.
 * Rollbackers (editors with rollback privileges) can hide offensive posts from view by readers (and/or view hidden posts).
 * Only editors with oversight privileges can permanently delete posts (and/or view deleted posts).
 * Blocked users who cannot edit on Wikipedia may not post feedback either

Different user groups will have access to different tools (as shown in this comparative wireframe. This preliminary matrix lists key user groups and AFT features under consideration, with proposed access levels shown in green for each item (see of that matrix).

Here is a list of the proposed permissions:

Please note that this matrix is for discussion purposes only and is likely to change based on responses from the community as well as Wikimedia decision-makers. Some features listed above are still under consideration and may not be included in our first releases. This chart is based in part on this page for Wikipedia-EN User Access Levels.

Our overall goal is to tie-in with existing Wikipedia user groups and processes, rather than create new processes from scratch. For example, the current 'rollbacker' group (users with rollback permissions) would be enabled to hide (or show) offensive posts, as well as view hidden posts. And the current 'oversight' group would have the right to permanently delete (or undelete) posts containing illegal material (e.g. posts with links to child pornography).

Blocked users would only be able to view the feedback page, but not post any comments or ratings. Users who think their IP address is blocked unfairly may request special access from Wikimedia. These ideas are for discussion purposes, and will be the subject of an upcoming Request for Comments in January 2011.

<br style="clear: both" />

Features under consideration'''
These features are being considered for phases 1.5, 2 or beyond.

Captcha on protected articles This feature would require users to fill in a Captcha before they can post feedback on controversial articles (protected and semi-protected), to reduce the quantity of inappropriate feedback.

Restrict feedback posts for protected articles This feature would require users to be registered or auto-confirmed before they can post feedback on controversial articles, to reduce the quantity of inappropriate feedback. A variation on this theme would be to allow everyone to post, but always show posts from trusted users first, then registered users, then anonymous.

Restrict access to feedback page for protected articles This feature would require users to be registered or auto-confirmed before they can view the feedback page for controversial articles, to reduce the quantity of inappropriate feedback. A variation on this theme would be to allow everyone to view the feedback page, but only give the 'Showing ...' filtering option to registered users.

Special filters on protected articles This feature would only display helpful feedback for protected articles, to prevent visitors from being exposed to inappropriate feedback. This would simply be done by changing the default filter to 'helpful' (or other 'relevant' or 'recommended' filter, see below), as opposed to showing all feedback.

Feature this post This feature would enable trusted editors to prominently feature a post at the top of the feedback page, as well as include that post in the 'Featured' and 'Relevant' filter groups (see below). This would allow editors to spotlight the best feedback, to surface quality suggestions above the noise of less relevant posts.

Relevant filter This feature would enable users to see a filtered view of a feedback page, by only showing posts marked as helpful, as well as posts from trusted users (e.g.: editors with high edit counts, wiki love or other reputation metric). If we implement 'Feature this post', featured posts could also be added. This 'Relevant' filter could be used as the default for protected articles. We might even be able to use 'Relevance' as a 'Sort by' item as well.

Customizable feedback display This feature would enable editors of an article to determine whether or not to display a feedback page for that article, as well as to control its default filter to meet their needs (e.g. 'Comments only', 'Helpful', 'Featured', 'Relevant', etc).

Search This feature would enable users to type in a search query in a text box, then click 'Search' to show only posts that match the query. This would be particularly useful for showing all the posts from a given user -- or posts that mention a particular topic.

Show all posts by a user When registered & logged-in users reload the page after providing feedback for an article, the feedback form is reset and ready for a new comment, even if they provided feedback earlier. If a logged-in user previously entered feedback, show this text confirmation in small gray font at the bottom of the form, to the right of the 'Post it button': 'See your last posts >>' ... with a link to a filtered view of the feedback page that shows only that user's posts for that article, a bit like we do now on permalink, but with all that user's posts.

Pagination As the volume of feedback increases, pagination features could be included at the bottom of each page, as needed (instead of a 'Show More' button, which may not be as practical for this purpose).

Email this user This feature would let editors email a user who has posted feedback, to follow up with questions, praise, issues, etc. Initially, this could simply open your email application with that user's email filled in (only show this if an email address is available for that purpose). Eventually, it could be integrated into a 1-on-1 messaging system.

Add Comments In phase 2, this page's functionality would support nested comments (that will be reflected both in the database schema and in code infrastructure), but this functionality will not be available in the interface for the first phase. The infrastructure should not impose limits on the depth of the comments tree. If such limits are to be introduced at later phases of the project, they shall be set in the code/configuration.

Add your feedback In phase 2, we will consider adding a button to enable people to add their feedback on this article, if they haven't already. This button could link to the article page, with form overlay.

Show posts on contribution page This feature would allow my feedback posts to be listed on my contribution page, so that my feedback is tracked in the same way as my edits.

Recognize helpful posts This feature would recognize helpful posts with a special icon on my contribution page, and add a special badge on my Talk page once 10? of my posts have been deemed helpful, to reward me for my contribution and make me want to do more.

Talk link This would be a simple link to a user's talk page, shown next to their name, to follow up with questions, praise, or issues about their feedback.

Talk page section Once the feedback page is working well as a stand-alone listing, we would like to start integrating on the talk page, where editors already gather regularly to discuss improvements to articles. One possible way to do that would be to create a special talk page section, which could be expanded or collapsed at will, as suggested by this very rough wireframe.

Promote to talk We would like to make it easy to promote a feedback post to the talk page, so that editors could discuss it before taking action about it.

To-do list We would like to make it easy for editors to add the best feedback posts to a to-do list, where volunteers could sign up for assignments and report back when they have been completed, a bit like Bugzilla or other bug tracker services.

Status Panel This panel would show the status of a given post:
 * Post to Talk page - Link to post item to talk page (manually at first - automated version would be for phase 2)
 * Add in To-Do list - Link to add item in to-do list (manually at first - automated version would be for phase 2)
 * Issue Resolved - Link to indicate that the issue has been resolved  (manually at first - automated version would be for phase 2)

More Filters
 * Future Filters (phase 2?)
 * Featured feedback (posts recommended by editors - phase 2?)
 * Most Relevant (show Featured first, then Most Helpful with comments, then Most Recent with comments)
 * Active feedback (posts with the most comments or tags by community - phase 2?)
 * Content type filters
 * More info (posts that request specific info)
 * More references (posts that request references)
 * More pictures (posts that request pictures)
 * Workflow filters
 * New feedback
 * Posted on Talk page - phase 2
 * Posted on To-Do List - phase 2
 * Resolved - phase 2
 * Filter by User Group (phase 2?)
 * Feedback by Editors/Admins only
 * Feedback by Registered Members
 * Feedback by Anonymous Users

Tagging
 * Tag this post (funtionality TBD)
 * User tags for this post (if applicable)

'''Show tools It is likely that busy editors may want rapid access to all of the tools at a glance, so we may want to consider having a show/hide function that opens the panel by default.

Expanded feedback If an expanded feedback section is implemented (see section at bottom of page), we would display an 'Expanded feedback' link in each feedback post.

<br style="clear: both" />

Abuse/Spam Filters
Because Wikipedia gets so many visitors, it is likely that a good portion of the feedback will include abuse, spam and junk posts. To filter some of this unusable feedback, we are researching automated filtering technology which could help identify questionable comments as they are posted, based on their contents, sources and/or destination. This software could either flag these comments for review by an editor -- or prevent users from posting them in the first place, for clear machine-detectable policy violations.

We expect to use a number of different software tools to parse all comments, looking for a variety of telltale signs of abuse, spam or junk:
 * offensive words (e.g.: 'f*** you')
 * links to known spam sites
 * gibberish (e.g.: the same character repeated more than 10 times?)
 * email addresses (e.g.: anything with a '@' symbol?)
 * posts from repeat offenders (e.g.: users with 10 or more feedback posts flagged for abuse this month?)

In a first phase, we will investigate the feasibility of leveraging these two popular extensions of the MediaWiki software:


 * AbuseFilter by Andrew Garrett (Werdna)
 * SpamBlacklist by Tim Starling

In the next phase, we will aim to use and/or adapt these tools for AFTv5 purposes, and integrate them with the feedback forms and feedback pages, as needed and where practical.

<br style="clear: both" />

Expanded Feedback


For phase 2 of this project, we are considering an expanded feedback form, which could let readers suggest specific improvements, rate article qualities or share their expertise. The preliminary wireframe above assumes that an expandable/collapsable text link enables users to display this form ('Tell us more').

Feedback inputs
For each article, the following feedback user inputs shall exist:
 * Text comment
 * Yes/No Answers (option 1 only)
 * Comment tag, one and only one of: (option 2 only)
 * Suggestion
 * Question
 * Problem
 * Praise
 * Ratings (option 3 only)
 * Overall rating

<br style="clear: both" />

Other data
Feedback records will also include for each post:
 * time-stamp
 * yes or no votes given by other users for this post
 * abuse flags from other users about this post
 * admin status: whether this post has been hidden or featured by moderators

Other feedback items from expanded forms may include, if applicable (phase 2):
 * Checked suggestions for improvement (e.g.: "Need more links")
 * Commenter's source of knowledge on the subject (pre-defined options TBD)
 * Section which the user is giving feedback about (if that option is available in expanded feedback, or recorded through link placement next to edit button)
 * Number of words or characters in user comments
 * Comments made by other users in response to this post

To learn more about proposed access and permissions to feedback features by user group, read the Access section below.

<br style="clear: both" />

Technical requirements

 * The AFT v5 shall be developed using much of the existing AFT implementation (MediaWiki extension). However, the AFT v4 tool will remain a separate code module, and the two will co-exist on the same server. Some of the current functionality v4 functionality will continue to be supported in v5, e.g.:
 * Feedback tool can be disabled in user preferences for registered users
 * Source control requirements:
 * Core - use v1.18 (REL1_18)
 * Extensions - from trunk
 * AFT being developed as an extension, branched from trunk
 * The AFTv5 shall be able to install together with AFTv4. Only one (i.e. either AFTv4 or AFTv5) shall be displayed on the page. To further clarify, the AFTv5 shall replace AFTv4 on a predefined subset of articles for the period of testing.
 * However, the same user preference used to disable AFTv4 shall also be used to disable AFTv5.

<br style="clear: both" />

Platforms
We aim to support the following web browsers for phases 1.0 and 1.5:
 * Internet Explorer 8+
 * Firefox 3+
 * Safari 5+
 * Opera 10+
 * Chrome 5+

We will focus our testing on these top browser versions for Wikipedia:
 * IE 8			(17%)
 * Chrome 14	       (16%)
 * Firefox 7		(11%)
 * IE 9			  (6%)
 * Firefox 3		  (5%)
 * Firefox 6		  (2%)

These will be tested on these desktop platforms:
 * Windows	(78%)
 * Mac		 (8%)
 * Linux		 (3%)

We are not currently planning to support IE6, IE7 or mobile platforms for phase 1.0, and will not show the forms at all on these unsupported platforms.

In future versions, we will aim for 'graceful degradation' in unsupported platforms, and are working on a good definition for testing that objective.

Data collection
The feedback forms will collect a variety of data for later analysis, including: (all items are phase 1.0 unless otherwise noted)
 * Article title
 * User name (if logged in)
 * User IP address
 * Original post date/time stamp
 * Modified post date/time stamp - phase 2
 * Feedback form version last used
 * Yes/No answer (if using option 1)
 * Overall rating (if using option 3 -- or average if using current form)
 * Detailed ratings (if using expanded form) - phase 2
 * Comment (in their entirety)
 * Number of words in comment - phase 1.5
 * Feedback type (suggestion, question, problem or praise, if using option 2)
 * Email address (if provided in email call to action) - phase 1.5
 * Edit status (attempted or completed, indicating if user edited the page using option 4 or call to action)
 * User status (visitor, anonymous, registered, editor or admin at the time of first post)

This section has been expanded into a separate Data and Metrics requirements page.