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 and 1.5 of this project (Oct.-Dec. 2011). Other features for phase 2 (Jan.-Mar. 2012) are only referred to here in outline form.

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

Overview
Key features for phases 1.0 and 1.5 of 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 - Did you find what you were looking for? Add a comment
 * Option 2: Make a suggestion Suggest an improvement, ask a question, report a problem or give praise to the editors
 * Option 3: Review this page - Rate this article. Add a comment or suggestion for improvement.

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. In phase 1.5, we will also test different placement options (described below), well as these additional options:
 * Option 4: Edit this page - Help improve Wikipedia (call to action, for comparison purposes)
 * No feedback form (option 0)

For more info about our a/b test plans, read the data and metrics page for this project. We plan to develop more features in a second phase (Jan.-March 2012), based on first phase results. We are starting a wish-list of features for that second phase and will link it here shortly (for now, we have outlined key phase 2 features and labeled them as such below). For a preview of what these forms and pages might look like, read below, or, which include simple wireframes for key touchpoints, as well a project plan and other useful exhibits.

Phases
Here's how we plan to develop AFTv5 features in phases 1.0 and 1.5: 1. Phase 1.0 Features 2. Phase 1.5 Features 
 * 3 feedback forms:
 * option 1 - did you find what you were looking for?
 * option 2 - suggestion / question / problem / praise
 * option 3 - review this article
 * basic feedback page (only accessible if you know the URL tag)
 * basic listing of full posts (most recent comments by default)
 * basic filtering (all, comments-only, flagged only, hidden-only, by option)
 * basic sorting (by date / by rating)
 * flag for abuse
 * hide/show this post (admins only)
 * edit call to action
 * 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 links to feedback page
 * add overlay capability
 * add minor copy tweaks
 * 3 placement options for feedback link:
 * option A - article section bar
 * option B - article title bar
 * option C - vertical button at right of page
 * expanded feedback page: same as above, plus:
 * better layout, with expandable comments and pagination
 * overall ratings (and % who found what they were looking for)
 * votes (was this post helpful?)
 * more filters (show by user group)
 * more sorting (by votes)
 * survey call to action
 * simple survey form (like AFT v4)
 * email capture form
 * data collection of stage 2 metrics (stage 3 after Xmas)
 * larger set of articles

Technical (non-functional) 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.



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



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.
 * For logged in users, feedback is posted under their user account (the IP address shall still be recorded).
 * For anonymous or logged out users, feedback is posted under their IP address.
 * Anyone can view the feedback page
 * Anyone can vote up or down any post on the feedback page (yes/no)
 * Administrators and editors only can access admin tools on the feedback page (hide, feature, etc.)
 * Users who have been permanently blocked from editing on Wikipedia may also be prevented from posting feedback (exact policy TBD)



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



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 Placement 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)

Overall Visual Design
 * 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.

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


(The picture above is a mockup - see also earlier and  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 (as shown in this wireframe)
 * 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).

Font Sizes: We will aim to use the following font sizes, with this proposed hierarchy across all forms:
 * 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]')

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



Option 2


(The picture above is a first mockup with preliminary icons - see also .)

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 and privacy policy
 * 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, Question, Problem or Praise.
 * 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 do you like most? 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


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.5 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 the 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)

Multiple posts / Editing your feedback
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?). 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.



Calls to Action
After readers post their feedback, they will see one of these calls to action (CTA):
 * 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.5, 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)

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 ). 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.5.

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 the 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 >>

http://en.wikipedia.org/wiki/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.

Take a Survey


New image will be added later (thumbnail of current version is provided here for reference).

This call to action will be postponed for a week to phase 1.5, so we can focus on the first call to edit in our first tests.

We will start with the current version of this CTA from AFT v4, with some changes to the wording of the survey, to reflect some of your new project goals and user interface.

Sign up or login
We will start with the current version of this CTA from AFT v4, with some minor changes to the wording.

Image to be added later on. This call to action will be postponed for a week to phase 1.5, so we can focus on the first call to edit in our first tests.

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.)

Image to be added later on. This call to action will be postponed for a week to phase 1.5, so we can focus on the first call to edit in our first tests.

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


 * discuss this article
 * view feedback page
 * learn how to edit

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



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 >>"

Placement


To increase feedback rates, we are discussing adding a 'Feedback' link higher up on the page in phase 1.5 (see thumbnail to the right). This is in addition to displaying the feedback form below the article. For a quick demo, check this first interactive prototype.

Feedback links on article pages
Here are some of the options we are considering for a feedback link higher up on the article pages:
 * Option A: add feedback link in the section bars (next to edit link)
 * Option B: add feedback link in the article title bar (top right corner of page)
 * Option C: add vertical button in the right margin of the browser window

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.

Overlay form
When users click on that feedback link, we would ideally like to display the feedback form as an overlay next to the link (as shown in the mockups -- see thumbnails to the right). If this proves difficult, a fall-back option is to simply include a jump link to the feedback form at the bottom of the page.



Feedback page


