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. 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)