Community Wishlist Survey 2023/Admins and patrollers/Inline diffs and inline patrol

Add links
From Meta, a Wikimedia project coordination wiki

Inline diffs and inline patrol

  • Problem: Patrolling recent changes is a time-consuming duty with very little help from MediaWiki software. It takes several clicks and browser tabs to patrol even the smallest change, while everything could be done inline, without ever leaving Recent changes, Page history or User contributions pages and losing track of where we left off. Unpatrolled changes are marked with a single ! in Recent changes, but not on Page histories and User contributions.
  • Proposed solution: I found the combination of "inline diffs" and "inline patrol" scripts extremely useful, and I'm proposing that their logic be added to MediaWiki software for all users with patrol rights. Every edit would get two buttons, one to [show diff] inline, one to [patrol] the change.
  • Recent changes (animation)
    Recent changes (animation)
  • Article revision history
    Article revision history
  • User contributions
    User contributions
  • Who would benefit: users with any kind of patrol rights; the feature should be enabled for them by default
  • More comments: Everything needed for this feature is already there: diff table (example) and patrol actions are in the API. What's lacking are some hooks in the frontend software, consistent across recent changes, page histories and user contributions: buttons to expand or hide diffs, buttons to patrol a change, revision ID data present in every line of the lists.
Try it now

What the feature could look like can be tested by loading either (ExpandDiffs) mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Bradv/Scripts/ExpandDiffs.js&action=raw&ctype=text/javascript");
or inlineDiff: mw.loader.load("//en.wikipedia.org/w/index.php?title=User:Writ Keeper/Scripts/commonHistory.js&action=raw&ctype=text/javascript");
together with inline-patrol.js mw.loader.load("//meta.wikimedia.org/w/index.php?title=User:Ponor/inline-patrol.js&action=raw&ctype=text/javascript"); This goes in one's local common.js, or in global.js at Meta. The first of the "inline diff" scripts only works on the English language wikis, but adds nice buttons in the style of Twinkle. The second script works on all wikis, as far as I know, but uses a tiny triangle to expand the diffs and messes up the "Group results by page" RC feature. Because all scripts depend on some hooks to manipulate the browser's DOM, they're very prone to breaking with any MediaWiki software updates and may not work on all pages on mobile/desktop sites.

Our wikis depend on the hard work of users with patroller rights. This feature would make their work much more efficient.
I know there is some external software or scripts that can do the same, but:
  • they seem to be enwiki-centric and don't play well with other wikis, or don't work at all
  • users, arguably, prefer working (writing, reading, patrolling, administrating) from the same interface (browser window), and on different devices
  • most users (patrollers) are, in my experience, reluctant to even create common.js and c&p two lines of code, because "not everyone is a computer scientist"
  • these tools and scripts are not easily discoverable, and debugging them to work on all wikis and for all users is likely very hard
  • some, if not all, do not have centralized message translation
  • or they show diffs separate from the changes list, causing a lot of scrolling back and forth.
My thanks go to Bradv, Writ Keeper, and Ivi1o4 for some inspirational code.

