Jump to content

Help talk:Notifications/Thanks: Difference between revisions

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Content deleted Content added
Line 374: Line 374:


:::::Then the [[Smiley]] article is wrong. It's written there that ''"the judge declared that the smiley face was not a "distinctive" mark, and therefore could not be trademarked by anyone"''. --[[User:Patrick87|Patrick87]] ([[User talk:Patrick87|talk]]) 18:33, 9 June 2013 (UTC)
:::::Then the [[Smiley]] article is wrong. It's written there that ''"the judge declared that the smiley face was not a "distinctive" mark, and therefore could not be trademarked by anyone"''. --[[User:Patrick87|Patrick87]] ([[User talk:Patrick87|talk]]) 18:33, 9 June 2013 (UTC)

== Thanks for multiple edits ==

Sometimes I'd like to express thanks for a group of edits — for example, when none of them is individually a big deal, but together they're really helpful. Any chance that we could get the chance to issue a single Thanks feature notice for a group of edits? I'm not clear how such a thing would be accomplished from a technical point of view. [[User:Nyttend|Nyttend]] ([[User talk:Nyttend|talk]]) 19:47, 9 June 2013 (UTC)

Revision as of 19:47, 9 June 2013

The 'Thanks notification' offers a new way to give positive feedback on Wikipedia. This experimental feature lets editors send a private 'Thank you' notification to users who make useful edits -- by clicking a small 'thank' link on their history or diff page.

The purpose of this notification is to give quick positive feedback to recognize productive contributions -- and it should be particularly helpful for encouraging new users during their first critical steps on Wikipedia. This small feature is now being tested on MediaWiki.org and we aim to release it on the English Wikipedia at the end of this week -- or the following week. We have intentionally kept it as simple as possible, so we can all evaluate it and improve it together, based on user feedback.

We welcome your feedback and look forward to a healthy discussion on this talk page, once you have had a chance to try it out. If you would like to test it in advance, you can do so on MediaWiki.org right now, as outlined on this testing page. And any user who does not want to be thanked will be able to disable this notifications in their preferences. To learn more about this feature, check out this Thanks overview page -- and our first specifications. We'll post an update here with more info once this feature is live. Fabrice Florin (WMF) (talk) 17:58, 28 May 2013 (UTC)[reply]

Watchlists and namespaces

  • Watchlists: This is Not going to be displayed on watchlist pages (just history pages, and diff pages), correct? (At least initially). If true, that probably warrants an explicit mention on the project page. (To prevent people worrying/complaining about "more links/cruft in my watchlist"). Thanks. –Quiddity (talk) 23:06, 28 May 2013 (UTC)[reply]
  • Namespace: Will it be in all namespace's history pages, or just article-namespace history pages? (the docs currently state the latter). Thanks. –Quiddity (talk) 23:06, 28 May 2013 (UTC)[reply]

Thanks, I've tried to fix/clarify both those points in the project page. Reword as needed. –Quiddity (talk) 01:21, 29 May 2013 (UTC)[reply]

Thanks, Quiddity! Sounds like namespaces is something we should discuss. I think it's potentially useful to have it in places like the talk namespace, but I think we should see if it has a good signal:noise ratio in practise. Okeyes (WMF) (talk) 07:13, 29 May 2013 (UTC)[reply]
2 quick notes on namespace: The main example image (currently used twice on the same page) uses the "user talk" namespace. We might want to change that, if the ideal use-case is for article edits.
Relatedly, I rambled a little about how I appreciate the feature's potential, and used talk-namespace edits as my example.
So, yeah - some potential good uses, and some potential restrictions to consider if it gets misused. But definitely better than anonymous upvotes! –Quiddity (talk) 07:55, 29 May 2013 (UTC)[reply]
Makes sense! Okeyes (WMF) (talk) 09:31, 29 May 2013 (UTC)[reply]
  • I'd really like to have this available from the watchlist too. That's where I see new edits crop up, and I'd like to thank the editor there and then. For people who complain about cruft on their watchlist you can always just make it easy to opt out. :) — Mr. Stradivarius ♪ talk ♪ 09:48, 1 June 2013 (UTC)[reply]

(undo | thank)

An illustration: nobody clicking "thank" in this example intended to—Kww(talk) 15:04, 4 June 2013 (UTC)[reply]

The current position of the button is very badly chosen in my opinion. It is too easy to click the "thank" button when one actually wants to "undo" an edit (or also the other way round). Especially since there seems to be no way to take back the thanks currently? --Patrick87 (talk) 02:17, 31 May 2013 (UTC)[reply]

Adding a "confirm thank" prompt would probably be the easiest solution.--Turtleey (talk) 03:39, 31 May 2013 (UTC)[reply]
Agree. I accidentally thanked a vandal. Brycehughes (talk) 05:24, 31 May 2013 (UTC)[reply]
@Patrick87:, @Turtleey:, @Brycehughes: Out of interest, why did you click the link you think ? Was it muscle memory, expectation that no longer matched, or 'jumping' content or something ? —TheDJ (talkcontribs) 11:02, 31 May 2013 (UTC)[reply]
Fortunately I didn't click the wrong link accidentally for now (I didn't dare to try the link at all because I assume there is no possibility to undo the "thank"), but it's somehow strange to find the "undo" link (which is used to revert vandalism most of the time) besides the "thank" link (which should be used for very good contributions). Dealing with vandalism and thanking authors are two different workflows, that don't have anything in common (at least not for me), therefore it's confusing to have both buttons directly next to each other. Maybe I'll get used to it, but that was my first impression (and I thought we were supposed to give feedback based on our first impressions on the new function? That's at least what new editor will see.). --Patrick87 (talk) 11:33, 31 May 2013 (UTC)[reply]
Thanks for the helpful feedback :). I'd argue they're part of the same workflow; a good/bad evaluation of content. Bad, undo. Good, thank. Okeyes (WMF) (talk) 12:42, 31 May 2013 (UTC)[reply]
Agree, but given that they are part of the same workflow, one would naturally expect similar behavior. Undo is at least a two click process. Brycehughes (talk) 17:00, 31 May 2013 (UTC)[reply]
The reason why these are different workflows for me: "thank" doesn't change any article content at all, it's just a social feature; "undo"s main purpose is to change article content while it is not a social feature (although the author gets notified in the meantime. Therefore the functions are totally different for me. --Patrick87 (talk) 17:20, 31 May 2013 (UTC)[reply]
OK, so no one has actually experienced this problem yet ? The report is about the potential risk to click the wrong link ? —TheDJ (talkcontribs) 21:41, 31 May 2013 (UTC)[reply]
Editors are describing misclicks due to its position in the discussion here. Position aside, the additional problem is that there is no confirmation and no way to retract a thanks (like you can with undo), thus as people try or test the feature for the first time, many will expect to be able to confirm or at least retract, which they won't be able to do after they try it, and then we may have a lot of extraneous and misplaced love floating around the place. Brycehughes (talk) 22:10, 31 May 2013 (UTC)[reply]
I had assumed there would be a confirmation. So I picked a random edit and clicked Thanks. Oops. Brycehughes (talk) 16:41, 31 May 2013 (UTC)[reply]
I think we can all agree that the 'history/rc' like pages are messy and have been for quite a while (this was known even when undo was introduced some 5 years ago). —TheDJ (talkcontribs) 21:41, 31 May 2013 (UTC)[reply]

For anyone interested, there's an open bug here regarding the Thanks workflow: bugzilla:47658. --MZMcBride (talk) 13:54, 31 May 2013 (UTC)[reply]

Yeah, the placement isn't terrible (to me) if there's a way to undo it. A confirmation would also be nice. I just thanked an editor I reverted. Ed [talk] [majestic titan] 17:57, 31 May 2013 (UTC)[reply]
I experienced the problem once yesterday: "thanked" an edit that I was intending to undo with an explanation. In my case it was apparently because the page had not fully rendered and the content "jumped" a bit just as I was aiming for the "undo". I agree that we should have a confirmation page or at least a way to reverse. --Arxiloxos (talk) 19:36, 1 June 2013 (UTC)[reply]
  • I'd agree that there should be a way to confirm the thanks in order to prevent mistakes. AutomaticStrikeout  ?  02:37, 2 June 2013 (UTC)[reply]
  • Add my name to the list of people who would like to have a way to undo a "thank" (or, better still, the "thank" feature removed outright but I doubt that's going to happen; I prefer going to someone's talk page than lazily pressing a button); I accidentally "thanked" someone I was reverting/undoing after automatically clicking where the "undo" feature used to be. The "thank" I gave is meaningless because I reverted the edit I was supposedly expressing gratitude for. Acalamari 09:05, 2 June 2013 (UTC)[reply]
  • I agree that there should be a a way to undo or confirm the thanks. Hopefully this is implemented as one of the first updates to this new feature. - tucoxn\talk 22:27, 6 June 2013 (UTC)[reply]

How to turn off this feature

Okay, the current way to get rid of the "thank" links is to tick "Exclude me from feature experiments" in preferences. However, I'm guessing this won't always be a feature experiment... Will there be another option to disable this once it is non-experimental? – PartTimeGnome (talk | contribs) 20:26, 31 May 2013 (UTC)[reply]

Good question! Fabrice? Okeyes (WMF) (talk) 20:49, 31 May 2013 (UTC)[reply]
Hi PartTimeGnome, thanks for your question. I'm afraid we have not yet determined a solution for this turning off the Thanks link when it is no longer experimental. We'd like to first see how this feature is being used, then determine the best option with your help. Perhaps it could be tied with the Notifications preferences, so if you tell us you don't want to be thanked, we can assume that you don't want to thank people either? Suggestions welcome, but take your time ... :) Fabrice Florin (WMF) (talk) 21:04, 5 June 2013 (UTC)[reply]
It makes sense to me to disable sending thanks if receiving is off; I see no use for send-only. However, it is reasonable to want to know if someone thanks you while not wanting to send thanks yourself (i.e. receive-only).
I currently fall in the latter category – I want to see thanks sent to me, but the "thank" link for sending my own is useless clutter (see below). If bug 49161 is fixed, this would no longer be an issue – the link would either work or be hidden from me, depending on the chosen solution. – PartTimeGnome (talk | contribs) 21:25, 5 June 2013 (UTC)[reply]

