Talk:Community Tech/Who Wrote That tool

Mockup

Hi! I like the proposed mookup; it's simple and easy to understand. The only thing I don't like is «On a given page, the user can click a button to enter the "Who Wrote That" mode»; this will be the first button on a content page (at least that I cas see now). Instead of this, in order of preferences:

1. a link in the "Tool" sidebar
2. a button on the "History" of the page
3. a tab at the top of page (near "Edit", "History", "Move", ...)

--β₁₆ - (talk) 08:50, 21 February 2019 (UTC)

@Beta16:, thanks for your feedback. We still haven't decided what the best way for activating the feature will be. There are several options, as you mentioned. A link under the "Tools" section is indeed our top choice right now (see mock design). I didn't want to distract from the actual feature so I did not post that mock here. Once I get feedback about the key features, then I will gather feedback from our designers and engineers about the best placement for that and share on the project page. Thank you. -- NKohli (WMF) (talk) 21:10, 21 February 2019 (UTC)

Pretty much as aboive - this is actually a lot better than I was expecting, given how clumsy the old tool was. JzG (talk) 23:42, 21 February 2019 (UTC)

I agree with both of the above. Also, please keep in mind that JavaScripts and CSS can operate on "objects" in the left and top toolbars, to arrange them as people want, so this is the most flexible approach. Anyway, I want to be clear that I agree also with "this is actually a lot better than I was expecting", not just that I agree with ideas on how to implement it. Good work!  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  03:52, 22 February 2019 (UTC)

Like the new name. Mockup looks reasonably intuitive. A dropdown option in the "view history" tab seems a good place to activate from. Information in popup looks useful, but it is not clear whether the highlighted text is from the diff (all the changes made in that edit) or only the surviving text from that edit.

The amount of information looks OK. If you have the Username, links to talk and contributions should be trivial. If you have the diff, the timestamp should be trivial. Without the username and diff the whole thing seems pointless, so I don't see how less information is really an option. Also dont see what additional information might be useful, but accept that you might find some.

Would this tool work on historical versions, or only on latest version? Reason is that if somene had corrected a spelling error in the selected word, the corrector of the spelling error is not generally the user one would be looking for. · · · Peter (Southwood) ^(talk): 04:54, 22 February 2019 (UTC)

@Pbsouthwood: The idea is that we highlight all the text by that same user in the article. The darker text is from the edit which added the specific word the user clicked on. The lighter text is from other edits by the same user. About the latest versus past revisions, I am not sure I understand the reasoning. How would one find out the spelling error if it was already fixed? Do patrollers normally go to old revisions to find problems which have been fixed in the latest revision? I am not familiar with their workflow so understanding this would be helpful. Thank you. -- NKohli (WMF) (talk) 17:31, 25 February 2019 (UTC)

Suppose editor A adds some content that I want to check up on, but misspells the word I want to check. Editor B comes along and fixes the spelling error berore I look for who wrote the contentious word. Do I get only the word that editor B corrected, or can I go back to the version before the correction and find out who put in that word and what else they wrote? Cheers, · · · Peter (Southwood) ^(talk): 19:50, 25 February 2019 (UTC)

@Pbsouthwood: Ah, okay. My understanding of the API is that it doesn't let us find the history of a specific word but it does give us something called a "conflict score" which can tell us if a word has been edited by multiple people. I will look into whether it will be able to give us the info we are seeking. -- NKohli (WMF) (talk) 23:26, 25 February 2019 (UTC)

Language and time

Hello, will the tool be available only in English, or some work can be done to provide other interfaces?

I see time in UTC, for me it would be better to use my local time. Is is possible? --Dalka (talk) 05:22, 22 February 2019 (UTC)

I assume the tool will work with text strings. The language should not make any difference, and the user-interface should be trivial to translate, so I would be surprised if it is not made available in any/all left to right languages. For right to left languages I do not know enough to comment. Local time setting should also be a minor tweak. Getting the tool to do what it says in the specification is the main job. · · · Peter (Southwood) ^(talk): 09:01, 22 February 2019 (UTC)

Cool tool! Can't wait till it's available on as many wikis as technically possible. @Peter S: why it would only work on LTR-languages? If designed, developed & tested well enough there should be not much (if any) difference in working for all supported languages. Klaas `Z4␟` V:  11:29, 22 February 2019 (UTC)

If you read what I said you will see that I have no idea if RtL languages would be a problem or not, so specifically excluding them from my opinions. Cheers, · · · Peter (Southwood) ^(talk): 12:28, 22 February 2019 (UTC)

@Dalka, Pbsouthwood, and KlassZ4usV: Hello. The tool will rely on an external API service and the wikis we can make it available on will depend on that. Currently, the API only supports five projects and we are in conversation to expand it to be available on other projects. This will be a gradual process and we will be reaching out to wikis to gauge interest over time. As for the interface language itself, there are a few different possibilities. I will be updating the project page as we talk about the project in the team and the details become clearer. -- NKohli (WMF) (talk) 00:26, 23 February 2019 (UTC)

@NKohli (WMF):, Thanks for clearing that up. Are there any other known limitations/constraints that might be useful to make clear at this point? Cheers, · · · Peter (Southwood) ^(talk): 07:13, 23 February 2019 (UTC)

@Pbsouthwood: I believe there are some other technical limitations that will surface as we narrow down on our implementation approach on this project. I will be sure to flag them as they come up. -- NKohli (WMF) (talk) 17:34, 25 February 2019 (UTC)

That usually happens. So nothing that is known that you think we should know? · · · Peter (Southwood) ^(talk): 19:54, 25 February 2019 (UTC)

@Pbsouthwood: I can't think of anything else right now. Not a lot of details about the project are known or well understood at the moment. -- NKohli (WMF) (talk) 23:27, 25 February 2019 (UTC)

