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.
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
This could easily be done, and should be. I'll try to find some time to explore this.
The layout of a feedback comment seems a little crowded and noisy, some ideas to improve this:
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
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:
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"?
This post was posted by Trevor Parscal (WMF), but signed as Trevor Parscal.
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.
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).
We actually decided against this because we feel that it would violate the spirit of the privacy policy.
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,
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 not sure, but it is probably a matter of the time when the leaderboard turns over.
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.
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.
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)
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?
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.
