Feedback Dashboard/Phase 1

'''This document is a work in progress. Comments are appreciated but this is not a final draft.'''



This document describes the design and behavior of the dashboard associated with MoodBar, a feature designed to enable new users to quickly provide feedback to the various Wikimedia Foundation project communities and to provide a view to that feedback for the community members themselves.

The Feedback dashboard is designed to enable experienced members of the greater Wikimedia project community to easily view issues, confusions, and praise sent by newer users and provide a simple mechanism to make responding to these issues easy and intuitive.

Note: This design has been modified and its phase numbers have changed. The numbers on the image filenames do not (currently) correspond to the correct phases. However, the image descriptions do.

The document is primarily written with Phase 1 in mind. Changes for Phase 2 have been pulled out into their own section.

The primary distinction between the two development phases is the inclusion of in-line, in-tool responses. The development of this feature has been divided into phases so as to better silo the work required (e.g., it is far simpler to implement display only when one does not have to also worry about interactivity).

Hypothesis
Having a quick and easy way for experienced editors to provide answers to feedback (of all kinds) in a structured and modern manner will promote new editor retention.

Use Case

 * Expert: User would like to see what issues new editors are having and provide aid, explanation, or encouragement to new editors.

Note: the goal of this tool is to surface community issues first and technical issues second. This feature is not designed to be used as a bug reporting mechanism.

Feature Requirements (Phase One)
Required
 * Provide a "dashboard" to allow community members to easily read and understand feedback.
 * This dashboard should provide a running feed of feedback comments
 * This dashboard should provide various filtering and searching mechanisms
 * Ability for Admins to remove comments (e.g., inappropriate comments such as personal information that need to be removed)
 * Admin view:
 * Admins will be able to remove comment from dashboard. Removed comments are not deleted, just suppressed from view for non-admins.
 * Admins will be able to restore removed comments
 * Non-Admin View:
 * Non-Admins will not be able to view removed comments

Feature Requirements (Phase Two)
Required
 * Extend the functionality of the feedback dashboard.
 * This dashboard should provide a mechanism for experienced editors to easily respond to issues.
 * This dashboard should support accepting responses to feedback comments.
 * Feedback comments should be subject to oversight (to prevent publication of phone numbers, real names, etc.)
 * There must be notifications to all involved parties in comment discussion that new responses have been made.

Stretch
 * This dashboard should provide the ability to view high-level rollups of the data over time

(Stretch goals will comprise version 3 of this tool, should they not be met with version 2.)

User Experience (Dashboard)
An experienced editor will navigate to "Special:FeedbackDashboard" or similar url. At this point they will be given a screen with two main elements:


 * A Filter Box
 * A Feed of Comments

For the purpose of this document, a single "Feedback Entry" shall be considered a comment, regardless of its type (praise, confusion, sadness).

Filters
The filters box will affect the comments which are displayed in the feed. By default, all comments of all types are displayed.


 * By Comment Type (Praise, Issue, Confusion)
 * By Keyword
 * By Username (of submitter)
 * Only show unanswered comments

Ideally, the system will remember which filters have been set in the future (via cookies) so as to reduce user frustration.

In the future, additional filters could be added:


 * Project
 * Language
 * Namespace
 * Article Name
 * Time Range
 * Keyword

Feed Behavior
Comments will be stacked in chronological order according to whatever filters have been activated. Upon initial load, only the 20 most recent comments will be loaded. The comment feed will have a "More" link at the bottom of the page that will load the next 20 entries in the stack via AJAX call (to the bottom of the stack).

For phase one, it is not required that the comment feed automatically update or indicate that new comments have been added. If this can be accomplished during the sprint, however, it would be desirable to indicate to the user that new comments have arrived (via a banner at the top of the feed). This banner should "flash" an orange color to draw attention to it when it first appears and then whenever it is updated again.

Comment Elements
Each comment, as displayed, will have the following elements:


 * The Type of comment (happy, sad, confused)
 * The UserName of the comment submitter
 * The Comment Text, if available
 * How Long Ago the comment was submitted (while we store timestamps, converting this number into a format like "X minutes ago" will be more useful to users)
 * A Link to this, showing the permanent link to the specific comment and conversation.

No Javascript Behavior
If the user's browser does not have Javascript enabled, a set of pagination controls will appear instead of a "More" link at the bottom of the screen. The controls will show as being disabled if there are no additional comments in either direction.

Permanent Links and Views
There will be multiple ways to view the comment feed:


 * Full feed - as is, with no filters
 * Full feed with Filters - applying one or more filters from the side
 * Single Conversation View - only one conversation, with a permanent link (Special:FeedbackDashboard/item/4679234235535). Filters are disabled here.
 * My Feedback - a personalized view of all the feedback a user has given (filterable - this is effectively the "by username" filter) (Special:FeedbackDashboard/UserName/)

