Last modified: 2014-09-26 17:38:27 UTC
Thanking a user is too hard, and requires a confirmation step. This is unlike any site where similar functionality exists. Recommendation : hold thank action in a queue for 30 seconds (60?) in which the thanker can click "thanked" to unthank with no notification sent to the target of the thanks. After the queue expires, the user can unthank but no action will occur other than "Thanked" changing back to "Thank"
Introduced in https://gerrit.wikimedia.org/r/#/c/67591/
(In reply to comment #1) > Introduced in https://gerrit.wikimedia.org/r/#/c/67591/ Thanks for the link, I'm aware of the reason why the current flow is in place.
(In reply to comment #0) > Thanking a user is too hard, and requires a confirmation step. This is unlike > any site where similar functionality exists. I am not aware of any such sites, personally. Care to provide examples? > Recommendation : hold thank action in a queue for 30 seconds (60?) > in which the thanker can click "thanked" to unthank with no > notification sent to the target of the thanks. After the queue > expires, the user can unthank but no action will occur other than > "Thanked" changing back to "Thank" Sounds unintuitive. The current workflow appears to be a good compromise between easiness and avoiding accidental clicks. Maybe the interface could be made less intrusive, but that's a separate thing.
Bartosz, Facebook (like), Twitter (favorite), LinkedIn (like), Quora (thank) Pinterest (heart) Like I said, I've yet to see a site that requires a secondary step for an action where a user shows appreciation for other users' actions. Unintuitive? for all intents and purposes its a button, buttons usually have an on and off position and you usually press, click or tap them to toggle between two states, so one click thanks, a second click unthanks. Given the general tone of interactions on the site, and the severe decline in thanks after this change, this seems to me to be a serious and measurable regression. What is worse, accidental thanks being sent (to vandals or well intentioned users making errors) or the serious decline in positive user to user actions on site?
> Facebook (like), Twitter (favorite), LinkedIn (like), Quora (thank) > Pinterest (heart) I only use Facebook and LinkedIn out of these, so I'll base my reply on them. I was also not aware of any "like" functionality of LinkedIn and I can't seem to find it now, so I'll only base my reply on Facebook. :) * The "thank" link is right next to "undo" and "rollback", so missclicks cause more issues than, say, clicking in the comment field instead of liking a post on Facebook. That's why the secondary step is needed, and why it was requested by the community (and why the request was actually fulfilled instead of being ignored, like such requests often are). * You certainly can unlike Facebook likes at any time, while you can't unthank anybody ever. This is also why I think that a solution where you suddenly can unthank, but only for a brief period of time, is unintuitive. Of course, this is possible to do (GMail does, or did, it, allowing user to "unsend" an e-mail for a few seconds), but it needs a clear indicator that something is happening right now and you can stop it (GMail used a button on a yellow bar near the top of the screen). * The thanks have been widely advertised for being unlike likes - in particular because of being private (invisible to other users) and carrying more value (to me it seems like thanking a person for something is more "personal" or "involved" than liking something they did). You are now implying that's not how it is. > Given the general tone of interactions on the site, and the severe > decline in thanks after this change, this seems to me to be a > serious and measurable regression. If there was such a decline (Where are the stats? Are they public?), then it's probably caused by people getting used to the feature and stopping playing with it. (Or possibly deciding that it's not something they actually want to use.) > What is worse, accidental thanks being sent (to vandals or well > intentioned users making errors) or the serious decline in positive > user to user actions on site? This is a false dichotomy and a rhetorical question, both of which should be avoided in a serious discussion. Thanks being sent for edits one actually intended to rollback are obviously an issue for both persons involved, especially if the author of reverted/thanked edit made it in good faith.
(I'm CC-ing people actively involved in the previous discussion.)
Meh... I expect to see a WONTFIX from this ticket because this discussion was just had not long ago. I've yet to have the time to finish my user-script I was working on that would allow users to customize thank the way they wanted (completely get rid of it or get rid of just the confirmation step). I've got a good chunk of the completely disable it code in a NoThanks.js script in my userspace and Ryan Kaldari provided me with a good starting point to get rid of the confirmation step. I just need to put all of the pieces together. Of course, if it was decided to allow this customization in the back-end php for the extension instead, I would not complain.
I don't have a problem with the current implementation, but IF this ended up happening I would rather see the "thanked" turn into a link reading "un-thank" or "thanked (undo)" rather than just sitting there. Who's going to know that clicking it again will undo the thanking? But like I said, it's not that difficult to click "thank" -> "OK".
(In reply to comment #8) > I don't have a problem with the current implementation, but IF this ended up > happening I would rather see the "thanked" turn into a link reading > "un-thank" or "thanked (undo)" rather than just sitting there. Who's going to > know that clicking it again will undo the thanking? But like I said, it's > that difficult to click "thank" -> "OK". I think it is a pain in the ass to click "thank", wait two minutes for the okay dialog to load on my Android, click ok, wait three minutes for the link to change to "thanked"... I'd be fine with a single click and a three minute wait. Thanks.
I agree with Jared's overall recommendations here. Now that we are almost caught up with serious bugs and deliverables for Notifications I recommend that we consider implementing a simple 'undo' function to replace the 'confirmation' step -- which seems too heavy-handed. By now, users should have adjusted to this feature, and a more lightweight 'undo' tool might be more effective, increasing overall traffic as a result. And this can be implemented in a way that addresses Technical 13's concerns here, so we don't have to wait 2 minutes for a link to change. Jared has some really good ideas on how to make this work, which I will let him explain. To provide more perspective on this topic, here is a recap of our community discussions about this feature right after launch: https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Recap After we first launched this feature, about 23% of users on this talk page reported that they miscklicked often on the thanks link -- requiring the use of a 'confirmation' or 'undo' tool. About 54% of respondents wanted a 'confirmation' dialog, whereas 46% wanted an 'undo' tool. Ideas for 'undo' tools included an 'unthank' link, as well as a countdown solution, described below the recap. Because our engineering resources were limited at the time, we implemented a simple 'confirmation' dialog in early June, because the 'undo' solutions would require some backend engineering we couldn't afford. This caused a decline of about 25% in the overall number of thanks notifications sent, which corresponded to the number of misclicks reported above. Overall, our community was comfortable with this choice, as described here: https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Thanks_confirmation_feature_added For more information, here are current usage patterns for the Thanks feature on our Notifications metrics dashboard: http://ee-dashboard.wmflabs.org/dashboards/enwiki-features Since the Thanks feature was released on the English Wikipedia on May 30, 2013, we've collected these metrics: Total notifications events since launch: 29.9k Daily notification events: 325 * Daily notification share: 2.2% * Daily notification views: 1.6k ** Daily notification clicks: 65 Clickthrough rate: 0.04% * daily numbers are based on Sep. 9 activity ** daily views are based on flyout impressions shared by other notifications
Created attachment 13293 [details] updated appearance of the thank tex Added visual design for update to thank interface. This could be implemented with or without the timer feature (e.g just the visual design)
(In reply to comment #11) > Created attachment 13293 [details] > updated appearance of the thank tex This looks very neat, but also very out of place on those history pages :/
(In reply to comment #0) > Thanking a user is too hard, and requires a confirmation step. This is unlike > any site where similar functionality exists. > > Recommendation : hold thank action in a queue for 30 seconds (60?) in which > the > thanker can click "thanked" to unthank with no notification sent to the > target > of the thanks. After the queue expires, the user can unthank but no action > will > occur other than "Thanked" changing back to "Thank" I think the confirmation step is probably fine, considering there's also a confirmation for undo. Jared is right that it's weird to require a confirmation on a thanks action like this, but the root cause here is that page histories are a cluttered mess with a poor visual hierarchy of actions. But we're not going to solve that right now. An incremental improvement here would be to make the confirmation not require a modal (e.g. do it inline via JS), or provide a quick un-send function inline. The jquery.ui modal that it being used now is a huge overkill.
(In reply to comment #13) > I think the confirmation step is probably fine, considering there's also a > confirmation for undo. Tweaking status to reflect that the request is unsettled so far.
Can we have a GSoC student code it as the attached design shows. Roll it out and get feedback on if we're still getting accidental clicks and track the number of undos were getting, and go from there. I know we have number from the original design and from with the modal to compare to. It would be nice to base the decision to have a confirmation step on data rather than conjecture.
This is my personal take on this bug. I haven't followed everything super-closely, but here's broadly what I see. (In reply to comment #15) > Can we have a GSoC student code it as the attached design shows. Reading comment 0, "it" seems to actually include multiple components, depending on how detail-oriented you are. One step is obviously removing the little dialog box. That part is trivial to implement immediately. But... (In reply to comment #0) > Recommendation : hold thank action in a queue for 30 seconds (60?) in which > the thanker can click "thanked" to unthank with no notification sent to the > target of the thanks. After the queue expires, the user can unthank but no > action will occur other than "Thanked" changing back to "Thank" Implementing this piece might be a blocker to doing any useful experiment, and coding this second part properly is not trivial. You need to add a reliable delay mechanism and implement the ability to de-queue and re-queue thanks reliably.
Perhaps we could make the "queuing" of the thank client side, and with a shorter time span, 5 seconds or so. Rather than making the issue more complex with the need of server side queues
(In reply to comment #17) > Perhaps we could make the "queuing" of the thank client side, and with a > shorter time span, 5 seconds or so. Rather than making the issue more complex > with the need of server side queues Couldn't a token just be stored in a cookie or session data that expires after 30 (I'd prefer 60) seconds so if they manage to navigate away from the page and back before it expires they can still undo?
Client-side queueing is unacceptable to me, both in the way Jared proposed (which would mean the user has to wait on the page!) and in the way Technical 13 proposed (it would be too easy for thanks to disappear, only to reappear a few days later when the user visits Wikipedia again, or never).
(In reply to comment #19) > Client-side queueing is unacceptable to me, both in the way Jared proposed > (which would mean the user has to wait on the page!) and in the way Technical > 13 proposed (it would be too easy for thanks to disappear, only to reappear a > few days later when the user visits Wikipedia again, or never). I think you misunderstood what I was saying. The user side would have a cookie containing a token to unthank which would include a timestamp 30/60 seconds in the future, if that had already passed, it would be expired and wouldn't be available (so there is no way it could show up after the agreed upon delay) and the server side would process the than after that 30/60 seconds unless it received the token to undo. I hope that is a better explanation of what I mean.
There are two aspects here: the UI workflow and the notification sent. At least Twitter and Facebook have a simple and binary workflow: * Twitter: Favorite --> Favorited --> Favorite --> Favorited... * Facebook: Like --> Unlike --> Like--> Unlike... Therefore I guess a simple solution that wouldn't surprise to any user would be * MediaWiki: thank --> thanked --> thank --> thanked... I personally agree that the extra dialog feels unnecessary. Then again About delayed notifications, they seem to be used by these services. I have no idea about their setup but usually a few seconds inenough for a user to realize that a click has been done by mistake. The worse that can happen is that another user gets a notification. Not a big deal? What is clear is that they don't send any notification if you have been "unfavorited" or "unliked". Whether this is a good candidate for a mentorship program or not will depend on the complexity of the feature (not too easy, not too difficult), community consensus and availability of 1-2 mentors.
I think MatmaRex's idea with https://gerrit.wikimedia.org/r/#/c/92315/ is a better idea, and is unobtrusive IMO. (In reply to comment #21) > About delayed notifications, they seem to be used by these services. I have > no > idea about their setup but usually a few seconds inenough for a user to > realize > that a click has been done by mistake. The worse that can happen is that > another user gets a notification. Not a big deal? I think the whole point is to have users not send accidental thanks.
@kunal, I think we have 2 main goals: 1. Make positive actions (like thanks) on the site easy and seamless (in this case seamless means fewer steps, preferably 1 2. Reduce the number of accidental thanks which can be frustrating to the thanker and confusing to the thankee
It seems to me that the problem of accidental thanks has far more to do with the UI of the history and diff pages than the process of how thanks works itself. In mobile, we've completely redone the diff interface and accidental thanks is no longer an issue so we removed the confirmation step there. Putting a lot of work into a band-aid solution doesn't really make sense to me. Personally, I would prefer that we leave thanks how it is for now and work on redesigning the history and diff pages so that people aren't clicking the wrong things.
Ryan, I think thats a good point, but priority-wise we might have community members that want to contribute to improving the thanking experience and we don't currently have updates to the history view as a priority at this exact moment. I want to make sure we have a solid idea and designs for community members who want to improve this in the interim.
Time to revisit this now that we're using jquery.confirmable for the confirmation step?
(In reply to Kunal Mehta (Legoktm) from comment #26) > Time to revisit this now that we're using jquery.confirmable for the > confirmation step? Agreed. It still takes multiple clicks, but the current bug does not clearly propose a solution. Let's close this in favor of considering a specific alternative. The best currently proposed is bug 69636, so I'm going to mark this as a duplicate of that discussion. *** This bug has been marked as a duplicate of bug 69636 ***