Search "Who Deleted That"

Is it possible, having an old revision, find who deleted a quote - between that and actual revisions? --Dalka (talk) 11:02, 24 February 2019 (UTC)

@Dalka: My understanding from the existing api is that it does not allow look up for deleted text. This might change, as we talk with the API maintainers. I will keep you posted. Thanks Dalka. -- NKohli (WMF) (talk) 17:36, 25 February 2019 (UTC)

Feedback

• When I look at edits on my watchlists the time of the edits is shown in my local time. I see no reason to show the UTC time in the blame tool.
• It's not immediately clear whether clicking talk brings you to the talk page of the user in question or whether it brings you to the talk page of the edit. I would prefer the text in the popup to be "Foo(talk|contribs‎) created the edit on 08:50, 15 February 2019. Show diff"
• In cases where the edit in question was reviewed I would want to see that information "Alice(talk|contribs‎) created the edit on 08:50, 15 February 2019. Bob(talk|contribs‎) reviewed the edit on 11:50, 15 February 2019. Show diff" (For Wikis like dewiki that have approval, that information should be shown analogous by replacing reviewed with approved.
• I don't think that the button/link should be placed on a regular page. I would add the button in the edit mode of the page. ChristianKl ❪✉❫ 15:13, 3 March 2019 (UTC)

@ChristianKl: Thanks for the feedback! Replies below:

• I will look into showing the local time. We put UTC in the mock because I am not fully certain what the API returns to us. Hopefully it is not a lot of work to offer the local time.
• Good point about clarifying the text to indicate it will take you to the user talk page. I will relay that to the designer.
• Showing review status for an edit is going to be challenging, to say the least. That information is not stored in a way that is easily accessible by this tool. In addition, pulling that data will make this tool slower - i.e. the popup will take longer to load. I'm afraid it's not straightforward include that information.
• About placing the button on the edit mode of the page - do you mean that the popups should be shown when a user clicks on a word in the VE/standard editor? Note that in the editor there are already tools like syntax highlighting that "take over" the wikitext and to add one more JS tool to the mix there will be problematic.

Thanks again. This is very helpful. -- NKohli (WMF) (talk) 20:42, 6 March 2019 (UTC)

I don't get why it's complicated to get the review data. I would expect there to be a database that can be queried with the edit-id and that then returns the data. Would that take longer then say 50ms? I think it's beneficial to show who reviewed an edit given that a person should be partly responsible for the content they reviewed.

I would put a button in the edit-mode to toggle blame mode being activated/deactivated. The benefit would be that it doesn't add complexity to the page that displays articles. ChristianKl ❪✉❫ 10:02, 8 March 2019 (UTC)

ChristianKl The complication with review data is that it's only stored for recent-changes so there won't be data for revisions older than 30 days. I talked with other people on the team and their opinion is that different wikis also have different workflows around revision patrolling. Customizing this to work for specific projects will be a very big task.

About putting the button in edit mode - do you imagine the text highlighting happening inside the editor when a user wants to see who added a piece of text? Do you think that will interfere with syntax highlighting?

Thanks. -- NKohli (WMF) (talk) 19:07, 14 March 2019 (UTC)

API

Hope there will be an API interface so bots can access this information. They currently search revision by revision, but it is not easy and expensive. A hook to this tool would be fantastic. Either way looks really great and wish you the best of luck. -- GreenC (talk) 15:52, 9 March 2019 (UTC)

@GreenC: The way this tool will work is that it will utilise existing WikiWho APIs. This is a third-party API maintained by the GESIS – Leibniz Institute for the Social Sciences. The APIs are freely available for everyone to use so bots can already access this information if they want to. -- NKohli (WMF) (talk) 19:11, 14 March 2019 (UTC)

More feedback

Hi. I like the mockup. I look forward to a working tool.

I also wonder how "what's wrong with existing solutions" is still an "open question". To the best of my knowledge there are no working existing solutions. (There were, in the past.) So, are you actually still wondering what's wrong with existing solutions, or is the "open questions" section just out of date and in need of editing? Ijon (talk) 15:00, 18 March 2019 (UTC)

@Ijon: Hello. It's not an open question anymore. I didn't get around to updating that section yet, like you guessed. To my knowledge, there are a couple of solutions that currently work to some extent including WikiBlame and WikiWho/WhoColor scripts. We will be building this project off of the latter service. -- NKohli (WMF) (talk) 20:11, 18 March 2019 (UTC)

Great, thanks! (WikiBlame did not work at all, when I last tried it, about half a year ago.) Didn't know about WikiWho. Ijon (talk) 20:20, 18 March 2019 (UTC)

See also for reference; [[:de:Benutzer:Atlasowa/edit history visualization. I especially like and use de:Benutzer:Atlasowa/edit_history_visualization#Schnark_artikel-statistik:

• de:Benutzer:Schnark/js/artikel-statistik

Schnark artikel-statistik zu Artikel Inversor von Peaucellier, ältere Version des Skripts)

Hope this helps, NKohli (WMF). Would love to have this in default wikipedia! --Atlasowa (talk) 21:26, 29 March 2019 (UTC)

That is helpful. Thanks, Atlasowa! -- NKohli (WMF) (talk) 00:39, 30 March 2019 (UTC)

Feedback - Alsee

Multiple people have mentioned time. In order to match timestamps from history and elsewhere you need the time based on Preferences/Appearance/Time_offset setting. I'd presume the API gives you that automatically.

Your rough mockup looks like it's based on the article-read view. I'd also like to be able to search from the wikitext editor. There's a lot of content in an article that isn't accessible from read-view. In fact earlier today I was manually hunting down who added __NOSECTIONEDIT__ - that text isn't visible anywhere except wikitext view. Alsee (talk) 15:14, 21 April 2019 (UTC)

@Alsee: Sorry for the delayed reply. While this feature will only work on the article page (time constraints), I know that MusikAnimal has plans to make a version for the editor that would work for your use case! -- NKohli (WMF) (talk) 22:40, 19 June 2019 (UTC)

Case sensitive?

Will it be possible to toggle between case sensitive or not? Thanks in advance, Ottawahitech (talk) 15:26, 9 May 2019 (UTC)

@Ottawahitech: It will work by clicking on the text on the page so it doesn't matter whether it is case sensitive or not. :) -- NKohli (WMF) (talk) 22:38, 19 June 2019 (UTC)

Help us test the prototype

Hey 👋🏽 I am the designer for the Who Wrote That tool, and I've been working on a prototype based on the wireframes and the feedback we've received for it. We'll be doing a round of usability testing using these prototypes and we'd would love to get your feedback on it.

We'll be using usertesting.com to get structured feedback and reactions on the prototype. We'll also be posting the prototype here for open feedback. If you're interested in participating in the usability test (it would be really helpful for us if you do), you can leave your email address using this form. We'll use it only to invite you to the usertesting.com test. Thanks! --PSaxena (WMF) (talk) 10:49, 22 May 2019 (UTC)

Looking for feedback

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech: Pinging everyone who has participated on this page in the past. My apologies if I missed anyone. I recently posted a link to the interactive prototype we have for this tool on the project page. To activate it, follow the pop-up box and click on the Who wrote that link under the Tools menu in the sidebar. Then either click on the word Henry (middle of second paragraph) or Mother (last line of second paragraph) to see how it will work. In implementation, clicking on any word will show you authorship information, but for the mockup we couldn't do it for every word. The prototype is only to give you an idea for how it will work. There is definitely scope for improvement. Note that the tool will be enabled as a browser extension. Looking forward to hear your feedback on the prototype and activation/deactivation process for the tool. Thank you. -- NKohli (WMF) (talk) 22:48, 19 June 2019 (UTC)

• Works for me. Easy to initiate, easy to understand, functional. If it highlights the block of text in orange, what does clicking on the word do that is already visible? -- GreenC (talk) 01:18, 20 June 2019 (UTC)
• I have a few fewback items:
  • The blue bar should not block access to the History, View_source, and other links. In particular I might want to right-click one of those links to open in another tab, to better investigate and understand the situation.
  • Having the date (instead of the usual timestamp) in the popups immediately struck me as odd. Having the standardized timestamp everywhere is a very familiar visual pattern for editors. Just showing date is shorter and in most cases it would be fine, however for example if I am working from the History page in another tab then I need the full timestamp to easily locate that edit in the history sequence. There could be a hundred edits on that date, with fourty randomly intermingled edits by the named person.
  • The popup doesn't feel complete. I compared the popup info to the pattern of info&links appearing on a row of the History page, as well as the pattern of info&links appearing at the top of a diff:
    • The username on the popup should follow the standard pattern: Name (talk | contribs). This is the familiar pattern, and the contribs link is particually significant for IP edits.
    • Both other locations I looked at include the edit summary. Adding edit summary to the popup seems reasonable. It's probably not important in most cases, but sometimes it might add helpful context when hover-scanning parts of the page.
    • The Undo and Thank links could theoretically be included on the popup and it might even seem tempting to add them, however I would suggest those links stay off the popup. At this point the user sees an incomplete and possibly misleading view of the edit they would be thanking or undoing. I think it makes more sense to access those actions from the diff link, where the entire edit is displayed in the proper context.
  • I'm not sure if there is difficulty with the available tools, but searching page-source is a very relevant use case. (Who added or changed an http:// link, or other content not directly visible in read-view?) I suspect this is also a problem if the content is inside a collapse template or if am trying to find who added-or-modified non-text content like a template or an image.
  • I'm not sure if there is difficulty with the available tools, but searching from an old version of the page is a significant use case. There are a lot of ways that the desired search-content can end up buried and only searchable from History. The simplest and most obvious case is when someone just deleted bad-content off the page. (May *I* am even the person who rushed to delete abusive or otherwise bad content off the page.) I need to find who added that content, but it appears the tool would be useless?? Another example: The article claims "John Q. Random" did something evil, the tool might show me that user Foo made a trivial edit changing "john q. random" to "John Q. Random". I still need to find out who is responsible for putting that name in the article. Pbsouthwood gave another example involving a spelling correction. Finding an edit that made a trivial spelling fix is unhelpful, we need to find the person who added the (mispelled) content in the first place. This is also an issue if someone does a copy-edit, changing the word order an/dor replacing words with synonyms may leave none of the original edit accessible though the tool. We need to find who added the conceptual-content, not the person who merely improved the grammar or clarity of that content. It's an annoying gap if the tool is unable to handle these use cases. (Of course a tool with an annoying gap is better than no tool at all, chuckle.) Alsee (talk) 11:37, 20 June 2019 (UTC)

• Not sure I am seeing what I am supposed to be seeing. I am using a mobile device at the moment (I would rather not give particulars publicly). Ottawahitech (talk) 02:34, 23 June 2019 (UTC)
• NKohli (WMF) That hover action doesn't work at all for me in the prototype. There is no way for me to progress from step 3 to beyond. —TheDJ (talk • contribs) 13:06, 24 June 2019 (UTC)
• NKohli (WMF) Looks good to me. The hover doesn't work for me either. Is it supposed to? Ijon (talk) 10:08, 29 June 2019 (UTC)

Response to Feedback

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech:

Hello, everyone! My name is Ilana, and I’m the new product manager for the Community Tech team. I’ll be managing the Who Wrote That project from now on, though I’ll be regularly consulting with Niharika. Below, I have provided some general questions, followed by responses to your feedback on the interactive mockup. Thanks for your feedback so far, and I look forward to further insights from the community.

General Questions & Updates:

• We’re excited to share the findings of the usability tests. Please check out the slides and let us know your thoughts.
• We plan to release the tool as a browser extension for Chrome and Firefox only (for technical reasons). If this tool isn’t available on other browsers, would this cause significant issues for users? Why/why not?
• In the current mockup, the tool is activated and accessed under Tools in the sidebar. However, would you prefer to access the tool via a tab at the top (for example, refer to the position of the “WhoColor” tab in the screenshot below) — and why/why not?

Responses to User Feedback:

@GreenC: Great to hear! As for the block of text in orange, the current interactive mockup displays the following on Slide 6 (see screenshot below):

Who Wrote That mockup, slide 6

When you click on the word, a pop-up appears, which provides details about the contribution (i.e. name of contributor with link to user page, link to user talk page, date of contribution with link to diff, and percentage of the article written by contributor). However, we’re changing certain elements of this display (see our response to Alsee). If you’re having difficulty viewing the pop-up, check out the advice at the end of this update.

@Alsee: Thanks for the detailed feedback, which I’ve responded to below:

• Yes, we (product and design) agree that the blue bar should not block access to any links, including History and View Source. We'll incorporate this change (i.e. no blocked links) into our design.
• Yes, we agree that the timestamp should be displayed instead of the date. Great point about cross-referencing the History page. We’ll incorporate this change into our design.
• You wrote that the pop-up doesn’t feel complete. We agree that the pop-up should follow general standards of information display. Now, regarding your specific points:
  • Yes, we agree that username should follow the standard pattern: Name (talk | contribs). The design will be updated to reflect this change.
  • You suggested the inclusion of edit summary in the details pop-up. We’ll investigate this suggestion and later share our findings.
  • Yes, we agree that the Undo and Thank You links should not be included in the pop-up because it excludes the full context of the edit.
• We plan to develop this tool for Read only mode for two primary reasons: 1) The majority of use cases are for Read mode, and 2) The technical work to support the tool in Edit mode is beyond the capacity of the team, especially if we want to complete other 2019 wishes.
• We’ll look into the feasibility of enabling Who Wrote That for older versions of an article. To properly investigate this issue, we have two follow-up questions:
  • You discussed the following use case: Someone deleted bad content from the page, and you want to know which author wrote the bad content. Can you let us know a common example of how/when you would identify the bad content on an old page without knowing the author?
  • You discussed the following use case: Someone corrected a grammar or spelling error on the page, and you would like to find who added the error. Can you let us know a common course of action/next steps you would take when you identify the author of a grammar or spelling error?

