Page MenuHomePhabricator

Growth design: finalize designs for thanks confirmation UX
Open, Needs TriagePublic

Assigned To
None
Authored By
KStoller-WMF
Mar 24 2023, 5:58 PM
Referenced Files
F36455909: image.png
Mar 24 2023, 5:58 PM
F36922847: Current Thanks behaviour-sml.webm
Mar 24 2023, 5:58 PM
F35483686: image.png
Mar 24 2023, 5:58 PM
F35483684: image.png
Mar 24 2023, 5:58 PM
F35483682: image.png
Mar 24 2023, 5:58 PM

Description

User story:

As an editor unfamiliar with Thanks, I want sending Thanks to be easy and follow modern UX standards, because the current confirmation message is easy to miss and the message is easy to misinterpret.

As an editor, I want a way to confirm or cancel sending Thanks, because sometimes I accidentally click Thanks (In other words, there should either be a confirmation step or a temporary window to cancel sending thanks. )

Prior work:

In T315859: Growth design: improve thanks confirmation UX we explored initial ideas. Before we implement any changes we should conduct a community consultation and then finalize designs.


Background:

The thanks link confirmation UX is subtle and the language is confusing:

Mobilebefore click
image.png (380×978 px, 151 KB)
after click
image.png (380×978 px, 157 KB)
after confirming click
image.png (380×978 px, 149 KB)
Desktop

Some people never confirm because they think they already sent "private" thanks or because they simply miss the confirmation message that appears inline.

Maybe we could borrow the UX from Minerva/MobileFrontend, where tapping thank gives you the opportunity cancel within a few seconds.

If not that, maybe there's something we could do to adjust the weight, or to present a dialog to the user asking them to confirm, rather than the inline, quite subtle text that is the same weight/color.

  • Meet with Rita and Kirsten to review and refine
  • Share with Design teams at review to iterate
  • Get feedback from Growth CRS and Ambassadors, as appropriate (who can help share ideas for community feedback)
  • Share with Growth team in design "deep dive"
Further details:

There are several other tasks that relate to this request:

Some other relevant feedback from T229168:

This request was prompted by this discussion at enwp, in which the OP said:

It wasn't clear to me whether my thanks had been sent already and if it was asking me if I wanted to publicly thank the editor on top of that, or if publicly thanking was the only way to go.

Which is precisely the same concern/confusion that the OP of T159302, which resulted in changing the confirmation message from "Send public thanks?" to "Publicly send thanks?", had:

The message "Send public thanks for this edit?" is confusing. People have been known to misinterpret it it as giving the user a choice of "Send public thanks" vs. "Send private thanks". Actually the choice is "Send public thanks" vs. "Don't send thanks".

So the rephrasing has hardly helped.

The word "public(ly)" has been nothing but a source of confusion. I understand it was added out of concern for the feature being construed as something private (T90486), but it's steered people too far in the other direction. Pdebee said in the aforementioned thread:

A few years ago, a new joiner wanted to thank me for my initial help with her first steps as an editor, but changed her mind because she thought that “publicly” meant that tens of millions of other registered editors were going to see what she’d hoped would be a simple, private signal of personal appreciation.

...when in fact only who thanked whom when, not even for which edit or on which page, is visible—and only on Special:Log, not on any diff or history page or anyone's watchlist.

Current Design Explorations:

Personalized praise Figma designs

Dialog:

image.png (754×1 px, 111 KB)

Acceptance Criteria:
  • Design: Create one or more design prototypes showing how we can improve the Thanks confirmation UX.
  • CRS and Product: community consultation
  • Design iteration based on community feedback
  • Finalize designs

Event Timeline

See also T357669: jquery.confirmable is not accessible
I think it should be included into the scope of this task. Though I kind of disagree with its findings given that the benefit of the current interface is that it doesn’t block anything, and the proposed design does.