You're welcome

I just got thanked using this tool for the first time today, and I found myself wanting to say "you're welcome" to the user who thanked me. But it seemed a bit too much to actually go to their talk page and leave them a message thanking them for the thanks they gave me. Could there be a feature like a "you're welcome" button? I thought of "thank this user back" and "show appreciation", but I'm sure someone else can come up with something more snappy. — Mr. Stradivarius ♪ talk ♪ 09:55, 1 June 2013 (UTC)[reply]

Only if, on receiving "you're welcome", I can hit a "that's OK, no problem" button... Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:48, 1 June 2013 (UTC)[reply]
Or we could just cut out the middleman and get the developers to code up an Infinite Loop of Thanks. ;) Seriously, though, I think something to let people know that you got the thanks and that you appreciate it might not be such a bad idea. — Mr. Stradivarius ♪ talk ♪ 11:11, 1 June 2013 (UTC)[reply]
Oh, come on! This is the price you pay with an impersonal "Thank" feature, that is triggered by pushing a button somewhere on a history page. There's no point to be able to answer back. That's exactly why I don't really like the feature at all (but I don't want to start a huge discussion about this now, just mention my reasons): On the one hand, when you really want to thank a user for an exceptional contribution, it stays impersonal and cold, no comparison to leaving a personal comment or even a barnstar on the users talk page. On the other hand it can lead to people flooding Wikipedia with thanks for even average contributions, making a "thank" worth even less. It's (sorry for the example, but it just matches perfectly) like "Likes" on facebook: A single like counts nothing, it's the comment with the most likes that counts, and this concept simply doesn't work for Wikipedia (at least I don't want Wikipedia to become a place where this concept works). --Patrick87 (talk) 13:54, 1 June 2013 (UTC)[reply]
I would say that any "Thanks" that is expecting a reply would be on the talk page. The advantage of sending it this way is that it is a ping, and no discussion is necessary. It is simply a tip of the hat, not a discussion needing a reply. Dennis Brown / / © / @ 18:38, 1 June 2013 (UTC)[reply]

How do I un-thank?

I was unaware this feature was being implemented, and this morning I just "thanked" two edits I was intending to "undo" by accident, since the buttons are now right next to each other. How do I retract these "thanks"? Chubbles (talk) 18:34, 1 June 2013 (UTC)[reply]

You can't. Thanks are irreversible. This is discussed in the (undo | thank) section above. – PartTimeGnome (talk | contribs) 20:01, 1 June 2013 (UTC)[reply]
Wow, really? And where do I go to complain about that? I can't be the only person who's very uncomfortable with a function that has no checkstep and no possibility of undoing. I accidentally click on things all the time, but at least I can fix a screwup for everything else. Chubbles (talk) 07:58, 2 June 2013 (UTC)[reply]
Same place as always, bugzilla. —TheDJ (talkcontribs) 11:34, 2 June 2013 (UTC)[reply]
Chubbles, this is something we're actively discussing and looking for ways to resolve, as you can see from the discussion two sections above this one. Okeyes (WMF) (talk) 12:52, 2 June 2013 (UTC)[reply]
Just tested this. I expected some kind of confirmation or explanation. πr2 (tc) 18:53, 2 June 2013 (UTC)[reply]
I thanked three times, when I was only going to undo edit... And now the user [maybe] thinks that he's contributors were good, or then he thinks that wtf I'm doing... --Stryn (talk) 19:33, 3 June 2013 (UTC)[reply]
I too have thanked about three people that I was meaning to undo. I've turned off the feature but agree with what Stryn says - three people now probably think either I'm an idiot or they made correct edits. –anemoneprojectors13:08, 4 June 2013 (UTC)[reply]
We're working on this problem now; update in a sec :). Okeyes (WMF) (talk) 13:13, 4 June 2013 (UTC)[reply]
Unreversible one-click actions are seriously bad user-interface design, particularly with the spread of sensitive touch-screens, but I don't think "Un-thank" is the answer, and I'm not sure how it could work - how long would the option stay open, would the Thank message be removed from the notification tab or followed by a withdrawal message, and what if the recipient has noticed it before it is withdrawn? Much better have an "Are you sure?" check with a second click. JohnCD (talk) 21:41, 4 June 2013 (UTC)[reply]

JavaScript-only?

Do we need more JS-only features that are confusing to users with JS disabled? It's confusing to those with JS enabled too, but that's a different story... πr2 (tc) 03:37, 3 June 2013 (UTC)[reply]