@Ottawahitech, TheDJ, Ijon, and GreenC: You experienced difficulty viewing the mockup. Here are some possible solutions:

• Some users reported difficulty viewing the mockup via mobile. We recommend you view it on a desktop browser.
• If you’re stuck on Slide 1, click “Got It.”
• If you’re stuck on Slide 2, click on “Who Wrote That” under Tools in the sidebar.
• If you’re stuck on any slide, click on the right arrow key (on a desktop device) or swipe right (on a mobile device) to proceed to the next slide.
• If these recommendations don’t resolve your issues, please let us know. We want to ensure that everyone can access and comment on the mockup.

Thank you and I look forward to hearing from you! IFried (WMF) (talk) 00:39, 10 July 2019 (UTC)

Thanks for the update. Can you clarify whether the browser extensions would be available in mobile versions of Chrome and Firefox as well? Ijon (talk) 17:31, 10 July 2019 (UTC)

@Ijon: Thanks for your response! The browser extension will be for desktop only. This is because mobile browsers don't generally support extensions. We may look into making the tool more accessible later on, if we have the resources. However, the current version will be desktop only. IFried (WMF) (talk) 01:47, 11 July 2019 (UTC)

@IFried (WMF): Thanks for clarifying. In that case, to your question "would this cause significant issues for users", my answer is yes, very significant issues. I have the privilege of contributing mostly from desktop (laptop) devices, but we have numerous communities, especially in low-income countries, where a majority of our contributors only have access to mobile devices (phones, tablets, ChromeBooks) and are practically never contributing from desktop devices. Excluding them from ever using this tool would greatly diminish its usefulness for very large swaths of our contributor base. I urge you to reconsider this product decision. Thank you. Ijon (talk) 17:08, 11 July 2019 (UTC)

