Thanks workflow needs further thought
Closed, ResolvedPublic

Description

The workflow of the Thanks extension (https://www.mediawiki.org/wiki/Extension:Thanks) needs further thought.

Currently we have an irreversible action link without any user confirmation. This is bad.

The "thanks" link sits next to an "undo" link. A user could easily accidentally press the "thanks" link and then try the "undo" link as a means of un-thanking a user. (Many user interfaces provide an "undo" link after a user submits an action.)

One possible solution to the first issue might be requiring a two-click process. So the link would read "thanks" initially. After the first click, it might switch to "are you sure you want to thank this user for this edit?" (or something less verbose!). After the second click, it would submit the thanks.

The juxtaposition of the "thanks" link and the "undo" link... well, I'm not sure how to solve that.

I'll upload screenshots of the current workflow momentarily.


Version: unspecified
Severity: normal
See Also:
T49782: Rollback workflow needs further thought
T55879: Thanking a user for an edit takes multiple clicks
T63737: Thank notification on mobile should support click to undo
T73360: Instrument click through tracking on Thank, and confirm steps

Details

Reference
bz47658
bzimport raised the priority of this task from to High.
bzimport set Reference to bz47658.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 12180
Screenshot of mediawiki.org Thanks extension link in the page history, pre-thanks

Attached:

Created attachment 12181
Screenshot of mediawiki.org Thanks extension link in the page history, post-thanks

Attached:

Requiring 2 clicks for a non-destructive action (thanking), but only 1 for a destructive action (rollback) seems strange. Personally, I don't think we need to complicate it with a confirmation or unthanking interface, but that's just my opinion (and I tend to have a "less interface is better interface" philosophy). In the meantime would be good to get more opinions on this. Feel free to invite other Wikipedians to comment on the bug and I'll run it by the designers as well.

(In reply to comment #3)

Requiring 2 clicks for a non-destructive action (thanking), but only 1 for a
destructive action (rollback) seems strange.

Rollback is reversible and tracked (in Special:Contributions, Special:Watchlist, Special:RecentChanges). Rollback is also intentionally not exposed to users until they opt in to it (via an additional user group).

And, for what's worth, I hide rollback links everywhere because I never use them and when they were exposed, I would accidentally click them. This is particularly problematic on touch screen devices.

And, for what's worth, I hide rollback links everywhere because I never use
them and when they were exposed, I would accidentally click them. This is
particularly problematic on touch screen devices.

Yeah, I have a hell of a time using the history and diff interfaces on touchscreen period. These are in need of an overhaul (part of the minerva project perhaps).

(In reply to comment #4)

And, for what's worth, I hide rollback links everywhere because I never use
them and when they were exposed, I would accidentally click them. This is
particularly problematic on touch screen devices.

I filed the rollback issue as bug 47782.

Someone could probably expand my solution on Bug 46412 and my new [[User:Technical 13/Scripts/NoThanks.js]] to make it so that "(thank)" (or any of the others) is grayed out until clicked on and then the second click would perform the action... I would be happy to work on that. I've been thinking of improving and modifying that code anyways and I could add multiple settings to allow for hiding/removal of rollback, block, thank, and undo links based on user settings...

ignatzmice.wiki wrote:

(In reply to comment #8)

Someone could probably expand my solution on Bug 46412 and my new
[[User:Technical 13/Scripts/NoThanks.js]] to make it so that "(thank)" (or any
of the others) is grayed out until clicked on and then the second click would
perform the action...

*Something* like that would be good. Maybe not grayed out, as that often (such as in pref panes) means "this option is not available, move along". Maybe the "thank" could turn into "are you sure?" or similar once clicked, and clicking again would actually do it. But—again—I am worried about JS bloat. sigh...

JohnCD67 wrote:

I'm not sure what's the best solution, but a one-click, non-reversible "Thank" button right next to "Undo" is *not* a good idea. If accidentally clicked when undoing vandalism or an unacceptable edit, the recipient will think it is sarcasm, or just be confused, so it would be necessary to follow up with an awkward "ignore that thank-you, it was a mistake, I have undone your edit because... " message.

I'm still thinking that making the post-thank bold text (Thanked) into a link that can be clicked to (de-thank) or (un-thank) is the best solution.

ignatzmice.wiki wrote:

(In reply to comment #11)

I'm still thinking that making the post-thank bold text (Thanked) into a link
that can be clicked to (de-thank) or (un-thank) is the best solution.

Brilliant. This would be best, I think. Prolly would require massive coding; I rather imagine the ability to *remove* notifications isn't in place yet. But it would be the most elegant.

Okay, in other news pertaining to thanks... I just learned about [[Special:Log/thanks]] and think that this log should be expanded to include a link to the edit. So instead of:

11:26, June 3, 2013 Okeyes (WMF) (talk | contribs) thanked Foo (talk | contribs)

it would read:

11:26, June 3, 2013 Okeyes (WMF) (talk | contribs) thanked Foo (talk | contribs) for this edit

and the words "this edit" would link to the diff of the revision...

(In reply to comment #11)

I'm still thinking that making the post-thank bold text (Thanked) into a link
that can be clicked to (de-thank) or (un-thank) is the best solution.

You should read bug 46690 comment 4 and the follow-up comment.

(In reply to comment #13)

Okay, in other news pertaining to thanks... [...]

Yeah, this is a separate issue. :-) I split this out to bug 49087.

Thanks for all your recommendations for improving the Thanks feature! We will review them with our design team this week and respond in a few days. In the meantime, I have given a normal priority to this bug, so it shows up higher on our list.

ypnypn9 wrote:

How about if you click "thank", you get a pop-up saying

Thank <username> for this edit. (OK) (Cancel)

This would both clarify what the link means, and provide a confirmation/undo option.

ypnypn9's suggestion seems the most reasonable, both in terms of technical complexity and non-confusing UI-ness.

JohnCD67 wrote:

I too agree with ypnypn9's suggestion of an "Are you sure?" type pop-up requiring a second click, as a more natural alternative to an "Un-thank" option, and less confusing to the recipient.

Hi everyone, thank you so much for all your helpful feedback about the Thanks feature! We have reviewed all the comments from a variety of channels and have started to discuss and prioritize feature requests, based on your suggestions.

Over a dozen people have reported issues with the thanks link, which has caused some to accidentally click "thank" instead of "undo" on history and diff pages, as described on this Bugzilla ticket.

We are now working on this issue as our top priority, as it appears that the current placement next to undo is problematic, as well as the lack of a confirmation or 'unthank' function.

To help us solve this issue quickly, we would be grateful if you could answer a few questions, so we can pinpoint the problem more accurately -- and develop an appropriate solution in coming days.

To keep our discussion focused in one place, we have posted these questions and a feature update on this Thanks talk page:
http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Thanks_feature_update

We encourage you to post your answers on that thread.

Thanks again for all your good insights!

P.S.: Personally, I like ypnypn9's idea to show a popup saying 'Thank <username> for this edit. (OK) (Cancel)', as described above. This seems like a reasonable and practical solution. But let's take a closer look at the answers to our questions to finalize the best solution based on user feedback.

As an intermediate solution, can we at least swap the positions of the "Undo" and "Thank" links? That should dramatically decrease the likelyhood of clicking Thanks by accident, as we all expect the Undo link at the right most position.

(In reply to comment #21)

As an intermediate solution, can we at least swap the positions of the "Undo"
and "Thank" links? That should dramatically decrease the likelyhood of
clicking
Thanks by accident, as we all expect the Undo link at the right most
position.

Please do not do that... It will cause a lot more confusion than it will do good.

I agree with Technical 13.

This proposed re-ordering of links seems premature, since we're all discussing better solutions with the community.

What community members are telling us is that they don't think that a cosmetic solution is sufficient (e.g. adding more space or a visual cue, or changing the order of the links).

Based on community feedback, I just posted my findings and recommendations for next steps here:

http://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Recap

Feel free to chime in on that discussion page about the two key ideas we're now considering (confirmation popup or quick countdown).

The full spreadsheet of community responses is here:

https://docs.google.com/a/wikimedia.org/spreadsheet/ccc?key=0Aq_75_5y5sKWdFJ6MjN5UTlpYlMwVW1lQVFnbnJFSFE#gid=0

Overall, I think we're getting to a good place with this discussion. Thanks to Technical 13 and other community members for all your help in making this happen!

To be continued ...

Fabrice

Confirmation step added in https://gerrit.wikimedia.org/r/#/c/67591/. Needs review.

Thanks, Kaldari. Let's try it out that way and see if it solves the problem. Much appreciated.

This fix is live on en.wiki now. Can this bug be closed?

(In reply to comment #26)

This fix is live on en.wiki now. Can this bug be closed?

I'd rather it wasn't until there has been a few days to try it out and see what the response is. Just my personal thoughts though...

I agree. We would like to confirm that this implementation works for community members, in the spirit of close collaboration and rapid iterations for this experimental feature. I will post an update shortly on the Notification and Thanks talk pages to get some feedback. Thanks!

This appears rather fixed now. :)

Restricted Application added a project: Collaboration-Team-Triage. · View Herald TranscriptNov 15 2017, 1:40 PM