Talk:Feedback Dashboard/Phase 1

Names of filters

Shouldn't the filters be named "happiness", "sadness" and "confusion"? This at least would appear to be the more obvious direct set of nouns for each of the adjective used in the tool ("happy", "sad" and "confused"). Was there some reason for using "praise" and "issues"? Trevor Parscal 20:52, 13 September 2011 (UTC)

When we interviewed the Mozilla people about their experiences, they made this recommendation which I agree with. The mental space that a user is in when they give feedback and the mental space that a user is in when they receive feedback are different. To use the "strong" words (happy, sad) in the "feed view" could cause the feedback reader to take those emotions as being directed at them, which results in a negative experience. Further, the feedback reader is an observer; a more neutral tone is expected.

Tamping down the tone ("this is an issue" vs. "this is what people say sucks") is pretty much the goal there. I didn't see the Mozilla numbers about this but it was explained and made sense. Jorm (WMF) 19:21, 14 September 2011 (UTC)

Feedback comment layout

The layout of a feedback comment seems a little crowded and noisy, some ideas to improve this:

• Reduce the darkness and possibly size of the timestamp in the top right
• Left align the username, comment text and arrow for the response link
• Increase and make more consistent all the margins between all the elements
  • Especially adding some more space between the emoticon and the text elements on the right
• Reduce the text-size of the feedback comment text to be the normal content text size Trevor Parscal 22:15, 13 September 2011 (UTC)

Hrm. I agree that the "View Conversation" link should be brought in more - to align with the feedback text. The feedback text is "indented" from the top "signature" portion to indicate that it is a "child" of the signature.