@IFried (WMF): Firefox for Android does support extensions. The supported technology is WebExtensions, the same as what’s used by Firefox and Chrome (and Opera and Edge) desktop. Writing the extension to work in all these five browsers wouldn’t require much more work, but it would greatly improve the number of reached users—especially the Firefox for Android availability (although Chrome is much more popular, and installing yet another browser just for this is a bit overkill, but much more realistic than buying a PC, and at least we can say we did our best, and recommend users to install Firefox). —Tacsipacsi (talk) 19:02, 11 July 2019 (UTC)

@IFried (WMF): It would really be apreciated if support for mobile is added/given same attention as desktop. Indeed many volunteers in the Sub-Sahara region for example access and edit wikipedia via low-end/tech smartphones tablets/phablets and chromebooks. This feature would definitely improve and enrich their reader/editor experience. I hope that you will reconsider, at the very least the suggestion by Tacsipacsi, to make it available on firefox browser.--Thuvack (talk) 15:32, 12 July 2019 (UTC)

Regarding use case examples: While I recall there were several times I had to dig history to find who added something, it's hard to recall specific details. I'll offer a fictional example that hopefully answers the questions. Let's say there's a conflict at the biography of John Q. Random, and I add the page to my watchlist. The next day and edit shows up on my watchlist, someone either deleted the word "politican" or spelling-corrected it to "politician". Either way, the original word no longer appears on the page. The discovery of the problem and the workflow have begun from a version in history. I'm pretty sure John Q. Random was never a politician, so I want to find who added the "politican" claim to the article. Maybe it was a respected long term editor, and I can ask them if they have a source for the politican claim. Or maybe it was a short-history account and I need to check to see if every edit by that account was stealth vandalism. (Stealth vandalism: deliberately false information that looks plausible and which can easily slip common causual reviews.) If it's vandalism then I probably need to revert every edit made by that account, and have the account blocked. Alsee (talk) 20:24, 14 July 2019 (UTC)

