Talk:Feedback Dashboard/Phase 1
|Thread title||Replies||Last modified|
|Feature request: mention articles||2||01:40, 21 June 2012|
|Leaderboard/counter||0||01:36, 13 June 2012|
|feature request: Leader board/counter on user talk pages||3||22:21, 27 January 2012|
|"Hide feedback"||5||20:45, 15 November 2011|
|Suggestion||0||09:43, 11 November 2011|
|Feature Request - Wachtlist||0||21:54, 31 October 2011|
|Feature request: persistent filters||2||18:33, 31 October 2011|
|Assets||1||23:51, 18 September 2011|
|Feedback comment layout||1||21:08, 14 September 2011|
|Names of filters||1||19:21, 14 September 2011|
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).
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.
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?
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.
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.
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.
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.
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. ;)
This *should* be the default. In fact, the design document describes the filters as being persistent. I'll investigate.
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.
I have added cut, web-ready assets for the Feedback Dashboard. They are at the bottom of the page.
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
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.
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"?
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.