Page MenuHomePhabricator

RFC: Proposed "unthank" feature to roll back "thanks"
Closed, DuplicatePublic

Assigned To
None
Authored By
awight
May 11 2021, 5:13 PM
Referenced Files
F34450586: image.png
May 11 2021, 5:13 PM
F34450589: image.png
May 11 2021, 5:13 PM
F34450581: image.png
May 11 2021, 5:13 PM
F34450583: image.png
May 11 2021, 5:13 PM
F34450597: image.png
May 11 2021, 5:13 PM
F34450579: image.png
May 11 2021, 5:13 PM

Description

Background

The Thanks extension provides something similar to a "like" button for revisions, called "thanks". Since the feature was first introduced, the lack of a corresponding "unthank" has caused concern, and eventually resulted in a two-click confirmation workflow to thank another user.

Desktop
On revision page:

image.png (97×540 px, 16 KB)

In history view:
image.png (326×612 px, 96 KB)

Confirmation step:
image.png (32×333 px, 4 KB)

After thanking:
image.png (27×139 px, 2 KB)

Mobile

image.png (488×439 px, 43 KB)

This issue was first discussed in 2013, on T49658: Thanks workflow needs further thought and on-wiki, where different implementations were considered including an "unthank" action. I'd like to re-open this question, hopefully with the advantage of hindsight.

Hypotheses

The Thanks feature might be more widely used if the interaction were simplified to only require one click.

Proposal

Interface

  • No confirmation step to thank.
  • Turn the gray "thanked" text into a link, which when clicked runs the existing confirmation workflow but in reverse. On desktop an inline question can be presented such as,
    image.png (29×343 px, 5 KB)

Configuration

  • No configuration, this feature should be designed so that it's safe to enable everywhere.

Logging

  • Both thanking and revokation are logged permanently.

Grace interval

  • As with the thanking feature, we can give the user c. 2 seconds to change their mind.

Notifications

  • Don't notify when revoking thanks. This is not actionable and can be easily misinterpreted.
  • Notify at most once per revision. If a user thanks, unthanks, and re-thanks on the same revision, don't send a second notification.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
mewoph subscribed.

Hi @awight, thanks for filing this! I'm moving this task for our team to discuss.

This seems to me like a lot of work to take on based on a very ad-hoc hypothesis.

(Some apps, such as Gmail IIRC, provide an undo by faking the action on the client side but only actually performing it once the undo period has passed. But even that seems fairly complex to do.)

MMiller_WMF subscribed.

@awight -- thank you for filing this. We talked about it on the team today, and we agreed that it is good practice to allow users to undo any sort of action. But we're not going to be able to prioritize this work on the Growth team, because of the other plans and priorities we have. I actually think this would be a good candidate for Community Wishlist, if you want to propose it the next time around.

Thanks for looking at it! To be clear, my personal motivation is to enable a 1-click "thank" workflow, on the hypothesis that it will increase interaction. "unthank" is not so interesting to me, merely a means to simplify the interface.

If you agree, I would like to add some metrics to the "thank" workflow to check whether users abandon before the second click. It's not perfect, but a drop-off there would demonstrate whether there's a problem.