@Alsee: Thanks for walking us through this scenario. Also, I apologize for the late response. This information was very helpful. We’ll think about this request, and we’ll update the community when we have updates. IFried (WMF) (talk) 21:41, 30 July 2019 (UTC)

Technical response regarding mobile

Hi everyone, I'm the technical lead for CommunityTech; thank you for all the feedback — it's super useful for us as we start planning the implementation stages of the project. I wanted to specifically respond to the requests for a mobile behavior.

We are, at the moment, planning to output the code for a desktop browser (Chrome and Firefox). There's some preliminary consideration to see if we can make this a gadget, but there are some concerns that we're looking into regarding loads, security implications of pulling from an external domain, and others. So while we're keeping the option open, it's not yet clear if we can go that route. A browser extension is what we are concentrating on, both in terms of development and testing.

As some of you pointed out, Firefox for Android can run browser extensions, but Chrome cannot. It is likely that we can make the mobile browser run the code. However, running the code is not the only consideration that we have to have in order to deliver a workable mobile product — and this is where the challenges lie. On desktop, you have a clear distinction between 'hover' and 'click' — on mobile, you do not. Everything is a tap or swipe action. Making this product a mobile experience doesn't just mean running it on the mobile device, it also means rethinking the UX and interactions when the user uses the mobile device. This is just one example; in our experience, there tend to be quite a number of them.

We aren't eliminating the possibility of delivering a mobile experience. We are still in the preliminary stages of exploring what some of the development aspects mean and how long they take. There are pieces of the current interaction (even in the browser version) that need to be implemented from scratch. Each addition to that takes more time. As the Community Tech team, and unlike most other teams at the Foundation, our work covers multiple products in the Wishlist, so our focus is to deliver to you the best product interaction we can — within a limited scope and time.

My recommendation is this: We start with a desktop experience that is responsive, making sure that technically speaking the code is ready to run on mobile. We concentrate our efforts, first and foremost, on delivering a working and robust product to you on the two browsers, with an exploration of making it a gadget, either now or in the future.

Alongside that, we will explore what it requires to provide a workable UX for the mobile experience, so that we can estimate this work properly and provide better insight into whether it's feasible for us. If it is — all the better! :) if it's not, we will have to scope it down. And, as always, and with great pleasure — patches are always welcome! :)

MSchottlender-WMF (talk) 19:43, 12 July 2019 (UTC)

I like the current slides, but I don't understand the decision to go for a browser extension. I don't think any regular features are currently provided via browser extensions Providing features via a browser extension means that the feature isn't easy to discover for new users. That's especially import for users that only use Wikidata irregularly. ChristianKl ❪✉❫ 08:08, 15 July 2019 (UTC)

Yep, this is much better done as a MediaWiki "gadget" that we can turn on via Preferences. As for placement, I would say to put it up top, since I rarely use stuff in the left-hand menu, but others may prefer the opposite, so some kind of preferences/options choice would be good.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  18:11, 24 August 2019 (UTC)

Looking for Survey Participants (to determine link location)

@Beta16, JzG, SMcCandlish, Pbsouthwood, Dalka, KlaasZ4usV, ChristianKl, GreenC, Ijon, Atlasowa, Alsee, and Ottawahitech: We are now considering the location of the Who Wrote That tool link. To do this, we would like to collect some feedback regarding how you find information about pages. For this reason, we would love if you could answer two brief questions in our survey. Thanks! IFried (WMF) (talk) 17:52, 26 September 2019 (UTC)

• Done· · · Peter (Southwood) ^(talk): 18:03, 26 September 2019 (UTC)
• Done --β₁₆ - (talk) 08:12, 27 September 2019 (UTC)
• Done Klaas `Z4␟` V:  08:25, 27 September 2019 (UTC)

@Pbsouthwood, Beta16, and KlaasZ4usV: Thank you! Also, if anyone still wants to participate in the survey, there is still time & we would love your feedback. Thanks! IFried (WMF) (talk) 01:33, 29 September 2019 (UTC)

Thank you so much for the feedback! Based on your responses we'll be checking the technical feasibility of some solutions, and then deciding where this tool would be accessed from. The survey is still open if you'd still like to leave your answers. PSaxena (WMF) (talk) 13:00, 3 October 2019 (UTC)

• Done, since it still seems to be open.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  07:57, 28 October 2019 (UTC)

Gadget, tool, extension?

I'm trying to understand how is this developed exactly and I can't find an answer on this page: As a gadget whose code is maintained on wiki pages? Or as a MediaWiki extension? Or as an external tool?

Tagging User:PSaxena (WMF)], User:MusikAnimal (WMF), User:IFried (WMF). --Amir E. Aharoni (talk) 18:53, 31 December 2019 (UTC)

As far as I understand, this is going to be a browser extension for Firefox and Chrome, although I don’t see it yet on Wikimedia’s AMO account. —Tacsipacsi (talk) 23:50, 31 December 2019 (UTC)