Discussion

  • What if the diff is 100 lines long ? How would we handle that ? And how would this behave on mobile ? —TheDJ (talk • contribs) 19:37, 23 January 2023 (UTC)[reply]
    @TheDJ, the majority of diffs are short. I've used the two scripts to patrol thousands of edits, and had no issues with very long diffs either. It's as painful as checking the diff on a separate page: if it's too long, it's too long. The [show diff] button could ask for a second press if diffsize (example) is above some threshold. Every diff is downloaded on demand, and can be easily closed because the change entry and the corresponding [show diff] button do not shift relative to the viewport.
    No issues for me on mobile. I don't use my phone to patrol en masse, but the buttons come in handy for some users and some edits. Jdlrobson suggests using in lineinline, as opposed to side-by-side diffs on mobile (phab:T327566), that'd be cool if supported by MW API.ponor (talk) 21:09, 23 January 2023 (UTC)[reply]
    However, there are some problems resulting from the diff is too large, such as harder to load (some vandals insert a lot of content in one edit). Thingofme (talk) 01:50, 24 January 2023 (UTC)[reply]
    I use my own version of this type of script and it has built-in "jump to bottom/top" buttons ;) Nardog (talk) 19:23, 24 January 2023 (UTC)[reply]
    FWIW some Fandom wikis use QuickDiff, which arguably has slicker UI than the popular inline diff scripts on Wikipedia. Nardog (talk) 07:25, 27 January 2023 (UTC)[reply]
    See User:NguoiDungKhongDinhDanh/QuickDiff. He has deployed the tool onto Wikimedia. Thingofme (talk) 03:10, 28 January 2023 (UTC)[reply]
    I did think of using modal windows myself, and QuickDiff may indeed *look* slicker, but it introduces more complexity and actually slows down some common patroller workflows (I'm talking about 1000–2000 manually patrolled changes a month here!): 1) a user makes 10 small overlapping changes, you check their joint diff on Page history and quickly click one by one as patrolled using inline [patrol] buttons; with modal windows you'd need to open and close 10 windows; 2) when global (semi)-bots rename images, you also want to patrol quickly without checking the diffs; 3) it's sometimes convenient to see a few consecutive diffs at the same time, to check "where the user is going", and quickly patrol them; with modal windows you can view one diff at a time (...) All in all, I still prefer simple, efficient and quick over slick. The note at the bottom of NguoiDungKhongDinhDanh's page also tells you why we need some support from CommTech here: our hacks sometimes just don't play well together. ponor (talk) 09:19, 28 January 2023 (UTC)[reply]
    In Fandom, we have aggregative changes over one page by multiple users in Recent Changes, but in Wikimedia does not have this feature. Thingofme (talk) 13:57, 28 January 2023 (UTC)[reply]
    Actually, QuickDiff do allow you to navigate between consecutive diffs by using arrow keys. However, you're right: continuously opening and closing a window doesn't seem so nice. For inline patrolling, we have this Wikidata gadget which works quite well. NguoiDungKhongDinhDanh 09:15, 11 February 2023 (UTC)[reply]
    QuickDiff cannot patrol edits like this (QuickDiff was copied from Fandom script). Thingofme (talk) 13:34, 11 February 2023 (UTC)[reply]
  • Given the proposer, and supposedly other users, seem to be content with the existing tools, I feel like this should be developed bottom-up (by community), not top-down (by WMF). Not something I want to see CommTech's limited resources spent on. Nardog (talk) 19:23, 24 January 2023 (UTC)[reply]
    @Nardog, I never said I was satisfied. The scripts work (hackishly) on some wikis, for some users, on some pages, and only with some options, so the two features — [show diff] & [patrol] — definitely need some love and support from CommTech. Plus, I specifically asked this be enabled for all patrollers (and other roles I may not even know about) in a unified way, which helps with teaching, translations, debugging... I mean, you go to Revision history or User contributions and you can't even see which changes have or haven't been patrolled. Our patrollers deserve better than that! ponor (talk) 22:21, 24 January 2023 (UTC)[reply]
  • If implemented, it should have nothing to do with patrolling rights. This is useful for any advanced user, regardless of holding any advanced rights. That being said, I'm more or less satisfied with w:User:Bradv/Scripts/ExpandDiffs.js, and I think improving some of the existing scripts might be a good option. MarioGom (talk) 17:34, 28 January 2023 (UTC)[reply]
    If there's interest, all users can get [show diff] buttons inline, and patrollers/sysops/? can additionally get buttons to [patrol]. Also, if possible, non-patrollers could get [unpatrolled] 'tags" instead of the [patrol] buttons, so they could see which changes have been patrolled – why not? When thinking of user scripts, please don't think enwiki alone. I've used ExpandDiffs for my mock-ups because I like the style (of its buttons), but I'm forced to use the other script to patrol on my little wiki /has to do with how the script extracts some data from html source. ponor (talk) 23:49, 28 January 2023 (UTC)[reply]
    Sure. I think about all wikis. User scripts can also be improved for cross-wiki support. And, if required, MediaWiki can be improved to make it easier to port these scripts, if these rely on some features that are not portable. MarioGom (talk) 21:56, 29 January 2023 (UTC)[reply]
    I agree the proposal's coupling of diff and patrol is weird. I bet it would attract more support if it were about just one or the other. Nardog (talk) 14:30, 29 January 2023 (UTC)[reply]
  • Improving moderation tools by providing more context directly in the patrol interface (i.e., recent changes) is something I would much support. --Matěj Suchánek (talk) 13:55, 29 January 2023 (UTC)[reply]
  • I think that if this is done, we should make it a special 'app'. We should resist the urge to stuff ever more functionality into a few highly critical pages (that should also be mobile compatible). —TheDJ (talk • contribs) 23:36, 29 January 2023 (UTC)[reply]
    There are special apps like SWViewer that have this capability, however the request seems to be integrating it into MediaWiki and Wikimedia pages. Thingofme (talk) 15:31, 30 January 2023 (UTC)[reply]
    Arguably, we call RCh/PHist/UContrib pages highly critical *precisely because* that's from where we start patrolling. Since both actions (show diff + patrol) will happen on demand, with some quick calls to MW API, this can be coded as an "official" javascript gadget (or two), adding very little burden to those pages for patrollers/admins who leave the feature enabled and choose not to use it. Those who are patrollers but do not patrol can always disable the feature and will see nothing. ponor (talk) 16:40, 30 January 2023 (UTC)[reply]
    People usually start patrolling from there Recent Changes pages, and patrollers and rollbackers with these tools can perform their duties faster without using 3rd party apps like Huggle, SWViewer... but Twinkle and RedWarn/Ultraviolet has proven to increase the patrolling speeds. Thingofme (talk) 14:35, 31 January 2023 (UTC)[reply]
  • Somewhat overlaps with Redesign the watchlist. --Tgr (talk) 00:58, 1 February 2023 (UTC)[reply]
  • We can already view diffs in Navigation Popups; a "mark as patrolled" option could - and should - be added there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:10, 2 February 2023 (UTC)[reply]
  • You can also use this great script that allows you to see the changes in a pop-up window: commons:User:Serhio Magpie/instantDiffs.js - mw.loader.load('https://commons.wikimedia.org/w/index.php?title=User:Serhio_Magpie/instantDiffs.js&action=raw&ctype=text/javascript'); Iniquity (talk) 19:16, 10 February 2023 (UTC)[reply]

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Admins_and_patrollers/Inline_diffs_and_inline_patrol&oldid=24623493"