Agreed. It is both silly and confusing to show a link that does nothing when JS is disabled. It isn't a big deal that it's a JS-only feature (it's hardly a core function), but it's plain sloppy to show a broken link to users who don't use JS.
I wouldn't have thought this to be too difficult to do without JS: The link target would go to somewhere like /w/index.php?title=Special:Thanks&oldid=REVISION&token=TOKEN, which would show a message like Your thanks have been sent to USERNAME.. It's a little clunkier than it is with JavaScript since it takes you away from the history page, but that's something I expect for not using JS. – PartTimeGnome (talk | contribs) 22:02, 3 June 2013 (UTC)[reply]
Agreed. Should a bug be filed? πr2 (tc) 23:55, 3 June 2013 (UTC)[reply]
 DonePartTimeGnome (talk | contribs) 00:10, 5 June 2013 (UTC)[reply]

Why is this not counted?

The project page says that thanks "are not publicly visible or counted up on the history page, diffs, or your contribution history." Could I ask that someone explain the rationale for deciding in favor of making this not publicly visible? Thanks. Blue Rasberry (talk) 18:33, 3 June 2013 (UTC)[reply]

I would guess that it's to prevent gamification and the explicit forming of cliques. Also to prevent people citing "the number of thanks I received for this edit" in discussions.
As for not adding it to our contributions history, that would lead to WP:editcountitis problems. (Ie. in RFA, if someone has made 1,000 "thank" edits (months from now), does that count towards their votecount?)
Ie. This seems to be intended (in its current iteration) as an utterly informal method of expressing gratitude or agreement with an edit. If someone wanted to express that gratitude or agreement in a formal/recorded/"for-the-record" manner, they would give a barnstar, or reply to the comment, or post a comment on the user's talkpage, or etc. (Just my guesses). –Quiddity (talk) 18:57, 3 June 2013 (UTC)[reply]
Note that sent thanks are logged - what they mean is that we don't keep a tally of thanks received for each editor, or revision. Okeyes (WMF) (talk) 19:48, 3 June 2013 (UTC)[reply]
Er, thanks received are also logged for each editor, just not publicly per revision. — HHHIPPO 20:46, 3 June 2013 (UTC)[reply]
Huh, that's just weird :/. Okeyes (WMF) (talk) 20:47, 3 June 2013 (UTC)[reply]
Quiddity is correct, based on my conversations with Fabrice and others around the office about this feature. We want this to be a genuine person to person thank you, not an endorsement or a tool for "voting up" edits. They're logged like Oliver notes, but AFAIK, this is primarily so that the community can track down potential over-use or abuse of the feature (e.g. is the current rate limit enough?). Steven Walling (WMF) • talk 20:21, 3 June 2013 (UTC)[reply]

I just made the horribly-coded User:PiRSquared17/thanks.js, so that Special:BlankPage/thanks//Rschen7754 tells you who has thanked User:Rschen7754, and Special:BlankPage/thanks/Rschen7754 tells you about the people he has thanked. Special:BlankPage/thanks tells you stats about the last 500 thanks. I know it could be improved, it's just a proof-of-concept. πr2 (tc) 02:24, 5 June 2013 (UTC)[reply]

Using that JS, Special:BlankPage/thanks/Rschen7754/Vogone tells you how many times he has thanked User:Vogone, etc. πr2 (tc) 02:24, 5 June 2013 (UTC)[reply]
Of course, it is not much different from using Special:Log/thanks. Except it gives you numbers, "count". πr2 (tc) 02:56, 5 June 2013 (UTC)[reply]
Oh no, our thanking shenanigans are over! :O --Rschen7754 02:59, 5 June 2013 (UTC)[reply]

Why don't I see "thanks" links?

I just received my first thanks. While I was pleased to get it, I was also mildly dismayed that I had not seen a way to send them. This page seems to imply that they should appear if I have my "Preferences | Appearance | Exclude me from feature experiments" unchecked (which is true). I have looked at several editor's editing history and recent changes. Should I see it?

Perhaps some other setting or gadget is interfering with it?

Here is a sample from Recent changes:

17:48:44  Gag Factor‎ (diff | hist) . . (-4)‎ . . Gene93k (talk | contribs | block) (unlinked Gwen Summers (deleted at AfD)) [rollback]

Here is a sample from Steven's editing history:

(del/undel) 2013-06-03T13:22:13 (diff | hist) . . (+29)‎ . . m Wikipedia talk:Notifications/Thanks ‎ (→‎Why is this not counted?)

Maybe I need to enable something else? —EncMstr (talk) 00:54, 4 June 2013 (UTC)[reply]

Try it on history pages (action=history), convenient example - next to undo. πr2 (tc) 04:16, 4 June 2013 (UTC)[reply]
Ah ha! It is there:
(cur | prev) 2013-06-03T21:17:35‎ PiRSquared17 (talk | contribs | block)‎ . . (22,361 bytes) (+15)‎ . . (→‎Why don't I see "thanks" links?: clar.) (rollback: 2 edits | undo | thank)
(cur | prev) 2013-06-03T21:16:53‎ PiRSquared17 (talk | contribs | block)‎ . . (22,346 bytes) (+436)‎ . . (→‎Why don't I see "thanks" links?: +) (undo | thank)
Thanks!  :-) —EncMstr (talk) 07:10, 4 June 2013 (UTC)[reply]

Does anyone ever actually THINK before implementing stuff like this?

There should be a way to simply tic a box in preferences that disables this...or even better, a box to opt-IN. I'm not a programmer, so talk of importing lines into some js file are a little confusing, and I suspect that it would be for many other non-technical people as well.

Make this easier to get rid of please, and stop turning the project into Facebook. Tarc (talk) 12:41, 4 June 2013 (UTC)[reply]

Er. There is a way to simply tick a box in preferences that disables this. See the section of the thanks page you were referring to re importing lines into some JS file. Our goal is not to turn Wikipedia into facebook, and for reference, we did actually think before implementing this. If you want to discuss your concerns in more detail, I'm happy to talk it through with you here, or set up a skype/google hangout call. Okeyes (WMF) (talk) 13:02, 4 June 2013 (UTC)[reply]
Could you be a little more precise? I have long had the "experimental" box un-ticked, and at the moment I still see the "thanks" links. Tarc (talk) 14:07, 4 June 2013 (UTC)[reply]
Ah, this may be the source of the problem; the experimental box is "exclude me from feature experiments", so you have to have it ticked to be excluded (which seems somewhat backwards, but.) Okeyes (WMF) (talk) 14:15, 4 June 2013 (UTC)[reply]
Yes, confusingly worded, but now that works fine. I'd thank your post, but I already turned it off. (irony) :) Tarc (talk) 14:30, 4 June 2013 (UTC)[reply]

Thanks in notifications

From what I understand, flow of talk and information on Wikipedia is supposed to be public, rather than private. When I found out about this new feature, I thought it was a good idea, because I presumed that it would leave a small automatic message on the person's talk page, and then notify them (especially since it says "thanked" rather than "thanks"). I would be in favour of this. However, sending only a private message of thanks is not a notification, but an actual message. This would seem to be a change in the way Wikipedia normally functions. Has there been a consensus about this? If so, can you direct me to the discussion?—Anne Delong (talk) 13:24, 4 June 2013 (UTC)[reply]

Well, it's a notification that the person appreciated your contribution. I would note that thanks sent are logged, as are thanks received, so the information is available in cases of abuse, and for the sake of transparency. Okeyes (WMF) (talk) 13:38, 4 June 2013 (UTC)[reply]
That helps. Why does it say "thanked", as if the thanking was posted somewhere already? In my opinion it is better if the positive feedback appears on the talk page being edited or the talk page of the article being edited. Then everyone can see the prevailing opinion/consensus. Because this notification is easier than actually writing a message, a person could leave a message on a talk page, have one person add a message of disagreement, and 50 people could send these notices to the second person, and none to the first, and the first person would have no idea that consensus had gone against him or her. Soon other types of these messages which are not notifications will be added and communication on the Wikipedia will no longer be open. It makes me very uncomfortable, as if people are talking behind my back. Again I ask, please direct me to the consensus discussion that I missed about adding this feature. —Anne Delong (talk) 15:21, 4 June 2013 (UTC)[reply]
There wasn't a consensus discussion, Anne. Interface changes are developed by the WMF and then forced upon us. They tend to pay some attention to what we say, but they feel no obligation whatsoever to get our consent or approval.—Kww(talk) 15:30, 4 June 2013 (UTC)[reply]
Anne, the intention is not for this feature to act as a consensus-deciding or representing piece of software, or as a way of denoting how supported a particular position is. It's not got that role, and I can't imagine a world in which it's used for that. It's simply a way of saying "hey, I liked that edit" easily. Maybe it was a copyedit that was particularly helpful, or the addition of some DAB-links, or something similarly small and useful. The vast majority of edits are not controversial, and any edit substantial enough to be controversial is unlikely to be engaged with using this feature anyway. Okeyes (WMF) (talk) 16:26, 4 June 2013 (UTC)[reply]
Anne's point is still quite valid, Okeyes. If I'm chastising an editor for a bad edit and that editor has received 100 "thank you"s for the very edit that I'm chastising him over, that's valuable information. It will provide valuable context for future discussion. It should be readily visible, not information that should require a search through a log. Bear in mind that we all have contexts for our discussions: since I am one of the few administrators that actually watches over the Disney Channel articles, I wind up in a lot of discussions with young children. Knowing that a nine-year-old is rejecting my warnings because he is being encouraged by a squad of seven-year-olds is important.—Kww(talk) 16:54, 4 June 2013 (UTC)[reply]
Seven year olds who can handle diff links and history pages? I don't deny that this is a valid use case, I'm just arguing that it's an edge case. You could make the same argument that we should surface patrol actions in contributions to avoid people discussing negative elements of articles that have been 'reviewed' and thus declared okay. Okeyes (WMF) (talk) 17:10, 4 June 2013 (UTC)[reply]
Kww and Anne, I think the idea of keeping the thanks just between the giver and receiver is to avoid this feature supplanting normal decision making/consensus discussions (if they were displayed on a talk page, we'd have sort of an "up-vote" scenario for edits, something not good in contentious situations where discussion is key). Kww, in your scenario, I'd say the seven-year-old editors who are thanking your problem editor are irrelevant to any consensus process; they're going to have go to "on record" for their opinions to have any weight in a dispute. I'm not saying there isn't potential for abuse with this feature, there probably is some. The Interior (Talk) 17:23, 4 June 2013 (UTC)[reply]
They aren't really irrelevant. In terms of editor retention, trying to deal firmly but effectively with the children that edit here is actually pretty important. If they feel that they are being dealt with arbitrarily, they turn into vandals quite rapidly. Seven is the low edge, but I'm quite willing to bet that the majority of editors that I deal with on a daily basis are under 15. I know for a fact that most of the ones I rely on in terms of being able to deal with problem situations because of their maturity are still in high school.—Kww(talk) 17:32, 4 June 2013 (UTC)[reply]
Sorry, Kww, just a clarification - didn't mean that the young editors were irrelevant (i agree that working diligently with them is important for the future of the project), just that their thanking our problem editor wouldn't strengthen his/her position in a dispute. The Interior (Talk) 18:23, 4 June 2013 (UTC)[reply]

The Interior is right on this; we're trying to avoid precisely this situation. I'd point out there's also nothing we can do about emails, either. Okeyes (WMF) (talk) 17:42, 4 June 2013 (UTC)[reply]

The best way to avoid the situation is to not implement the feature.—Kww(talk) 17:46, 4 June 2013 (UTC)[reply]
Er. Strictly-speaking, yes, but the feature has a lot of positive benefits and fills a purpose (said benefits are going to be scientifically tested, so we will have data). Okeyes (WMF) (talk) 17:49, 4 June 2013 (UTC)[reply]
All of this should have been covered in the consensus discussion leading up to the addition of this new feature. Can someone please point me to this discussion (3rd time asking - does it not exist?) Recently when I wanted to make a change to the Afc script I had to go through an Rfc, wait a month for comments, and then request closure. Don't the technical guys have to do the same thing, or are they free to just treat Wikipedia as a plaything? I'm sorry if I sound negative, but just because Kww used children as an example is not a fair reason to dismiss his point. I'm sure the page about a soap opera star that I was reviewing this morning wouldn't be any different. —Anne Delong (talk) 18:08, 4 June 2013 (UTC)[reply]
Why would there be any need for a consensus? A new feature was developed and enabled. No one has to use it. If it causes trouble, it can be switched off. The only way to know if it will work is to try it and see how it goes.
Just about every wiki feature has attracted a group of naysayers—discussion about the then-pending rollback facility springs to mind. Amazingly, Wikipedia hasn't shriveled in a heap of dust like the most vocal opponents predicted. —EncMstr (talk) 18:20, 4 June 2013 (UTC)[reply]
Anne, to quote the second reply you got to your question the first time you asked it, "There wasn't a consensus discussion". Okeyes (WMF) (talk) 18:46, 4 June 2013 (UTC)[reply]
And, no, the developers who maintain the site do not have to obey consensus when making technical changes. Again, this isn't a feature that can really be used as a substitute for consensus in discussions, and I can't imagine it being used for that. If you ever see someone citing the 'thanks' log as evidence their decision was a good one (and getting away with it!) let me know. Okeyes (WMF) (talk) 18:47, 4 June 2013 (UTC)[reply]
This is just a reminder that we are not the owners of Wikipedia, Anne: WMF is. They don't have to ask us what we think, nor do they have to listen when we voluntarily tell them. When we explain why what they have done will make our tasks more difficult, they don't have to care.—Kww(talk) 19:34, 4 June 2013 (UTC)[reply]
Kww, I do care. I'm not the owner of Wikipedia either, professionally or personally, and as someone who contributes quite a bit personally, this impacts me as much as it impacts you, iff it happens. We can't be building or killing features based on implausible use cases; it's totally inefficient and if we take the attitude of "something bad might maybe happen, kill it" we'd frankly take down MediaWiki as a whole. If and when it happens, let me know and I will kick people into gear on trying to work out a solution. But it seems highly improbable. Okeyes (WMF) (talk) 19:38, 4 June 2013 (UTC)[reply]
Sorry, I guess I missed the reply to my question. I had an edit conflict and had to repost further down the page and forgot to look back. However, in reply to "you can just turn it off", I am not concerned about my own use of it, but the effect of others' use on me. But now I am disillusioned, because after working hard for months to learn Wikipedia's procedures it seems that they are a sham and only apply to certain people and I am one of them. I feel tricked. I thought that I was becoming a part of a community of equals. It's especially irksome to see my own project, which was supposed to help the functioning of the Afc, ignored for this back-patting. I have said more than enough now. —Anne Delong (talk) 19:43, 4 June 2013 (UTC)[reply]
What project? What back-patting? If we've got a software project we're ignoring, by all means tell us about it. The community is a community of equals. The Foundation exists, to some degree, outside of the community. Okeyes (WMF) (talk) 21:32, 4 June 2013 (UTC)[reply]
Not meant at a personal level, just as a true statement: you don't have to care. You don't even have to listen. It's a WMF site, and WMF can do with it what it wants.
Your definition of plausible is quite different from mine: editors will grasp at any pretext of support when arguing with someone that objects to an edit they have made. The idea that these "thank you" things won't be taken as positive reinforcement for bad edits can only be based on the notion that they aren't effective positive reinforcement, which makes them pointless. I certainly hope that you aren't maintaining that people won't be thanked for bad edits ... any experience with our ethnic conflict pages, pseudoscience pages, or fiction pages would render that notion a non-starter.—Kww(talk) 21:34, 4 June 2013 (UTC)[reply]

I think there's a couple of people here and elsewhere who need to realize the difference between listen and obey. If the WMF is not doing exactly as one editor (or even a majority of the editors who speak up) demands, that doesn't mean they're not listening, or they're not taking these arguments into account, or they don't care about us. It just means there are other considerations they also take into account. I'm not saying I always agree with their decisions, or that they do the best possible job in explaining them, but the claim that they don't listen or care is a conclusion that's not supported by the evidence at hand. — HHHIPPO 21:42, 4 June 2013 (UTC)[reply]

"the information is available in cases of abuse, and for the sake of transparency" Available to whom? How? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:59, 4 June 2013 (UTC)[reply]

LoggedKww(talk) 22:15, 4 June 2013 (UTC)[reply]
On a purely technical note, that log is incomplete: one has to hope that the "thanks" are not being given for abusive edits, because you cannot see what edit was the target of the thanks. That's a major hole, as I would certainly want to have a serious discussion with any editor that was thanking other editors for vandalism or personal attacks.—Kww(talk) 22:22, 4 June 2013 (UTC)[reply]
It's precisely the opposite. This section is about the possibility of people gaming the system by using it as a way of indicating consensus. By not listing the pertinent edit, it totally invalidates any attempt to do so. Okeyes (WMF) (talk) 15:31, 5 June 2013 (UTC)[reply]

Maybe this will become Wikipedia's version of karma or 'likes'. πr2 (tc) 22:25, 4 June 2013 (UTC)[reply]

@PiRSquared17: and @Kww: That's presumably exactly the reason that we do NOT have the edit associated with the "thanks" given either publicly on-wiki, or in logs. To prevent negative gamification. I.e. So that "thanks" doesn't get all the baggage of reddit's karma/upvotes and google's +1s and facebook's likes and etc. –Quiddity (talk) 22:50, 4 June 2013 (UTC)[reply]

Why don't we try the "wait and see" approach on all this. The Thank feature is brand new. We don't know how it will be used; we don't know how it will be abused. We don't know if seven-year-olds will use it to gang up on other editors. WMF's intentions seem good enough -- they want to improve the karma around here and promote a more positive and encouraging atmosphere for editors and especially new editors (I think), which WP desperately needs more of. The feature is not perfect, and it will need to be tweaked, reworked or perhaps even junked as time goes on. But right now, the feature just hasn't existed for long enough to know what needs to be fixed and what doesn't. In the meantime, let's not let perfection be the enemy of progress. Brycehughes (talk) 22:43, 4 June 2013 (UTC)[reply]

Please give a specific time frame so I'll know how long I have to wait bring this up again. Also please say how I can tell when I am talking to an employee of the foundation and when to another volunteer editor. I have tried to be a conscientious member of the community, contributing in a positive way and working with others toward consensus, but I see this backchannel as the first small step away from the openness I depend on to give me confidence to contribute. Maybe lots of people are agreeing with Brycehughes right now and thanking him privately instead of posting here. Shall I check the log every few minutes to see? And will this be evident to those reading the discussion at a later date? This uncomfortable feeling in the pit of my stomach can't be progress or good "karma". —Anne Delong (talk) 11:55, 5 June 2013 (UTC)[reply]
An editor speaking with the authority of the WMF will have "(WMF)" in the signature.—Kww(talk) 13:57, 5 June 2013 (UTC)[reply]
Thank you. —Anne Delong (talk) 14:45, 5 June 2013 (UTC)[reply]
My attitude to it would be; bring it up again when there is evidence of this happening. Until then it's an edge case. And I would say that we have had (for many years now) the ability to email people through Wikipedia, the ability to obliterate edits made from the pages they were made on so that no editor can see what's happening....this is the Nth nail ;p. There is no such thing as absolute transparency. Okeyes (WMF) (talk) 15:31, 5 June 2013 (UTC)[reply]
Anne Delong, you might like to read WP:CONEXCEPT. That's the English Wikipedia's official policy on the point: the editorial community controls the encyclopedic content, and the developer community controls the software. This is supposed to be a mutually beneficial relationship, but it's not a matter of "where's the consensus discussion" or "who gave them permission". They're supposed to do their task, even when we have people predictably screaming because somebody just changed something on the website. It's a "tried-and-true axiom of the Web: People always hate when their favorite site is suddenly completely different. A lot of them threaten to quit....I've got news for you: You'll get over it soon enou0gh." Change is hard, and the more time you spend at a given website, the more painful any small change will be for you. Give yourself some time to get used to it. In a couple of months, you'll probably find that this change doesn't matter. (And read up on WP:VisualEditor now, because there are massive changes coming to the English Wikipedia this summer.) WhatamIdoing (talk) 22:32, 5 June 2013 (UTC)[reply]
Thank you for the pointer to WP:CONEXCEPT. It's amazing that I could work in this environment long enough to make 10,000 edits without understanding my limited position. Despite the above patronizing comments, I won't have any trouble with a new editor. I've been dealing with editors all my life; the first one I used was a punch card machine (not very forgiving - no undo function). I guess I knew I was wasting my time. Once X number of hours have been put into a project it will be defended at all costs. Now, just one more thing. How can I tell which changes come from WMF and which from other editors, so I will know when to bite my tongue? —Anne Delong (talk) 01:46, 6 June 2013 (UTC)[reply]
In terms of edits to article content, the "WMF" in the signature or a reference to an OTRS ticket in the edit summary. When it's the arrangement of things on your screen or new things popping up on it, those are generally WMF software changes. Simple changes to text on your screen are usually just a local administrator: while you can't undo them directly, they are subject to consensus. Let me know if you see something that confuses you and I'll try to help you sort it out.—Kww(talk) 14:03, 6 June 2013 (UTC)[reply]
Anne, I once believed it was simple enough, but after the watchlist debacle last year, I've changed my mind. I really don't know how you would always be able to tell who was responsible for a given change. I don't even know how to convince everyone that community-driven changes are actually community-driven, because despite incontrovertible evidence, some of them still seem to believe that even community-initiated, CENT-listed RFCs are just tools of the dev(il)s.
In theory, "styling" is handled locally, but "features" are not; I just don't know that this is always true, or how you would find out which category a borderline feature might fall into without asking or without reading every page in the Wikipedia: namespace. It's unfortunately complicated. WhatamIdoing (talk) 18:40, 6 June 2013 (UTC)[reply]

Thanks feature update

Hi everyone, thank you so much for all your good feedback about the Thanks feature!

We have reviewed all the comments from a variety of channels (this Thanks talk page, the Notifications talk page, the Village Pump and this Bugzilla ticket), and have started to discuss and prioritize feature requests, based on that feedback. To keep this discussion more focused, we will be posting responses and updates on this talk page, and link to it from the other pages.

Here are some of the requests we are now working on, listed in order of priority -- along with a few questions for you to help us focus on the key issues.


I. Thanks link
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. This is our top priority, as it appears that the current placement next to undo is clearly problematic (as pointed out in this post).

To help us solve this issue quickly, we would be grateful if you could answer these questions, so we can pinpoint the problem and its solution more accurately:

  • Q1. How many of you have accidentally clicked on 'thanks' instead of 'undo'? Did this happen only once, or are you doing this often?
  • Q2. Where are you getting confused? Is the diff link fine and the history link problematic? Is it the other way around? Are both a problem?
  • Q3. What solution would best address this issue for you? Could it be solved by adding more space or a divider between the links? or would this require a two-step confirmation process? or an 'unthank' button?

(Keep in mind that adding more space is easy, but adding a second confirmation step requires a bit more development -- while providing an 'unthank' function would be a significant effort, because we would need to introduce a delay function on the back-end to make that possible.)

Your answers will help us confirm the severity of the issue, as well as come up with a better solution. Right now, the proposed solution on this Bugzilla ticket seems promising and could be developed relatively quickly, as proposed by ypnypn9, who suggests that if you click "thank", you get a pop-up saying:

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

What do you think? This solution seems reasonable and practical to us, because it would both clarify what the link means, and provide a confirmation/undo option.


II. Different icon
A number of people have expressed concerns about the use of a heart icon for the Thanks notification, as outlined in this post -- and various alternatives have been proposed by participants. We have passed on these ideas to our design team for review and they are considering their options. This issue is a bit trickier, because we are trying to establish a general visual language that can work across applications, and there is already a precedent for using a heart for expressing gratitude, in the form of the WikiLove tool. We also note that using a heart to show your appreciation is now widely used across many top websites, so it is becoming a best practice as a result. That said, we are definitely looking into this issue and will respond with more concrete recommendations after we've heard back from our designers.


These are the first two issues we're focusing on right now, because they seemed to be the highest priority based on the number of comments we received so far. As more suggestions come in from your usage of the tool, we will continue to look for ways to optimize this feature based on community feedback.


III. First stats
For now, you might be interested in these first statistics about this feature: since we deployed it last Thursday, about 2,161 Thanks notifications have been triggered by over a thousand unique users. This represents an average of about 3% of total notifications events, which is comparable to the percentage of notifications for page reviews or user mentions, as shown on this metrics dashboard.


That's it for this update. We will post another update as soon as we've heard more from you on the questions above -- and had a chance to discuss your recommendations. In the meantime, I would like to express my gratitude to all the folks who gave us positive feedback about this experimental feature. And I love that many of you used the 'Thanks' tool to show your appreciation for our work -- which seemed very appropriate ;o) Fabrice Florin (WMF) (talk) 18:26, 5 June 2013 (UTC)[reply]


Comments

  • The "pop-up confirmation" solution is my preference.
Changing the color might also be useful,
eg on diff pages: Latest revision as of 18:26, 5 June 2013 (edit) (undo) (thank)
eg on history pages: 18:26, 5 June 2013Fabrice Florin (WMF) (talk | contribs)‎ . . (50,586 bytes) (+5,168)‎‎ . . (Thanks feature update: new section) (rollback: 1 edit | undo | thank)
I've almost accidentally clicked "thank" a few times, in both diff pages and history pages, because I'm used to the last bold blue link in that line being "undo". A visual hint would help avoid that, at least for sighted users without colorblindness (possibly a reduced font-size, in addition, for their sake).
Someone with additional buttons (twinkle, admin-buttons, etc) would need to check that the suggested changes don't interfere with the way those tools are currently displayed. HTH. –Quiddity (talk) 19:15, 5 June 2013 (UTC)[reply]
  • Regarding 1: I don't think an undo functionality is necessary, but there needs to be a confirmation step. Don't increase any spacing, history pages are far too crowded already! --Patrick87 (talk) 19:58, 5 June 2013 (UTC)[reply]
  • 1) Mistakenly clicked thanks only once; 2) I was expecting a confirmation; 3) A confirmation and/or an unthank link would resolve the problem. Brycehughes (talk) 20:30, 5 June 2013 (UTC)[reply]
  • 1) Mistakenly thanked the wrong user (While I was trying to de-escalate an issue, I thanked him for a ccomment that was non-flattering) 2) No. 3) Unthank button is the best. I like the thank function, and I'd rather be able to thank people quick enough, and without hassles or anything. Its uncomfortable adjusting to it now, but having to use two clicks for a potentially long time is non helpful. TheOriginalSoni (talk) 21:20, 5 June 2013 (UTC)[reply]
  • I support the idea of a confirmation. I almost clicked 'thanks' rather than 'undo' on a diff page, and that's despite already knowing that misclicks were a problem. As for 'unthank', would it be simpler to unthank if the person hadn't already seen the notification, and if the recipient had already seen it, to generate an error message that says it's too late? I think that most of these misclicks would be undone within seconds, and most of us won't see the notification that quickly. WhatamIdoing (talk) 22:39, 5 June 2013 (UTC)[reply]
    And now I've misclicked on a history page. WhatamIdoing (talk) 22:47, 5 June 2013 (UTC)[reply]
    Unthanking would be difficult, because our preferences allow email notifications for things like "thanks", which would be triggered instantaneously. That's at least partially what Fabrice meant, by having to introduce a timed-delay into the system to cope with unthanking. –Quiddity (talk) 00:16, 6 June 2013 (UTC)[reply]
    But as Technical 13 pointed out on a related Bugzilla ticket, the system could delay the email a minute or two, to give people time to undo it. Ignatzmicetalk 03:40, 6 June 2013 (UTC)[reply]
    That's actually pretty difficult from a backend engineering point of view, unfortunately; it is a possibility we'd discussed. Okeyes (WMF) (talk) 16:29, 6 June 2013 (UTC)[reply]
  • Re 1: A popup does seem like the best option (especially [maybe] if there was an option in the prefs to turn it off once people get used to whatever the new placement is). But that depends on how, exactly-it's implemented—some people will have popups disabled, and some will have JavaScript off. I dunno if there's any way to get popups in HTML... Ignatzmicetalk 03:40, 6 June 2013 (UTC)[reply]
    If they've got JS disabled then they're not really going to be able to use Echo anyway. Okeyes (WMF) (talk) 16:29, 6 June 2013 (UTC)[reply]
    Actually, Echo is about usable without JavaScript now. My main bug bear there is the loss of the "you have new messages" orange bar. I think you really mean we're not able to use Thanks. I can receive thanks without JavaScript, but am unable to send it unless I resort to the API. – PartTimeGnome (talk | contribs) 20:12, 6 June 2013 (UTC)[reply]
    Ooh, it's got more workable? Excellent :). Okeyes (WMF) (talk) 20:22, 6 June 2013 (UTC)[reply]
  • I haven't mis-thanked, but I have been being very careful. I have been mis-thanked once. I don't think re-positioning is necessary, or extra space, provided a mis-click on "Thank" is not final. An "Are you sure?" or "Confirm?" pop-up is my preferred answer - seems to me more natural, and consistent with many other processes that require confirmation; also, I guess, easier to implement than an "Unthank". As I said on the other thread, I seriously dislike the pink heart, and that would be enough to stop me using the feature (which would be a pity). I guess there are two cultural divides here, young/old and US/Brit, and I am on the un-gushy side of both. Something based on a tick, or a smiley? JohnCD (talk) 16:51, 6 June 2013 (UTC)[reply]
  • (1) Yes, definitely the confirmation popup. It both clarifies what the link means, and provides a confirmation/undo option. Even after using (thank), this undo/thank combination confused me into believing I could undo the thank by (undo). ;-) The thank confirmation popup would be expected behaviour. In the diff I think (thank) should be more prominent. Users should be encouraged to send thanks from the diff, because they can see there what they are thanking for ;-) (2) Please don't use the pink heart icon. It's a bit too much and the wrong connotation. The Wikilove icon is widely disliked on german Wikipedia already, although WikiLove was never activated. The removal of the OBOD was noted critically, also the Facebook-style-notifications (and also the many WMF tracking cookies that mysteriously appeared in the last months on de-wiki). Please spare us at least the outcry about the pink bikeshed heart... ;-) Maybe consult the internationalization team about symbols? The smiley seems popular, the flower symbol is good too. --Atlasowa (talk) 18:36, 6 June 2013 (UTC)[reply]