It is here on AMO. The CT team have their own account. – Ammarpad (talk) 07:15, 2 January 2020 (UTC)

Why yet another place to keep track of, without a single link from Meta… At least we should have a status update on this page (not the talk page) with steps how to install the beta version in Firefox (and Chrome, if it’s available there). —Tacsipacsi (talk) 14:46, 2 January 2020 (UTC)

User:Amire80, User:Tacsipacsi, and User:Ammarpad Hello! WWT is being developed as a browser extension for Chrome and Firefox, available on desktop browsers. We shared our plan to make it a browser extension in June 2019. We later discussed some of the technical details regarding desktop vs. mobile support, as well as potential future plans, in July 2019. Since that time, we have been working on developing the tool as a browser extension. The beta version is currently being tested and improved (there are some bugs to fix). For this reason, we have not publicly announced or shared the tool yet. However, we plan for it to be generally available soon. We’ll definitely update everyone when that’s the case. Thank you, and more updates should be coming soon!--IFried (WMF) (talk) 18:52, 2 January 2020 (UTC)

I don’t think posting an update on Community Tech/Who Wrote That tool would count as a “public announcement”. This page is mainly for people specifically interested in this tool, and the more people test the knowingly beta version, the less bugs remain in the stable one. —Tacsipacsi (talk) 19:27, 2 January 2020 (UTC)

Tacsipacsi I will not only be posting on Meta-Wiki. I will be sharing on many channels when the tool is available.--IFried (WMF) (talk) 21:18, 2 January 2020 (UTC)

I understand that. But could CommTech right now post an update only on Community Tech/Who Wrote That tool so that important information and URL could be found on the content page, and people ignoring talk pages get a chance to notice them? —Tacsipacsi (talk) 22:29, 2 January 2020 (UTC)

Tacsipacsi We'll be posting an update with links to the extension (and request for feedback) very soon. There are just a few critical bugs that we would like to fix first. Once they are resolved, we'll widely share the tool. We just returned from our holiday break today, so we're catching up with some work over the next few days. You can expect an update regarding WWT in the next few weeks. Thanks for your patience, and we look forward to posting further updates soon. Thanks! --IFried (WMF) (talk) 00:11, 3 January 2020 (UTC)

Tacsipacsi Who Wrote That? is now available as a Chrome and Firefox browser extension. You can check out the details in the section below. We would love your feedback. Thank you! --IFried (WMF) (talk) 23:44, 14 January 2020 (UTC)

Beta Tool Released: Ready for Feedback

Note: Apologies if you were pinged twice! The first ping did not seem to go through due the 50+ ping limit, so I've updated the message blocks to be separate edits. Thanks!

@Tim.landscheidt, Strainu, Tgr, Ijon, Jenks24, Dvorapa, HHill, Beta16, Oscar ., Liuxinyu970226, Jc86035, YFdyh000, Stryn, Arkanosis, Draceane, Yiyi, Rcsprinter123, Laboramus, Gripweed, Iliev, Kurt Jansson, Thomas Obermair 4, Bawolff, PKM, Bspf, Simon Villeneuve, Ottawahitech, TheDJ, Ermahgerd9, Luan, ZellmerLP, He7d3r, Putnik, Nocowardsoulismine, Furfur, DMacks, JzG, Pbsouthwood, Nizil Shah, Defender, OrsolyaVirág, Dromedar61, ThePlatypusofDoom, Barcelona, Hogne, and Eug: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@TerraCodes, Gnom, Wostr, Cybularny, Wolbo, Tom Ja, Emir of Wikipedia, TheCatalyst31, Noyster, Winged Blades of Godric, Kostas20142, FULBERT, Paucabot, Mz7, Giraffedata, Gryllida, SMcCandlish, Jpcomic, ChristianKl, MOs810, Nabla, Doc James, Epìdosis, Ca2james, Shock Brigade Harvester Boris, B25es, Anthere, -glove-, Kudpung, The wub, Kolurpen, PamD, KlaasZ4usV, 15zulu, Tacsipacsi, Pipetricker, and Fano: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@MichaelMaggs, NaBUru38, Ldorfman, Perrak, Spinster, Jack who built the house, Serhio Magpie, Ле Лой, Sleeps-Darkly, Dispenser, Manu1400, Psychoslave, Niklem, Infovarius, Ilya, Ragesoss, NickK, Gikü, Martin Kraft, Semmendinger, and Downtowngal: --IFried (WMF) (talk) 06:26, 15 January 2020 (UTC)

@Superchilum, Laurentius, and Bryanrutherford0: --IFried (WMF) (talk) 06:40, 15 January 2020 (UTC)

Hello, everyone! I have pinged you because you voted on the 'blame tool' in the 2017 Community Wishlist Survey. We are now very excited to share Who Wrote That?, available as a Chrome and Firefox browser extension. With Who Wrote That? (WWT), you can find authorship information directly on Wikipedia articles. When you hover over content, the tool highlights all content by the same author. When you click on content, the tool identifies the author of the revision, along with revision details. Currently, the tool is in beta mode, and we would love your feedback. There are still some minor bugs to fix (and please let us know if you find any!), but the tool is already functional. You can download the Chrome and Firefox extension, and documentation on the tool is available on the MediaWiki WWT page. The data and analysis in WWT come from the WhoColor API, developed by WikiWho, and the MediaWiki API. Thank you, and we look forward to hearing your feedback! --IFried (WMF) (talk) 22:00, 13 January 2020 (UTC)

I like where this is heading! Main concerns, and apologies if I'm repeating things that have already been said – I've not had the time to properly read through the entire discussion:

