Page MenuHomePhabricator

Add "thanks" links to Special:Watchlist and Special:Contributions
Open, NormalPublic

Description

I would personally be more likely to use the thanks feature if there were links for it on [[Special:Watchlist]] and [[Special:Contributions]] instead of having to navigate to &action=history or view a diff which actually causes the effect of having to confirm the thanks twice (3 clicks to "thank").


See Also:
T57648: Remove Thanks from History pages

Details

Reference
bz49541

Event Timeline

bzimport raised the priority of this task from to Normal.Nov 22 2014, 1:47 AM
bzimport added a project: Thanks.
bzimport set Reference to bz49541.
bzimport added a subscriber: Unknown Object (MLST).

Right now Thanks is using a couple hooks that have roughly the same interface, HistoryRevisionTools and DiffRevisionTools. These both expose an array of revisionTools which includes stuff like 'undo' and 'rollback'. I'm not sure if Special:Watchlist or Special:Contributions have something similar. If they do, it should be a trivial change, if not, we may have to add or edit some hooks in the core code.

(In reply to comment #1)

Right now Thanks is using a couple hooks that have roughly the same
interface, HistoryRevisionTools and DiffRevisionTools. These both expose an
array of revisionTools which includes stuff like 'undo' and 'rollback'. I'm not
sure if Special:Watchlist or Special:Contributions have something similar. If
they do, it should be a trivial change, if not, we may have to add or edit some
hooks in the core code.

[[Special:Watchlist]] and [[Special:Contributions]] have 'undo' and 'rollback' links so I'm assuming they have those hooks available.

The larger issue is interface clutter.

(In reply to comment #3)

The larger issue is interface clutter.

I don't think that is any more of a concern on these two interfaces than it was on history and diff pages. If anything, these two pages were less cluttered to start with (at least with Twinkle enabled). Again, like in other things, I wouldn't be opposed to a JavaScript that will allow editors to add the thanks links on those pages just for them.

  • Bug 48999 has been marked as a duplicate of this bug. ***

I support investigating this proposal further, and note that this idea has also been brought up on this Thanks discussion page:
https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Add_thanks_link_to_more_locations

Our research so far suggests that the Thanks tool is useful for both new and experienced users, which supports the idea that we make it available in more locations, based on the latest findings posted here:
https://en.wikipedia.org/wiki/Wikipedia_talk:Notifications/Thanks#Whether_to_have_a_preference_to_hide_.27thank.27

I recommend we consider design solutions that might provide this valuable tool in ways that minimize clutter on these pages. These pages could use some design love anyway, and we may be able to improve them in the process. :)

I'd love to see the thank action in more places

I would really like thanking to be possible from Special:RecentChanges and Special:Watchlist and any other page used for patrolling. Such pages are the only way to possibly deliver thanks in a timely fashion to anonymous contributors.

Anonymous contributors could certainly use some positive feedback. It might be possible to integrate a 'please register' message into the thanks, which would further enhance our ability to recruit good anonymous contributors into long-term contributors.

It doesn't make much sense to have thanks delivered to most IP addresses except during the current session of the user. Only someone watching or patrolling is in a good position to offer timely thanks.

The opportunity to offer positive feedback might also draw more and different types of people to do patrolling, a chronic need at wiktionaries.

Anons won't have echo in their personal bar and therefore wouldn't have a notification to check their talk page, which, is also awkward to access if you don't have a personal bar. I'm not against the bug in general (MORE POSITIVE INTERACTIONS!) but i'd rather us remove the confirmation step from thanks rather than trying to solve for thanking anons right now.

Kelson added a subscriber: Kelson.Dec 18 2014, 7:23 PM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 28 2015, 1:39 AM

I'll take care of this. :D

Right now Thanks is using a couple hooks that have roughly the same interface, HistoryRevisionTools and DiffRevisionTools. These both expose an array of revisionTools which includes stuff like 'undo' and 'rollback'. I'm not sure if Special:Watchlist or Special:Contributions have something similar. If they do, it should be a trivial change, if not, we may have to add or edit some hooks in the core code.

(In reply to comment #1)
[[Special:Watchlist]] and [[Special:Contributions]] have 'undo' and 'rollback' links so I'm assuming they have those hooks available.

Nope, SpecialWatchlist and SpecialContributions have neither of the hooks. So this is not a trivial change.

Thanks.hooks has the handler function insertThankLink for the HistoryRevisionTools and DiffRevisionTools, which in turn calls the generateThankElement.
The latter returns an html element in an array, resulting in either a thank link or thanked span based on users session.

Since directly adding one of these hooks won't work - as the element is in a list and hence thanks link can't be directly appended outside a list element - we need to find a set of hooks and operations which would enable us to add in the thanks link to SpecialWatchlist and SpecialContributions.

I'll elaborate on this as soon as I can. Any suggestions?

Some more observations:

SpecialWatchlist has a function outputChangesList which gets its $list variable from newFromContext, which is in turn defined in changes/OldChangesList.

In the lines:

if ( !Hooks::run( 'OldChangesListRecentChangesLine', [ &$this, &$html, $rc, &$classes ] ) ) {
			return false;
	}

	$dateheader = ''; // $html now contains only <li>...</li>, for hooks' convenience.
	$this->insertDateHeader( $dateheader, $rc->mAttribs['rc_timestamp'] );
	return "$dateheader<li class=\"" . implode( ' ', $classes ) . "\">" . $html . "</li>\n";

if I change the contents of the <li> element (say add a 'random text' instead of (or after ) the $html, it shows in the Watchlist changes. I think this is where we need to add in the thanks hook and link to make the change effective.

Question is, where else will this change show effects? What will be the repurcussions of the same? Is this the correct way of approaching things?

@kaldari @jayvdb ?

It looks like you can use the ContributionsLineEnding (Special:Contributions), OldChangesListRecentChangesLine (Special:Watchlist), and EnhancedChangesList::getLogText.

Some more observations:
SpecialWatchlist has a function outputChangesList which gets its $list variable from newFromContext, which is in turn defined in changes/OldChangesList.

It actually depends on the request options and user preferences. For enhanced recent changes, it would be EnhancedChangesList.

The larger issue is interface clutter.

The even larger issue is whether it makes sense at all to have a thank button on those pages. The task description fails to address the point.

Most platforms put a lot of thought in this question, e.g. StackExchange users go around boasting about how they don't have down/upvoting buttons on the lists of posts as Reddit does.

In T51541#2166139, @Mattflaschen wrote:

It looks like you can use the ContributionsLineEnding (Special:Contributions), OldChangesListRecentChangesLine (Special:Watchlist), and EnhancedChangesList::getLogText.
It actually depends on the request options and user preferences. For enhanced recent changes, it would be EnhancedChangesList.

For Special:Watchlist, using hooks in EnhancedChangesList seems to be a way forward, indeed.

EnhancedChangesListModifyBlockLineData passes arguments ($this, &$data, $rcObj). As mentioned above, $data is the array we want to change, so the changes are reflected in the html element $line and then reflected in Special:Watchlist. So, I can add a function handler to Thanks.Hooks (lets call it watchthank temporarily) which takes in the same arguments as the Hook, and change the $data variable (since it's been passed by reference, the changes will be reflected without the need to return any variable). Also, I'd need to add the corresponding function handler to Thanks/extension.json.

I've tried it out with just a string added to $data, and here's how the results look on my local wiki:



I think I'll have to use the generateThankElement function in Thanks.Hooks to add the thank link, but it needs arguments $rev, $recipient - so I need to get them from $rcobj or $data somehow. I'll look into it.

jayvdb added a comment.Apr 8 2016, 9:14 AM

The larger issue is interface clutter.

The even larger issue is whether it makes sense at all to have a thank button on those pages. The task description fails to address the point.
Most platforms put a lot of thought in this question, e.g. StackExchange users go around boasting about how they don't have down/upvoting buttons on the lists of posts as Reddit does.

Valid concern. IMO the feature is reasonable, as demonstrated that some platforms do choose to have this type of feature.

But it can be disabled by default on Wikimedia projects. WMF would probably be best placed to do some analysis of user behaviour to determine whether it is appropriate to enable it for their wikis by default, and it might be necessary to make it a user option (personally I think the rollback link on Special:Watchlist and Special:Recentchanges is particularly useless and even problematic , encouraging reverting without reviewing - it is better to navigate to the diff, or to user contribs before starting to nuke the persons contribs ).

I've figured out how to add the thank link in both Special:Watchlist and Special:Contributions. :D


For Special:Watchlist:

I looked at the datatypes of the members of $rcObj - and found that rc_this_oldid refers to the concerned revision id, and that rc_user refers to the concerned user. I looked around the code a bit, and found that I can use these to get the arguments to pass to the generateThankElement function in Thanks.Hooks using the following code:

/**
	 * Function handler for EnhancedChangesListModifyBlockLineData Hook
	 * Adds a thanklink to the $data in Special:Watchlist
	 */
	public static function watchthank( $rv, &$data, $rcobj) {
		$rev = Revision::newFromId($rcobj->mAttribs['rc_this_oldid']);
		$user = User::newFromId($rcobj->mAttribs['rc_user']);
		$data['thanklink'] = self::generateThankElement( $rev, $user );
	}

The result looks like this on my local wiki (notice the 'thank' link at the end of the line):


For Special:Contributions:

The relevant Hook ContributionsLineEnding is in ContribsPager.php. It passes the arguments (&$ret, $row, &$classes). Luckily the $row object directly has rev_id and rev_user for generateThankElement. The code required in Thanks.Hooks is as follows:

/**
	 * Function handler for ContributionsLineEnding Hook
	 * Adds a thanklink to the 
	 */
	public static function thankContrib( $rv2, &$ret, $row, &$classes ) {
		global $wgUser;
		$rev = Revision::newFromId($row->rev_id);
		$user = User::newFromId($row->rev_user);
		if ( $row->rev_id != $wgUser->getId())
			$ret .= self::generateThankElement( $rev, $user );
	}

The result is like this:


Flip side to both - I still have to figure out a way to add the thank link within parentheses. I'll look into that, too.
@Mattflaschen @jayvdb

jayvdb added a comment.Apr 9 2016, 4:29 PM

It isn't inside the bracket on https://en.wikipedia.org/w/index.php?title=Privy_council&diff=prev&oldid=700851105 , so maybe just make it visually appealing and get a patch up for review to see what ppl think regarding the UI.

Change 282616 had a related patch set uploaded (by Darthbhyrava):
Add thank links to Special:Watchlist and Special:Contributions

https://gerrit.wikimedia.org/r/282616

Added the link in parentheses, and submitted a patch. Any more suggestions for the UI?

Made some changes in accordance with @matej_suchanek 's views. Please take a look at the patch and see if it can be merged or if it needs more work?
@kaldari?

matej_suchanek removed a subscriber: wikibugs-l-list.

@jmatazzoni CCing you since it is a significant proposed user-facing change that affects Thanks.

What is the purpose of adding the blind thank you link? Without seeing the diff you never know what you're actually thanking for. Having thank you links only on diff pages is reasonable.

@Danny_B e.g. based on the summary:

RFC closed

=> thank

page moved from [[Europe continent]] to [[Europe]]

=> thank

He7d3r added a comment.May 1 2016, 8:23 PM

...and once T60485 is done:

changed group membership for SomeUser from (none) to administrator

=> thank

blocked 1.0.0.0 (talk) with an expiration time of 31 hours (anon. only, account creation blocked) (Vandalism)

=> thank
etc...

I'm sorry to be tuning into this ticket only now. Did anyone in Design approve the interface changes on Watchlist and Contributions? If not, can someone please post a screenshot that shows how this will display on typical pages (the examples above are very stripped down)? I'd like @Pginer-WMF to have a pass. Thanks.

@Danny_B e.g. based on the summary:
RFC closed => thank

OK, so if some user will put some nonsense in the page, but reasonable summary, you are going to thank him just because of the summary without looking at the actual action? That sounds... scary...

@Danny_B I don't see a reason, why an administrator should add nonsense with RFC closed summary into RFC page. Except it would not be an administrator. But then it would be too suspicious to thank and better to check it out...

I didn't write "an administrator", but "some user". Neither I was talking about RFC page.

So how many such actions, where you can blindly believe what has been done according to the summary? A dozen per year?

Dvorapa added a comment.EditedMay 31 2016, 9:50 AM

@Danny_B But I talk about these. According to the summary I usualy thank about once or twice a day. And these steps between seeing, what anybody made and actually thanking him for the change are too pointless

No, they are not pointless at all. They actually guarantee that nobody will thank blindly without actually seeing the action to be thanked.

The larger issue is interface clutter.

Correct. Including code bloating which will carry the payload of more data needed to be transferred, higher memory usage due to more complex DOM etc. etc...

Such feature should not be part of the core, but can be easily achieved by on-demand (opt-in) gadget. The amount of thanking people is small, the amount of those who do it periodically is yet smaller. Why annoy others who don't (want to) use it with mandatory pushing it to them in the interface?

jayvdb added a comment.Jun 6 2016, 6:55 PM

I didn't write "an administrator", but "some user". Neither I was talking about RFC page.
So how many such actions, where you can blindly believe what has been done according to the summary? A dozen per year?

Quite often actually, in my experience.

Often I know the main editor(s) to an article, or its current torch-bearers, and have full confidence in their honesty, and like to show appreciation when I see they have made a sizable or difficult edit as evidenced by their edit summary and my prior knowledge of the ongoing discussions on the talk page, or open todo items.

A lot of tools (gadgets, scripts, bot frameworks) indicate what was done using the tool, fairly precisely, and I trusty their edit summary.

An obvious special case of that is when the UI says it is a revert, we believe it is a revert. This is especially helpful for a nonsense edit to a large page, where the revert is a very large diff page, which can be painful to load. We dont need to check the diff to know it was a revert, and it is usually very obvious what was being reverted.

My personal use case is trying to thank the first edit to a page. If I am on the page history, there is a thank link. I use it. I do not always check that the article was perfect on the first edit, because I've seen their contributions to it. I'd also like to access that feature from the Special:Contributions for the new page edit; I am often trawling through peoples very old contributions looking for especially good edits to thank them for.

I suspect that patrollers will have an interest it this appear on Special:Watchlist, but I cant talk about any usages for that, as I am not often patrolling anymore.
However as @He7d3r was pointed out above, once T60485 is done there will be many more use cases for thank links appearing on Special:Watchlist, as finding the relevant log entry on Special:Log can be quite painful.

But if it can be done with a gadget cleanly, that would be OK too, and would be a good proof of concept to see how widely this feature might be used.

@darthbhyrava: This issue has been assigned to you a while ago. Could you please share a status update? Do you plan to work on fixing the patch in Gerrit based on the received feedback?
If you do not plan to work on this issue anymore, please remove yourself as assignee (via Add Action...Assign / Claim in the dropdown menu) so others could work on it. Thanks a lot!

Restricted Application added a subscriber: jeblad. · View Herald TranscriptAug 25 2017, 5:56 PM
Aklapper removed darthbhyrava as the assignee of this task.Sep 14 2017, 9:00 PM

@darthbhyrava: I am resetting the assignee of this task because there has not been progress lately (please correct me if I am wrong!).
Resetting the assignee avoids the impression that somebody is already working on this task. It also allows others to potentially work towards fixing this task.
Please claim this task again when you plan to work on it (via Add Action...Assign / Claim in the dropdown menu) - it would be welcome! Thanks for your understanding!

There have been objections that no-one would want to give thanks for an edit they haven't seen. Please note that there are add-ons which allow users to view diffs directly in the Watchlist. Thanks.

It's easy to think of use cases that might have someone asking someone else
to do something with material prepared offline or to execute or resume
executing a known routine. When there is an indication that task execution
has commenced thanks might be warranted. How common such situations might
be I don't know. I have been grateful for someone resuming execution of a
long-dormant bot at Wiktionary.

Restricted Application added a project: Growth-Team. · View Herald TranscriptAug 30 2018, 5:48 PM
Mh-3110 added a subscriber: Mh-3110.

Hi @darthbhyrava,
assigning this to you as you're working on it.
Thanks

Dvorapa removed darthbhyrava as the assignee of this task.EditedApr 4 2019, 8:08 AM

I think noone is working on this right now

Mh-3110 added a comment.EditedApr 4 2019, 10:21 AM

My bad!

@Aklapper , @Dvorapa thanks.

Krinkle renamed this task from Add thanks links on Special:Watchlist and Special:Contributions to Add "thanks" links to Special:Watchlist and Special:Contributions.Mon, Jun 24, 12:17 AM