Thanks tool: How much does the confirmation button cost us?
Open, LowestPublic

Description

This is related to bug 61737.

Can we find out how many thanks are not being completed on desktop? That is, the user clicks on a thank button, but does not click on the confirmation button.

Does the level of non-completion differ by user experience level (perhaps total number of edits, or perhaps total number of completed thanks)?

The ultimate question is whether the confirmation step is likely to be preventing misclicks/unwanted thanks, or if it is mostly stopping wanted thanks. If it stops very few wanted thanks, then it might make sense to duplicate this confirmation step on mobile.


Version: unspecified
Severity: normal
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61737
https://bugzilla.wikimedia.org/show_bug.cgi?id=71360

Details

Reference
bz69804
bzimport raised the priority of this task from to Needs Triage.
bzimport set Reference to bz69804.
bzimport added a subscriber: Unknown Object (MLST).
Ironholds triaged this task as Lowest priority.Dec 5 2014, 7:40 PM
Ironholds edited projects, added Research; removed Analytics-General-or-Unknown.
Ironholds set Security to None.
Krenair added a subscriber: Krenair.Dec 5 2014, 7:42 PM
Legoktm added a subscriber: Legoktm.

What is the restricted project that this is a part of?

Dumb user question: why is this a research question? Generally, it is standard UX practice to not require confirmation for non-destructive changes, and specifically, no social network I've ever seen requires confirmation for stars/likes/etc. It doesn't seem like it is a good use of research's time/energy to confirm pretty widely understood practice..

(Which is to say, of course, that there should clearly be a bug for "remove the confirmation step in giving thanks".)

Dumb user question: why is this a research question? Generally, it is standard UX practice to not require confirmation for non-destructive changes, and specifically, no social network I've ever seen requires confirmation for stars/likes/etc. It doesn't seem like it is a good use of research's time/energy to confirm pretty widely understood practice..

This has been discussed in the see also bugs. A major difference that has been noted that stars/likes have an undo option whereas thanks don't. And there's a bug for that somewhere.

Quiddity added a comment.EditedJan 9 2015, 8:23 PM

The confirmation for "Thank" was added because on history pages, it is directly next to the (rollback | undo) links, and was added to the end of that bracketed line (rollback | undo | thank) which led to embarrassing errors, of thanking a vandal. T49658: Thanks workflow needs further thought
As soon as we have a way to fix these accidents, we can remove the confirmation step - possibilities are discussed in T71636: Thanks: Implement an undo feature - e.g. a server-side time-delay before sending the "thank", enabling a user to click cancel (like gmail offers for sending an email - a 20 second window)

Unless there is a rationale for adding analytics beyond just "confirm what we already know", then I would suggest that any programming efforts would best be put towards creating the Thank-Undo code instead of this. I suggest closing this task as Declined.

We have a current problem with embarrassing thanks on mobile. (Steps to reproduce: Navigate to a page with a big green 'thanks' button. Drop your expensive mobile device. Try to catch it before it hits the floor and breaks. Do you have any idea what buttons your fingers might have touched when you caught it?).

Real users who have suffered real problems with this button on mobile were told that the confirmation step would not be implemented on mobile unless there was data proving that people actually misclicked this button. Thus we have a request to get this data. If the users could just have what they asked for, which is a simple confirmation step for a proven problem, then this request could be closed as needless.

Whatareyoudoing-WMF Umm... People have been asking for an undo feature since thanks came out. It wasn't until the WMF team said they didn't want to spend any more time on such a lightweight product that they decided we would have to live with a confirmation step instead. This is still unacceptable and makes thanks not worth the time to use. I do hope the WMF rethinks their position on this as right now it takes me less time to send a wikilove message than it does to thank for an edit. I have to use wikilove for everything else from thanking for blocking a sockpuppet and thanking for patrolling an edit of mine and thanking for protecting a page and thanking for deleting a page in my userspace, might as well use it to thank for edits too since there is no easier alternative....