Greetings Fabrice and no problem for linking that way. I don't mind at all in fact I think that is the only good thing in the notifications change that is useful. But that's just me. As for the three questions I don't really have a strong opinion about the thanks function. It doesn't show up under my watchlist and I generally don't go to the trouble of digging through users contributions so I don't think I'll misclick too often. I do think its still possible though given the close proximity to the undo button. I don't really like the heart icon either but its already on the WikiLove app so we should keep things consistent IMO. If we change it in one location we should probably change it in both. I don't really have an opinion about the fixes either because as I mentioned I don't really think its needed and if it is we should just link it through the WikiLove app (which I don't really think is a big necessity either BTW). I hate to sound like a grump here but I still think that too much time and effort is being spent on nice to have stuff, creating and fixing things we don't need and didn't ask for that really don't fix or improve anything. I also find it annoying that there are so many other requests and improvements that have been asked for (some for years) and are still pending because time is being spent on stuff like this. Anyway, that's my 2 cents. Happy editing. Kumioko (talk) 18:42, 6 June 2013 (UTC)[reply]
I'd even prefer a two click process to prevent (deliberate or undeliberate) "thank" flodding. When thanking authors becomes an "on-the-fly" task, what is it worth anymore? If I want tho thank an author, it probably should be worth clicking to times to me, shouldn't it? --Patrick87 (talk) 20:35, 6 June 2013 (UTC)[reply]
  • Okay Fabrice, since you invited me by name I'll answer. I'm not sure how helpful you'll find this, since my issues are a bit different from those of most...

    1: I have never misclicked the "thank" link. The one time I clicked it was intentional. However, I have not had occasion to undo anything since the feature was introduced; I don't know if I would have misclicked had I been intending to undo anything.

    2: I was mildly confused when nothing happened upon clicking the link, though I quickly realised why. This was on a diff page, though I would have been equally confused on a history page.

    3: The ideal solution in my case would be to allow thanks to work without JavaScript. Rather than being a broken link, "thank" should target something like Special:Thanks/REVISIONID, which would ask me to confirm my thanks. Alternatively, simply hide the link if JS is disabled, to avoid page clutter and user confusion (this isn't a particularly important feature for me). I've logged bug 49161 for this.

    Of course, if I were able to use thanks I would then worry about accidental misclicks. My solution for non-JS users above includes a confirmation page that solves the problem. For JS users, a small confirmation pop-up could be displayed, allowing them to remain on the history or diff page. I don't think extra spacing or dividers would help, and would further clutter the page. I appreciate that an "undo thanks" feature would be Hard to implement; I don't think it reasonable to ask the developers to go to that much effort when a much easier solution (the confirmation step) is available. – PartTimeGnome (talk | contribs) 21:02, 6 June 2013 (UTC)[reply]

  • I'll comment in the morning. I've got a 21 month old that is taking alll of my focus right now... Technical 13 (talk) 23:30, 6 June 2013 (UTC)[reply]
    • She fell asleep and I have a moment. I rarely use undo on the history page, so I haven't mis-clicked there. I occasionally will use it on diff pages, but haven't mis-clicked yet due to the fact that I've had no thank links as i've been working on User:Technical 13/Scripts/NoThanks.js (edit | talk | history | links | watch | logs) for other editors that just want to disable the thanks feature but didn't trust clicking the "exclude me from feature experiments" checkbox for fear of missing another experiment they may be interested in. Still not quite done with that script, I can't figure out why it seems to disable the ability for the page to know which li is selected... Anyways...
    • I've been thinking long and hard about this and personally if I had to click twice every time I wanted to thank someone, I wouldn't use the feature (I'd actually be an intensional user of my script). I think that despite it being a little more work, adding a short delay to the actual sending of the thank giving an opportunity to "un-thank" or "de-thank" is the way to go. I would bet that the statistical data would show that a lot less people accidentally click on it than intentionally click on it and forcing all of the intentional uses to have to click twice is an inconvenience in my opinion and discourages use.
    • As for the icon used... I've suggested a few things, and they have all had there flaws... I actually just had another idea today that I was busy with playing money with my daughter and thought hey, what if the icon was the localized symbol for money for the user? I'm sure that this will be shot down as difficult to implement, but I think it would be clear and cool if in the US users saw "$" or "¢" and in the UK or Europe "₤" (I think that is the Euro sign, if not, feel free to change it) and in China or Japan they would see the Yen or in France the symbol for the Frank... Not sure exactly what the specs for the icons are, but perhaps an animated gif or png that cycles through all of the symbols at a rate of one every other second would be cool... Otherwise it would be hard to know which symbol is right for the viewer (would have to guess based on timezone/offset probably).
    • Feature improvement idea... I would like to see the thank link also added to my Watchlist/Recent changes... That is where I would be most likely to use it a lot.
    • I'll be sure to come back and add some more thoughts and ideas later, time for bed for me as well. Technical 13 (talk) 01:34, 7 June 2013 (UTC)[reply]
      FYI, France doesn't use the franc anymore, but the UK still uses the pound sterling. France uses the euro. The pound sign = £/₤, euro = €. πr2 (tc) 14:33, 7 June 2013 (UTC)[reply]
      Thanks for that currency lesson... What's everyone think of this idea? "currency symbols" == good "thanks" icon? Technical 13 (talk) 14:52, 7 June 2013 (UTC)[reply]
      We'd have to build up a global, accurate list of currency icons and automatically geolocate every user; this sounds non-trivial. Okeyes (WMF) (talk) 17:05, 7 June 2013 (UTC)[reply]
      I'm aware of that and there would likely be some privacy concerns which is why I modified my suggestion to just be "an animated gif or png that cycles through all of the symbols at a rate of one every other second". Technical 13 (talk) 17:14, 7 June 2013 (UTC)[reply]
      Given the number of currencies in the world and the shortness of the time the image would be displayed, it is improbable that any user would reliably get to see their currency. It's also probable they'd be unfamiliar with a lot of them. I can say with some certainty that we will never solve for a UI problem by introducing an animated gif. It's much like Regular Expressions. Okeyes (WMF) (talk) 17:29, 7 June 2013 (UTC)[reply]
  • Q1: I have accidentally "thanked" someone several times in the past few days. (Or at least I think I have; I have no idea what this looks like to the recipient.) Q2: I was not "confused". I was using a cell phone, and the combination of small links and big fingers makes it all too easy to activate a link you never meant to click on. Q3: Add a "verify" or "oops" step. There should always be some way to either verify or undo whatever you do. One-click-and-it-goes-live buttons are a tool of the devil. That's why I asked to have my rollback right deactivated; I was tired of having to undo and apologize for accidental rollbacks. Bottom line, my opinion: either add a "verify" step, or give us an option to disable the damn thing. Thanks. (BTW about those 2,161 uses of the Thanks button - that would be more meaningful if you knew how many of them were on purpose vs. accidental.) --MelanieN (talk) 12:56, 7 June 2013 (UTC)[reply]
  • Q1 & Q2: I've only done this once: Here is the scene of the mishap: [1]. I follow the experimental edit log of 28bot and pick up what articles need attention there. I have to click on the history though to see the diff to discern what needs to be mended. I just knew this involved 'example images' (the bot uses a key code for errors). So when I got to the diff it was a simple revert of that and a botched image file, so I just merrily clicked on what was always "undo". Never in my wildest dreams did I ever expect it to have evolved into 'thank'! I surely just wished to be able to undo the thanks!! However, I am a fast learner (fool me once...), so now I know what's where however: for Q3: a simple <thank, (ok), (cancel) > routine would be lovely to give a gentle hint of do I really want to thank... It was painful only because I still had to revert and then place a gentle warning on the user page (Vandalism 0), which vexed me and surely confused the user. ツ Thanks! Fylbecatulous talk 20:10, 7 June 2013 (UTC)[reply]

Recap

Hi folks, thanks for all your constructive responses. It's such a pleasure to collaborate productively with you guys to find a good solution to this 'Thanks link' issue together :) ...

To get a better sense of where our 'impromptu workgroup' stands on this issue, I compiled your responses on this spreadsheet. Here's a quick summary.

Q1. How often do you misclick?
Your responses suggest that accidental misclicking doesn't happen often for most of you:
a) Never 38%
b) Only a few times 38%
c) Often 23%
d) All the time 0%