• I'd be concerned if this would be opt-in for more wikis – being added upon request. They tend to miss those opportunities exist, and then when individual editors find out about the tool they have no idea how to get it to their wiki.
• It seems to understand reverts, but if I accidentally remove something while adding content, and then reinstate it using copy and paste (because reverting would remove what I added earlier), I get credited as the author of that piece.
• I'd love for this to work in the Wikipedia namespace, so I could try to follow who added which piece of policy or guideline.

Nice work. /Julle (talk) 04:40, 14 January 2020 (UTC)

(Or Commons namespace et cetera once it works beyond the Wikipedias, of course.) /Julle (talk) 06:48, 15 January 2020 (UTC)

@Julle: Thank you so much for the feedback! We are currently conducting an investigation to see if it is possible to expand accessibility of Who Wrote That? (both in terms of making it a gadget/extension and extending support to other wikis). Your question about the Wikipedia namespace is interesting, so I've added that question to the investigation as well. Regarding the accidental removal + copy/paste issue, I'm not sure if there is anything that can be done, but we can certainly take a look. Ideally, what behavior would you like in such a scenario, as a WWT user? Thanks! --IFried (WMF) (talk) 20:16, 22 January 2020 (UTC)

@Julle: Also, I should add that we're currently displaying the data that we get from the WhoColor API. This means that we can ask WhoColor folks to add support for the Wikipedia namespace, but we can't add that support directly. --IFried (WMF) (talk) 20:37, 22 January 2020 (UTC)

User:IFried (WMF) I love the fact that it gives the diff that added the edit in question :-) I would love this to also work on references and external links as that will make it faster to find people who are spamming these. Great work by the way. Doc James (talk · contribs · email) 10:55, 15 January 2020 (UTC)

@Doc James: Thank you for the feedback! I'm glad that you find the diff link to be a useful part of the tool. As for including references and external links in the analysis, we unfortunately can only display the data we get from the WhoColor API. Currently, the WhoColor API does not include references and external links in its analysis. However, if this changes in the future, we would happily extend that support to the tool as well. Thanks! --IFried (WMF) (talk) 20:42, 22 January 2020 (UTC)

At first glance and test of this, it seems an amazing tool. Thanks for sharing the initial version of this and happy to begin testing it. --- FULBERT (talk) 12:07, 15 January 2020 (UTC)

@FULBERT: Thank you for the supportive words, and we're happy that you like the tool so far. We look forward to any feedback that you have to share! --IFried (WMF) (talk) 20:44, 22 January 2020 (UTC)

I understand that there are technical limitations and that it's far more difficult to handle manual removals and re-inserts than reverts, but ideally, it wouldn't differentiate between what was "reverted" manually and what was reverted using the revert functionalities, since, in effect, they amount to the same thing in this particular case. I worry about the future where this is used externally and we see newspaper articles, papers and so on miscredit editors as the writers of things they simply copied and put back. /Julle (talk) 20:25, 22 January 2020 (UTC)

@Julle: Great point. I'm not sure what is possible, but I agree that it's at least important for the team to discuss (and see if we can support/improve the situation in any way). I've made a note for us to discuss it during an upcoming meeting. Thank you for bringing this to our attention. --IFried (WMF) (talk) 20:51, 22 January 2020 (UTC)

I'm also impressed with it, and mostly look forward to it expanding in applicability over time. That said, I would discourage a focus on bringing it to the project namespace. I would suggesting doing that as a final step (and an optional one), after people have gotten used to the tool, and after some norms evolve against misusing it to cast aspersions and make other bogus, battlegrounding arguments. The "fallacy of the revelation of policy" is already a recurrent problem, and having this tool usable in projectspace right from the beta period will simply worsen it.  — SMcCandlish ☺ ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:46, 15 January 2020 (UTC)

How? People will notice that the essay you cited is one that you wrote yourself? I think the more useful case would be people being able to find out when a given bit of a guideline was added, and therefore have an easier time finding any related discussions in the archives. Those discussions can often be useful in understanding whether the people writing it had considered the situation at hand. "Oh, hey, that was written several years before our policy about BLPs" can be a valuable revelation. WhatamIdoing (talk) 03:30, 16 January 2020 (UTC)

@SMcCandlish and WhatamIdoing: Thanks for providing perspective on some of the pros/cons of allowing WWT in the project namespace. At this point, we cannot implement this support either way, as we do not get such data from the WhoColor API. However, this conversation will be very useful for us to revisit if such support ever does change in the API. Thank you! --IFried (WMF) (talk) 20:55, 22 January 2020 (UTC)

Will this become a mediawiki extension, or will this stay as a browser extension? Also why does the browser extension need my browsing history? --Terra ❤ ^(talk) 12:24, 15 January 2020 (UTC)

I would also like to know why it needs my browsing history, and more importantly, what it does with it. · · · Peter (Southwood) ^(talk): 07:02, 19 January 2020 (UTC)

Hi @TerraCodes and Pbsouthwood:, thank you for your concern. Can you tell me where do you see that the extension asks for the history permission? We explicitly only ask for two permissions:

• activeTab (info here): Provides access to the contents of the current tab the user is on (we do not request information about all tabs)
• storage (info here): Provides access to the internal browser storage so we can save the state of whether to present the "Welcome" popup to you.

We do not ask for the history permission. On top of that, the "manifest" file (that defines where and how the extension runs and under what permissions), is specifically defined to only run the script within the approved wiki domains. You can see that file -- and the permissions we're requesting -- in this link.

Has the browser requested the history permission from you when installing the extension? If so, could you please tell me what browser store, and if possible, what it is that the warning stated? Thank you! MSchottlender-WMF (talk) 21:21, 22 January 2020 (UTC)

Thank you for doing that work. This is going to be an extremely useful tool! I've found just one bug so far (using the Firefox extension): sometimes it breaks the display of image galleries. Try it for example on the Father Christmas article, and watch what happens to the gallery named Old Father Christmas in folk plays part way down the page. MichaelMaggs (talk) 13:08, 15 January 2020 (UTC)