The Feedback page will display a list of the feedback posts for an article, as shown in the first mockup above (which doesn't show administration tools - see separate mockup in next section -- and )

The feedback page will be a stand-alone page, much like the Moodbar Dashboard (and we 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. The top tab of that page will say 'Feedback page' -- instead of 'Special page', if feasible.

Anyone will be able to view this feedback page, as well as filter or sort its posts, and vote on whether or not they are helpful. Editors and administrators only will also be able to use the administrative tools on this feedback page, enabling them to hide or feature some of the posts (see next section).

The actual nature of the comments 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.

The feedback page can be accessed in two primary ways: by clicking on the text links in the feedback forms, or on a link to be added on the talk page (it appears that this can be implemented via gadgets or hooks, and may not require Mediawiki core code changes are required for this requirement).

The feedback page will support navigation functionality, to filter or sort the list of feedback posts:
 * Filtering ('Show: ...') - predefined set of options:
 * All - unfiltered - phase 1.0
 * Comments only (this will be the default listing at launch, in phase 1.0)
 * Most Relevant (this would be default listing in phase 2 - show Featured first, then Top Rated with comments, then Most Recent with comments)
 * - - - - Filter by Form  - - - -
 * Option 1 form feedback only - phase 1.0
 * Option 2 form feedback only - phase 1.0
 * Option 3 form feedback only - phase 1.0
 * - - - Filter by User Group   - - - -
 * Feedback by Editors/Admins only - phase 1.5
 * Feedback by Registered Members - phase 1.5
 * Feedback by Anonymous Users - phase 1.5
 * - - - Filter by Response   - - - -
 * Feedback flagged for abuse - phase 1.0
 * Feedback hidden by administrators - phase 1.0
 * Feedback featured by administrators - phase 1.5
 * Feedback posted on Talk page - phase 2
 * Feedback that has been addressed - phase 2


 * Sorting ('Sort by: ...') - predefined set of options:
 * - - - Sort by Date   - - - -
 * Newest - phase 1.0 - show the most recent posts first (default)
 * Oldest Date - phase 1.0 - show the earliest posts first
 * - - - Sort by Article Rating   - - - -
 * Highest Rating - phase 1.0 - show the posts with the highest ratings first
 * Lowest Rating - phase 1.0 - show with the lowest ratings first
 * (combine Yes/No from option 1 with rating from option 3) - phase 1.0
 * - - - Sort by Feedback Vote   - - - -
 * Most Yes Votes - phase 1.5 - show the posts with the most 'Yes' votes first
 * Most No Votes - phase 1.5 - show the posts with the most 'No' votes first
 * (based on Yes/No votes for whether or not this post was helpful) - phase 1.5

The list 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.) A "Show more" button at the end of the list will load additional posts, same amount, and, again, display the "show more" button at the end of the list.

Each item in the feedback page list will display:
 * Logged user name (or IP address), with link to user page - phase 1.0
 * 'Yes/No' answer: 'found what they were looking for' -- or overall article rating from option 3 - phase 1.0
 * Timestamp (show 'x days, hours, minutes ago' -- all the way up to 48 hours, then just show date and time) - phase 1.0
 * Full Comment - phase 1.0
 * Truncated Comment - phase 1.5 (show first 500 characters, then users have to click 'More' to see the rest)
 * 'More' button showing expandable sub-section with feedback details (collapsed by default), including:
 * Form Option(s) Used - phase 1.0
 * Expanded Comment (if applicable) - phase 1.5
 * Permalink to that particular post - phase 1.5
 * Vote on this feedback post
 * 'Is this feedback helpful?' with 'Yes/No' buttons - phase 1.5
 * Number of up and down votes - phase 1.5
 * Link that shows names of voters (with their +1/-1 vote) - phase 1.5
 * Abuse Flags: (for any user to flag spam or offensive comments)
 * Flag as abuse - a text link - phase 1.0
 * Number of flags (in parenthesis) - phase 1.0
 * Link that shows names of flaggers - phase 1.5
 * Help icon - a question mark icon linking to help page explaining how to flag - phase 1.0
 * Diff link (e.g.: '152 edits since this post' - phase 1.0
 * (links to a comparison page showing the difference between the article at the time the feedback was posted and its current version.)
 * Administration tools in right margin (see below) - only visible to editors or administrators. (see next section)

In phase 2, this page's functionality will 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.

Pagination will be included at the bottom of each page by phase 1.5, as shown in the mockup above (instead of a 'Show More' button, which may not be as practical for this purpose).

Admin. Tools


This administrator version of the Feedback page includes admin./moderation tools, which would only be visible to editors and administrators. (see )

These moderation tools would include these features for each post:
 * A label to show if this article has been HIDDEN by any editor or administrator - phase 1.0 (or FEATURED - phase 1.5)
 * Hide - mark the post as hidden. - phase 1.0
 * (functionally, the comment is not deleted from the database, just not displayed unless you are an editor or unless a specific filter is selected; a 'Hidden' label is then shown next to post for editors.)
 * Show (for changing the status of 'featured' or 'hidden posts' back to normal 'listed' status) - phase 1.0
 * Feature - in phase 1 of the project this will promote the post to top of page, as well as include a 'Featured' label next to post. - phase 1.5


 * Check-box to indicate important items that have been posted manually to talk page ([ ] 'Posted to talk page') - phase 1.5
 * Check-box to indicate items that have been resolved (e.g.: '[  ]  Issue has been solved.') - phase 1.5
 * 'Email this user' - text link that opens your email application with that user's email filled in (only show this if an email address is available for that purpose) - phase 1.5
 * Last modified by (showing last editor name and date) - - phase 1.5

Here is an older wireframe that shows together (only focus on tools in the right sidebar)

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').

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.