Q2. Do you misclick more on the diff or history page?
There are too few responses to this question to suggest that misclicking happens more on one page than the other. For now, we'll assume the problem is the same on both pages.

Q3. Which solution do you recommend?
Your favorite solutions seem to be either the confirmation or undo options:
a) add a space or visual cue (e.g. colored link) 0%
b) add a confirmation step (e.g. pop-up) 54%
c) add an 'undo' option (e.g. 'unthank', countdown) 46%

Key findings
Here are my main take-aways from this feedback:

  • about a fourth of respondents report misclicking often
  • this seems serious enough to require a special solution
  • adding more space or a visual cue doesn't seem sufficient
  • over half of respondents prefer the confirmation panel option
  • nearly half of respondents prefer the undo panel option
  • some users think the confirmation option defeats the purpose of a one-click feature
  • some users suggest a short delay for undo (a few folks have proposed a quick countdown)
  • an undo option lets us optimize the UI for the primary use case (people who don't misclick)

We'll discuss our options with Kaldari, Vibha Bamba and our project team on Monday. Building a delay on the back-end is likely to require several days of development, which would slow down our work on other important goals for the Notifications project. Though it may be easier to build a delay on the front-end, as several people have proposed (if we don't mind that the thanks doesn't get sent if they close the window or hit the 'back' button). The two-step confirmation is easiest from a development standpoint, but it introduces an extra click (which seems to unfairly penalize the majority of users who don't misclick).