Technical13, I don't see any problem with providing both, but they haven't actually provided the Undo feature. Since they haven't provided the Undo feature (which requires a lot of work), then the people who are having this problem have requested that they provide the already-existing-on-desktop confirmation step on mobile, too. Porting an existing detail to mobile should not require nearly as much work as writing a new feature for both mobile and desktop.

We have a current problem with embarrassing thanks on mobile. (Steps to reproduce: Navigate to a page with a big green 'thanks' button. Drop your expensive mobile device. Try to catch it before it hits the floor and breaks. Do you have any idea what buttons your fingers might have touched when you caught it?).

Real users who have suffered real problems with this button on mobile were told that the confirmation step would not be implemented on mobile unless there was data proving that people actually misclicked this button. Thus we have a request to get this data. If the users could just have what they asked for, which is a simple confirmation step for a proven problem, then this request could be closed as needless.

Oh, right, the mobile issue, T63737: Thank notification on mobile should support click to undo. Yes, I agreed there that the button is very large (currently not working per T77929), and I agree that a confirmation-step, or undo-step, or opt-out would be helpful. (Maybe a CSS class, so that PamD can hide the button, at the very least?)

I'm not sure how we'd get any kind of proof-via-analytics though, because it would require guessing (or psychic powers) to know why anyone cancelled a Thank, no?

Maybe, but this was the data request that they made. They said that they
won't fix the reported problem until they have "data" to show that it's an
actual problem.

Whatamidoing (WMF)/Sherry Snyder
Community Liaison
Wikimedia Foundation, Inc.

Then I'd suggest that the problem isn't going to be fixed: R&D is currently heavily oversubscribed with work. This is a low-priority request, at the moment, and won't be jumped on until that changes/someone runs out of things to do.

Amire80 added a subscriber: Amire80.

(Added the StructuredDiscussions project, because I expect Thanks to be pretty important in Flow.)

The confirmation is not shown/required for Flow thanks.

Correction, there is a confirmation for Flow on mobile, but that seems to be a byproduct of the module registration details (see T89565: In Flow on mobile web thanks should not require confirmation step, like on desktop).

Can we A/B test out a click to undo feature and see what impact it has? I think this would be a really useful reusable component to have. Do we have a task to update the API to do that?

Can we A/B test out a click to undo feature and see what impact it has? I think this would be a really useful reusable component to have. Do we have a task to update the API to do that?

I don't think anyone's really against click to undo if it's done properly. (Obviously, it only makes sense with delayed delivery, since it's somewhat meaningless to undo a notification once the recipient has already seen it)

It doesn't seem worth it to implement the API just to A/B test it. (The current task is not requesting that, just funnel data for the current confirmation feature on desktop). If we're going to implement the undo API, we should just do the undo feature for real and be done with it.

Related: https://gerrit.wikimedia.org/r/#/c/163289/

QChris removed a subscriber: QChris.Apr 1 2015, 10:39 AM

See T63737 - @Mattflaschen I'm happy to do the frontend legwork if someone can help me add support in the api to cancel a thanks. Is suspect all that needs to happen is when you thank you get an id with which you can use in an api request to cancel in the same session.

EBernhardson added a comment.EditedApr 1 2015, 4:41 PM

I started on the backend cancelability of events in https://gerrit.wikimedia.org/r/#/c/163289/ but never got around to finish it. It needs a trivial API endpoint written that accepts the cancel token and passes it into EchoEventCanceler. Not sure if this also needs some sort of security added ensuring the token belongs to the user making the API request. Also have to adjust Thanks to enable cancelability, and return the generated token from the thanks API request.

Removing Research & Data and moving to Research Ideas board.

ggellerman edited projects, added Research ideas; removed Research.Jun 4 2015, 8:10 PM
Restricted Application added a project: Growth-Team. · View Herald TranscriptJul 18 2018, 7:06 PM
SBisson moved this task from Inbox to Triaged but Future on the Growth-Team board.Jul 20 2018, 5:59 PM