I'm disappointed that this wasn't implemented as a gadget. It seems that the wishlist of next year needs a wishlists item for "Gadget that provides the blame functionality" so that there's a possiblility for users to discover the functionality. ChristianKl ❪✉❫ 17:27, 15 January 2020 (UTC)

Unfortunately, can't use this due to the fact that I don't use any of these two browsers. Wostr (talk) 17:33, 15 January 2020 (UTC)

Very nice! I use the WikiWho tool very often, so I'm glad to see this work on making something that's easier to install. A few things that could be improved: Being able to highlight multiple people at once has been pretty useful (e.g. when looking at what a group of students have added to a page). It's also be useful to have a authorship summary stats graph (https://xtools.wmflabs.org/articleinfo) pop up when clicking the header, or even just a link to it. Having the breakdown for each section when the seciton header is clicked would be similarly useful. WhikiWho always had problems when printing the page to PDF with annotations shown, and this tool overall does much better, with the exception that the WWT header bar floats in the middle of the page. Obviously, working with references would definitely be very valuable, since that's also something WikiWho wasn't able to do. Overall I like the interface aesthetic improvements over WikiWho. It also seems to avoid the issue that WikiWho has where sometimes it'd stop tracking sections below the first table. Eventually it may even be useful to have as a default part of the history tab. T.Shafee(Evo﹠Evo)^talk 07:01, 16 January 2020 (UTC)

I do not use those browsers by default :( Anthere (talk)

I've added this to Firefox and Chrome, and on heaps of pages the link doesn't appear in the menu. (In both browsers, on Windows, and different pages.) How could I go about debugging why that is happening? pfctdayelise (talk) 22:53, 16 January 2020 (UTC)

@Pfctdayelise: We issued a fix yesterday, which may resolve the issue you have been experiencing. In that case, I recommend that you go to the Chrome and Firefox web stores to uninstall and then re-install the extension (click "Remove" and then immediately click to add the extension again). The extension should then appear under "Tools" if you're viewing it on Wikipedia articles in read mode on a desktop browser (English, German, Basque, Turkish, or Spanish Wikipedia only). Let me know if you still encounter the issue or if the issue is resolved. Thank you! --IFried (WMF) (talk) 20:19, 17 January 2020 (UTC)

Using it on Chrome and loving it so far. What a cool gadget! Clayoquot (talk) 06:51, 17 January 2020 (UTC)

• Works for me on Chrome. Have not yet tried it in Firefox. It appears to have to reload each time one goes to a new page, and takes several seconds to do so. Is this normal? (My internet is very slow at the moment, and Wikipedia edits take several seconds to open or save, and occasionally crash, so it might not be the tool). Also does not allow "show" function in collapsed navbox, but that is not a crisis. · · · Peter (Southwood) ^(talk): 10:11, 17 January 2020 (UTC)

  The blue bar seems unneccesarily large.

  Seems to work the same on Firefox.

  There is no popup until I click on a word. It takes several seconds for the popup to resolve, but that might just be my crappy internet, as currently it is taking several seconds to open an edit window, when it actually finds the server. There is no darker highlight on the selected word, and no indication of the user in the blue bar as shown above.

  The tool does not appear to work with any templates.

  When it reports X has written Y% of the page, what does this mean? The number appears to be somewhat unrealistic. Cheers, · · · Peter (Southwood) ^(talk): 06:53, 19 January 2020 (UTC)

I'm disappointed. Wikipedia should work from everywhere with every device and without a special app or extension. Not just with two specific browsers and after downloading and installing an additional tool, which I might not even be allowed if it is not my computer. So what you produced was explicitly NOT my wish. And proof that its possible in a different way is de:Benutzer:Schnark/js/artikel-statistik. Obviously I'm not going to test your tool, because I'm not going to install it. Fano (talk) 13:29, 17 January 2020 (UTC)

I can immediately think of two things to improve this tool

1. Allow the revision of the text that you are hovering over to be a different colour to all other text by the same author. (The tool shows the diff of only the hovered text, and this is different for each yellow text by that author that you click. I propose that the text associated with the diff be a different colour.)

2. Prevent the selection from being abandoned when you use the middle mouse button to scroll down the page in Chrome. (Click some text to bring up the popup, then click or hold the middle-mouse button to scroll. The selection disappears. This shouldn't happen. Such scrolling doesn't have any different effects (that I know of) to regular scrolling in regular Chrome usage.)

Thank you. SUM1 (talk) 09:51, 22 January 2020 (UTC)

@SUM1: There is one important difference between the behavior of the regular scroll and the middle-button scroll (so-called autoscroll) on Windows (there is no autoscroll in Chrome for Linux and Mac at all): when you press the middle button over a link, it doesn’t start scrolling, as the middle button is not only the autoscroll button, but also the button to open links in new tabs. This shows that the two don’t behave exactly the same even without any JavaScript; however, it doesn’t mean that closing the popup with middle click cannot be prevented. I don’t know which way is it more intuitive, though. —Tacsipacsi (talk) 18:30, 23 January 2020 (UTC)

@Tacsipacsi: That's strange, Chrome updated and it suddenly doesn't want to hold on to any selection at all when I scroll with the middle-mouse button. I could swear it did before. It still does in Firefox. Still does in word processors too. SUM1 (talk) 18:51, 23 January 2020 (UTC)

@SUM1: I’m afraid I can’t help you: I use neither Chrome nor Windows on a daily basis. I suggest you to find another support forum for your problem. Or use Firefox, like me! ;) —Tacsipacsi (talk) 19:06, 23 January 2020 (UTC)