So a possible solution might be to simply show a quick countdown after you click on the thanks link, giving you 10 seconds or so to cancel, as so:

Quiddity (talk | contribs)‎ . . (50,586 bytes) (+5,168)‎‎ . . (Thanks update) (undo | Sending thanks in 10 seconds - Cancel)

This countdown would be client-side, not server-side, and would start at 10 seconds, then 9, 8, 7, etc. -- ending up with the same 'thanked' message we now display. This idea of a short countdown was suggested by several community and team members, such as WhatamIdoing, Technical 13 and Jorm, to name but a few. It seems promising, if it could be done reliably on the front-end, without requiring special back-end functionality or delaying our other features. What do you think?

Either way, we'll get one of these solutions developed this week (e.g.: the confirmation popup or the short countdown, if feasible). But please understand that it may not be a perfect solution, if we want to meet all our other goals this month. Our approach with this experimental feature has been to keep it barebones initially, and incrementally improve it with small tweaks, based on community feedback, rather than try to figure it out all at once.

For that reason, we would like to first solve the Thanks link issue this week, then revisit the discussion about icons the following week, since it seems less urgent. We hope this approach works for you.

The good news is that more and more people are starting to use these Thanks notifications (which are now as frequent as Page Review notifications -- with 3,336 thanks sent in our first week). Also, more people are coming out to show their appreciation on this talk page -- and our team members are getting quite a few thanks notifications from you … which of course is music to our ears  :)