Administrative Behaviors
Since comments may require oversight (e.g., to hide ill-advised personal data, or attacks), users with administrative rights will have the ability to hide selected comments from view, view existing hidden comments, and restore hidden comments to full view.

To the left of the permanent link will be a new option, "hide this comment". Clicking on this will hide the comment from view of all non-administrators and be shown marked as "hidden" to those with administrative powers.


 * Non-Administrators: The comment is not visible and does not appear in the timeline, ever.
 * Administrators: The username is replaced with "User hidden". The comment text is replaced with "(Comment hidden by administrative action)".  The emoticon will not be displayed. The permanent link section will be replaced with a single link, "view this comment".

If the administrator clicks "view this comment", the comment will be displayed (only to them), with the following changes:
 * A red "this comment has been hidden" notifier will appear.
 * A "restore visibility" link will appear.

If the admin clicks "restore visibility", the comment will be restored to full visibility in the timeline.

WikiLove Links
Signatures and other elements in this design include a WikiLove link (alongside the standard "talk|contribs" links). It is intended that clicking on this link will open the WikiLove dialog directly within the page and that submitting WikiLove from the Feedback Dashboard will automatically submit to the user in question without leaving the Dashboard.


 * This will require development in WikiLove to accomodate this feature.

Phase 2 Changes
This section discusses changes that will occur during Phase 2 of the feature's implementation.

Comment Elements
A new element will be added to individual comments:


 * A View Conversation or Respond to this Control

Viewing Conversations
Multiple responses to a comment are allowed. The initial user who provided the comment may be encouraged to reply. Other users may be allowed to add their own responses.

If a comment has been responded to by anyone, a "View Conversation" link will be present.

Clicking on the "View Conversation" link will cause all responses to be displayed inline, below the original comment. Responses are stacked in chronological order, oldest at the top. Conversations are not threaded.

The response is standard wikitext.

At the bottom of the conversation is an additional "respond to this" section. Responding here will add to the existing conversation (see below for behavior).

Clicking the "View Conversation" link again will close the response display. The responder notification will then move back to its original position.

Each response will be formatted with the following:
 * User Name - a signature of the person who left the response
 * Timestamp - when the response was left.
 * Edit - a link to allow editing of the response. When this is selected, the response is not opened in a full-blown editor.  Instead, the abbreviated editor is inserted in-location with the existing comment text already included.
 * Delete (Admin Only) - The ability to delete a response. This link appears next to the "Edit" link.

Respond to this
If a comment has not recieved a response, a "Respond to this" link will appear beneath the comment itself.

Clicking on this link will open and expand a small editor pane below the comment. This will be a simplified editor (e.g., no edit toolbar). All wikitext will be allowed. If a signature is included, it will be stripped out automatically (the tool itself will provide the signature for the responding user).

Responses will have a maximum size of 5,000 characters. There will be a character counter that shows the user how much text they have remaining. The

Once the user has provided text into the textarea, the "Send Response" button will become active (move from disabled to active state).

If the user exceeds the character count, the counter will turn red and bold, indicating that the user has exceeded character allotment, and the "Send Response" button will become disabled (until such time as the response has been trimmed).

When the response is finished, and the user clicks the "Send Response" button, the system will (via AJAX) post the response to the commenting user's talk page. This comment will also have the user's signature applied as well as a small template indicating that the response is due to their MoodBar submission.

Ideally, an email will be sent (if the user has registered and confirmed their e-mail address) to the user with a slightly different format than what is normally given when a talk page is modified. Something friendly and user-readable, along the lines of:


 * JohnDoe has responded to your feedback about editing! The text of their response is as follows:
 * "Sed posuere consectetur est at lobortis. Aenean eu leo quam. Pellentesque ornare sem lacinia quam venenatis vestibulum."
 * You can continue the conversation on your "talk" page here.

Responses may only be sent by registered users. Anonymous users will not be shown the "Respond to this" link (they will, however, be able to view existing responses).

Error Behavior
If the server indicates that an error has occured, a simple "there has been an error, please try again later" message will be shown.

Data Model Modification
The primary data model of MoodBar remains, however, support must be enhanced for the following elements:


 * Response Date - the date a response was sent
 * Responder ID - the user id/name of the person who has sent the response
 * Response Text - a 5,000 character maximum text field that contains the response itself

This data can (and probably should) be kept in a secondary table.

Future Thinking
It would be nice if the receiving user were able to mark responses as being "helpful" or "insufficient."