I agree that more white space is better. Again, I avoided that (it's 5px instead of the 15 I originally wanted) based on not wanting to bikeshed on "waste of space". I probably shouldn't have done that.

As far as the text size of the feedback and the display of the timestamp, those choices are deliberate. The feed is meant to be scanned and not examined (at least until something jumps out that is important). It was a goal to make the following possible:

• Rapid scanning for keywords within a blocks of text (outside of keyword filtering), and
• Rapid scanning of the "novelty" of a feedback comment.

There might be something interesting that could be done with reducing intensity of these values the older a comment is (e.g., the older it is the less likely it will stand out) but I'm not sure that would support the overall goal of the feature. If anything, we'd want to tone down the "middle" set - the ones where users have likely logged off (and thus immediate response is less useful). Leaving intensity on the edges brings focus to comments that are fresh (can be immediately addressed) and comments that are stale (should get a response of some kind because hey, they've been ignored).

That said, intensity modification in this way is moot (for now) since there's no response mechanism in phase 1. But even then, I'm leery of adding a small level of complexity that may be confusing. Jorm (WMF) 21:08, 14 September 2011 (UTC)

Designs for non-JavaScript version

It may be helpful to show a design that has the non-javascript-enhanced version, with traditional paging controls and an apply filter button. These elements can of course be replaced with more dynamic behavior by JavaScript, but the tool could easily support use by non-JavaScript clients and utilize progressive enhancement. Trevor Parscal 22:18, 13 September 2011 (UTC)

This could easily be done, and should be. I'll try to find some time to explore this. Jorm (WMF) 21:09, 14 September 2011 (UTC)

Assets

I have added cut, web-ready assets for the Feedback Dashboard. They are at the bottom of the page. Jorm (WMF) 20:42, 18 September 2011 (UTC)

Not sure that's something that should be hosted on Wikimedia Commons. They're only needed for the developer implementing this. Perhaps store internally, in subversion or on MW.org ? Krinkle 21:40, 18 September 2011 (UTC)

Feature request: persistent filters

If I'm a person who wants come back to the dashboard again and again to see different kinds of feedback, it would be great (even in the read-only version) to have persistent filter settings. There are going to be people who want to show up to the dashboard every day and see only the happy people who had their day made better by Wikipedia. There are going to be even more people who show up to answer questions of confused folks. ;) Steven Walling (WMF) • talk 21:53, 27 October 2011 (UTC)

This *should* be the default. In fact, the design document describes the filters as being persistent. I'll investigate. Jorm (WMF) 23:10, 30 October 2011 (UTC)

After doing some responding to newbies over the weekend with it, I find that sometimes it remembers settings (including the set "username" field) sometimes and other times not. I'm not sure if it's related to whether I manually refresh the page or not, since I did that sometimes. Steven Walling (WMF) • talk 18:33, 31 October 2011 (UTC)

"Hide feedback"

I am confused about this one. As an admin, I can "hide" inappropriate feedback, and "unhide" it upon review. When I looked at the dashboard, I noted several "hidden" comments, but I could not tell why they were hidden. Were those ones hidden as some kind of test? I did not see offensive comments or usernames involved and, in fact, only one of them seemed to have a comment at all, most of them just had an emoticon. Might be necessary to have a comment field (either generally visible like log entries, or visible to other admins) simply so that the reason for hiding is quickly apparent. Risker 04:49, 28 October 2011 (UTC)

Brandon or Howie should really comment here, but my feeling is that the purpose of the show/hide feature is only to handle abusive comments. If admins are hiding comments that are merely blank or devoid of lots of content then that's not good. Since the tool is also supposed to be an aggregate measurement of the mood of newbies, not just a tool for substantial comments, it's okay if there are messages without a lot of meat to them. Steven Walling (WMF) • talk 18:18, 30 October 2011 (UTC)

Hrm. So, the design I made did not include such things as a "reason" for hiding the comment.

During the implementation, Andrew included this (possibly because he's, you know, crazy smart). However, he was asked to remove the feature because it felt like an extra degree of difficulty (I actually didn't see this version; I was on vacation, so I wasn't able to comment).

I'm thinking, based on your comments, that this may be useful and we should probably re-investigate the issue at hand. I'll talk with Howie on Monday about it. Jorm (WMF) 23:09, 30 October 2011 (UTC)

I feel like the reason entry is what admins are used to seeing. It makes me a little uncomfortable to hide comments without providing a reason that is logged. Steven Walling (WMF) • talk 18:30, 31 October 2011 (UTC)

Most if not all log actions have a log reason. MediaWiki almost presumes there always is a log reason (much like the edit summary). It's not required to be non-empty but support for it is throughout the core framework. Adding it should be simple and is probably the reason Andrew included it originally, to match other log actions in MediaWiki.

Especially when hiding things, being able to provide a reason is useful. Krinkle 18:36, 31 October 2011 (UTC)

As another follow up on this... it may be appropriate to have a "flag this feedback" button for non-sysops where the hide button would be, along with a filter for flagged feedback if you're a sysop. Steven Walling (WMF) • talk 20:45, 15 November 2011 (UTC)

Feature Request - Wachtlist

Can a way to watch list the dashboard be developed, either actual watchlisting, or through a script/gadget like the category watch script on en.wikipedia? Monty845 21:54, 31 October 2011 (UTC)

Suggestion

Sorry if I have posted a message at the wrong place, but I suggest the feature include comments in edit summaries as well. Cheers. Sp33dyphil 09:43, 11 November 2011 (UTC)

feature request: Leader board/counter on user talk pages

Would it be possible to allow adding of leaderboard on user talk pages, or simply a counter of responses made by that user? I think the later would be more helpful, especially if the user is not on the leaderboard. Garemoko 08:46, 21 January 2012 (UTC)

That is a great idea. Steven Walling (WMF) • talk 21:36, 25 January 2012 (UTC)

Thanks for saying so!

On a similar topic, I notice that I had about 108 responses on the leader-board earlier today and this has now dropped to 68. Is that meant to happen? Garemoko 21:54, 27 January 2012 (UTC)

I am not sure, but it is probably a matter of the time when the leaderboard turns over. Steven Walling (WMF) • talk 22:21, 27 January 2012 (UTC)

Leaderboard/counter

When does the leader board/counter reset? I have already noted that it keeps a users name on the leader board if the user responds everyday. Please leave a message on my talk page to alert me if you comment.

Thanks, Riley Huntley (talk) 01:36, 13 June 2012 (UTC)

Feature request: mention articles

http://i.imgur.com/X2vsW.jpg

At the top you'll see the current situation, under the red line you'll see what the featurerequest would look like.

Some of the feedback is highly context sensitive, so it would be nice to be able to see in a glance which article they are talking about. People frequently give feedback on articles they didn't edit (in some cases they tried to and failed, but most never tried). Arcandam (talk) 01:19, 21 June 2012 (UTC)

We actually decided against this because we feel that it would violate the spirit of the privacy policy. Jorm (WMF) (talk) 01:32, 21 June 2012 (UTC)

Ok, thanks. Arcandam (talk) 01:40, 21 June 2012 (UTC)