To me, this small experiment is a great example of the Wikipedia movement at its best, with all stakeholders working together to incrementally improve key features together, setting aside our diverse backgrounds and viewpoints to create a friendlier and more collaborative environment for all users. Thank you all for making this is possible! Fabrice Florin (WMF) (talk) 19:15, 8 June 2013 (UTC)[reply]

  • Regarding the countdown: I think it's a really bad idea. As far as I understand you have to wait 10 seconds before you can close the window. At least for me (and I'm sure for many others, too) giving thanks on a talk page and then closing the windows would be a typical workflow. I open nearly every new page in a new tab, and close that tab as soon as my work is done there. I'm quite sure such a timeout feature will produce a new wave of unsatisfied editors
Furthermore I don't think that the people who "think the confirmation option defeats the purpose of a one-click feature" will be happy with a countdown either. I assume the countdown (instead of a simple confirmation step) is considered especially to make those people happy? The reason is simple: Those who do not have the time to click two times, will surely not have the time to wait 10 seconds.
Eventually I think a countdown will make the whole process very hard to understand, especially for beginners. Questions that will arise are: When is thanks given? As soon as I click the button? But why is there some countdown? Do I have to confirm before the countdown ends? What if I leave the page before countdown ends? Will my thanks simply be discarded?
So I think the only reasonable solution is the confirmation step, since (as you wrote) an undo option is not a real option since it would just need to much resources for only a small gain. --Patrick87 (talk) 19:57, 8 June 2013 (UTC)[reply]
  • Patrick87, Fabrice mentioned it happening on the backend, which means to me that you will still be able to close the page right after clicking and move on and it will send right away. If you misclick, you will have 10 seconds to cancel unless you close the tab/page. Technical 13 (talk) 20:06, 8 June 2013 (UTC)[reply]
  • Well, Fabrice said "This countdown would be client-side, not server-side". So the question is: Is thanks sent to the backend before or only after the countdown? I'm sure Fabrice will update us on this with the definite answer. --Patrick87 (talk) 20:17, 8 June 2013 (UTC)[reply]
  • Well, I am not... Is thanks sent to the server the second I click the link and if I close the page it is saved nonetheless? Or is it sent after 10 seconds if I do not click cancel? I think it is confusing (but maybe I'm just to deep into internals myself). --Patrick87 (talk) 20:12, 8 June 2013 (UTC)[reply]
  • One question regarding the potential coonfirmation step: Will you implement it via a second page you have to visit (similar to when you use undo, were you reach a new page, too) or will it be handled with JavaScript without the need to leave the page (which would be the preferable option, but probably needs a non-JavaScript fallback). --Patrick87 (talk) 19:57, 8 June 2013 (UTC)[reply]
  • If the 10-second delay were truly annoying to some users, then perhaps "Sending thanks in 10 seconds - Cancel - Send immediately" would solve that problem. WhatamIdoing (talk) 20:09, 8 June 2013 (UTC)[reply]
  • Then we have replaced a simple two-click solution, taking maybe a second and familiar from many existing implementations, with a one-click-plus-distracting-ten-second-countdown-which-can-be-got-rid-of-by-a-second-click solution, which is more difficult to implement and is preferred by less than half the responders. I absolutely agree with Patrick87. JohnCD (talk) 21:16, 8 June 2013 (UTC)[reply]
  • I agree. I think this is not expected behaviour and confusing (confirmation countdown for thanks...?). Let's compare with existing implementations:
I edit and click "save" -> I get a post-edit confirmation, floating for two seconds [2][3] (1 click + confirmation popup)
I click "undo" -> I get the diff with the undone version, to confirm and comment. (2 clicks)
I click "rollback" -> I get the confirmation of successful rollback [4] (1 click + confirmation page)
I click on the bookmark star -> i get a confirmation popup for a few seconds (1 click + confirmation popup)
I click on the WikiLovwe heart -> i get a dialog box that i can dismiss by clicking X or select options (2 clicks)
Shouldn't this "thank"ing be consistent with other behaviour on-site? I don't really see the benefit of the countdown-confirmation. It's a compromise between a 1-click and a 2-click solution? How many "thanks" do we expect to lose by asking users for a second click, -30%, -10%? Any experiences/ research? --Atlasowa (talk) 23:33, 8 June 2013 (UTC)[reply]

Thanks confirmation feature added

Per the feedback we received on the problems with the Thank links, we've added a confirmation step: https://gerrit.wikimedia.org/r/#/c/67591/. The code still needs to be reviewed and merged, but it should go out some time in the next few weeks. Kaldari (talk) 04:34, 9 June 2013 (UTC)[reply]

I love this feature.

Without butting into this discussion too much, I would just like to point out a wonderful effect of this feature. WikiGnomes, who make a lot of small, by themselves unremarkable edits usually have very little communication. This feature makes it very easy for people to thank WikiGnomes for the wonderful work that they do. It completely removes the (relative) hassle of posting a talk page message. Thank you, WMF, for this cool feature. TheOneSean [ U | T | C ] 21:42, 6 June 2013 (UTC)[reply]

I'll add here as well. I got thanked yesterday by an editor who had just created an article. I happened to mark it reviewed with Page Curation and then added some complicated categories for the user... and I later received the little heart of appreciation. I have to admit this is nothing anyone would come to my talk page over or paste a Barnstar for; so it did give me the warm fuzzies feeling to have been noticed. So after all, I do believe this is a keeper. Fylbecatulous talk 20:30, 7 June 2013 (UTC)[reply]

Thanks for this feature

I used to spend most of my free time contributing to Wikipedia, but now I spend most of my free time contributing to StackExchange sites. On Wikipedia, it seems the only time anyone ever communicates with you is to complain about something you did wrong or to start an argument. All the contributions you make just go out into the void and you don't get much positive feedback about them. Are people reading them and benefiting from your work? Does anyone care? Is it all a waste of time? Then the arguments start and it leads to frustration and burn-out.

On StackExchange, people upvote your answers if they are correct and helpful, and downvote them if they're wrong or need work. You get far more upvotes than downvotes, accruing "reputation points" that, while ultimately useless, serve as a constant reminder that your contributions are being read and appreciated by lots of other people, which motivates you to keep contributing.

I hope this feature will help make editing Wikipedia a more positive experience, reminding users their work is appreciated. — Omegatron (talk) 04:37, 8 June 2013 (UTC)[reply]

👍 LikeEncMstr (talk) 18:03, 9 June 2013 (UTC)[reply]

Change the i-love-you heart to something more neutral

I will never use what to me is an I-love-you icon to express my thanks to anyone on Wikipedia. Yet, I do think the idea of the feature is good, allowing a "small form thanks" for edits that you would not otherwise express gratitude for through a dedicated talk page message, cookie or barnstar. A message from me, no matter how much it is automated or represents a symbol for the feature itself rather than making up a part of the message (which others *might* understand to be the case), is not going to have something attached delivering a meaning that I would not express myself or intend to convey. With the pink heart icon attached, the feature is closed to me.--Fuhghettaboutit (talk) 15:17, 9 June 2013 (UTC)[reply]

@Fuhghettaboutit:, do you have a suggestion for what to replace the heart with? It has been agreed at this point the heart is not desired or preferred, and the development team is open to replacement suggestions. Technical 13 (talk) 15:31, 9 June 2013 (UTC)[reply]
A simple smiley face would be a neutral and universal symbol. No wink, no big grin, just a smile which would say "You did something that pleased me", the purpose of a "Thanks". Dennis Brown / / © / @ 15:46, 9 June 2013 (UTC)[reply]
Good idea. A simple smiley face has no unwanted overtones; seems perfect.--Fuhghettaboutit (talk) 16:19, 9 June 2013 (UTC)[reply]
True—however, it is also the copyright of Nicolas Loufrani and Wal-mart, both of whom are famously zealous when it comes to protecting their intellectual property rights and would doubtless love a chunk of the Wikimedia Foundation's pie. – iridescent 18:04, 9 June 2013 (UTC)[reply]
(ec) Walmart ruined the smiley face for me decades ago. How about a thumb up, an OK, +1, or an "agree"? —EncMstr (talk) 18:06, 9 June 2013 (UTC)[reply]
I thought Forrest Gump invented it during a jog one day. ;-) As to whether it is copyrighted and this would provide a bar to its use, I would prefer more evidence that this posed a problem, as the smiley face is ubiquitous in every aspect of our global culture. Dennis Brown / / © / @ 18:17, 9 June 2013 (UTC)[reply]
Thumb up and +1 are even worse I assume. If we want this feature we shouldn't copy from Facebook or Google. OK and agree don't sound very honorable at all. I think the Smiley is not a valid trademark anyway after reading Smiley, so I thin we should be fine. --Patrick87 (talk) 18:24, 9 June 2013 (UTC)[reply]
If it's not copyright, the people who pay The Smiley Company $167 million per year in licensing fees are probably feeling pretty foolish right now. It's ubiquitous because a hell of a lot of ubiquitous companies like Amazon licence it, not because it's some kind of community property. (This, BTW, is why you can't see smileys on phones running open-source software such as Android.) Whether or not something is a trademark has no impact on its copyright status. – iridescent 18:27, 9 June 2013 (UTC)[reply]
Then the Smiley article is wrong. It's written there that "the judge declared that the smiley face was not a "distinctive" mark, and therefore could not be trademarked by anyone". --Patrick87 (talk) 18:33, 9 June 2013 (UTC)[reply]

Thanks for multiple edits

Sometimes I'd like to express thanks for a group of edits — for example, when none of them is individually a big deal, but together they're really helpful. Any chance that we could get the chance to issue a single Thanks feature notice for a group of edits? I'm not clear how such a thing would be accomplished from a technical point of view. Nyttend (talk) 19:47, 9 June 2013 (UTC)[reply]