If someone decides to pick up this work, Design-System-Team is happy to support.

I got a couple of suggestions for this page's behaviour at Wikimania (I forget from who now, perhaps @Chlod?, sorry!):

• A column in the table that signifies whether the creator was the only contributor or not - there are Nuke use cases for deleting pages where the only contributor was a particular user, but further investigation might be warranted if multiple users have edited the page. This could perhaps be a Yes/No datapoint or displaying the total number of page editors.
• We should do a mockup with image thumbnails for when Nuke is used on images. Also, the behaviour with thumbnails is poor right now, because clicking an image takes you to the page for that image. If you then navigate back, you are prompted to resubmit the form and lose any checkbox progress. Instead we could explore integrating Media Viewer, like in articles, so that clicking the image has it pop up, but is closable, without taking you off the page.

Indeed it was me. I think we also discussed if it was possible to use MediaViewer with TheDJ? Not sure if there was anything specifically blocking, though.

In T370974#10060878, @Chlod wrote:

Indeed it was me. I think we also discussed if it was possible to use MediaViewer with TheDJ? Not sure if there was anything specifically blocking, though.

Yeah, it sounded not-straightforward but also not impossible.

Another column suggestion - page size (bytes) so that users could sort the table by page size. An example use case would be community consensus to delete all very short pages (e.g. redirects) created by a given user.

Hi, that one came from me. In addition to including size information, I'd recommend

1. Adding the ability to exclude (or limit the query to) redirects
   • Like the size filter, this is likely to come in handy in cases where a productive contributor has mass-created a specific type of page that needs deleting; bad redirects and inappropriate stubs are the most likely candidates here.
2. Allowing people to exclude namespaces (and/or list multiple namespaces of interest) as opposed to simply enabling them to limit queries to a single namespace
   • This is likely to be useful because many nuke operations will likely want to exclude individual namespaces. This applies specifically to user talk pages, which -- on enwiki at least -- are almost never deleted. If, say, a block-evader created a bunch of main-, project- and templatespace pages that an admin wants to delete per CSD G5, but they first gamed extended-confirmed by mass-placing welcome messages on the talk pages of newly-registered users, then the current filtering setup would either require them to not filter by namespace and manually (un-)tick all user talk pages, or to run nuke several times -- once for each namespace of interest. Both approaches seem suboptimal from a UX perspective.

Looking at the mockup, I think it would be a significant improvement over the current design no matter what additional features are implemented. I do wonder whether it's necessary to hide the creation timestamp, as well as the editor and edit counts behind a toggle. I suspect the vast majority of users would end up enabling them anyway, and 5 columns doesn't seem excessive as the default table width.

In T370974#10199244, @Blablubbs wrote:

1. Allowing people to exclude namespaces (and/or list multiple namespaces of interest) as opposed to simply enabling them to limit queries to a single namespace
   • This is likely to be useful because many nuke operations will likely want to exclude individual namespaces. This applies specifically to user talk pages, which -- on enwiki at least -- are almost never deleted. If, say, a block-evader created a bunch of main-, project- and templatespace pages that an admin wants to delete per CSD G5, but they first gamed extended-confirmed by mass-placing welcome messages on the talk pages of newly-registered users, then the current filtering setup would either require them to not filter by namespace and manually (un-)tick all user talk pages, or to run nuke several times -- once for each namespace of interest. Both approaches seem suboptimal from a UX perspective.

Filed at T376379 - I'll copy this comment over.

Thank you, Sam -- I should've checked for a separate task first, my bad.

Having thought about this some more: Are there any plans to enable users to adjust the query parameters "on the fly", i.e. once they've already reached the list of pages? Currently, Nuke is a two-step process where users first specify the search parameters (user, title pattern, namespace etc.), and are then presented with the actual deletion menu. Adjusting the parameters requires them to navigate back and fill out the form again. It might be nice to make this process a little more dynamic, akin to the way Special:Search allows users to look at an initial list of results, adjust the query term and the list of namespaces to search, and then re-execute the search right away. Integrating the filter options with the results would allow users to iteratively refine their search and simply ht "select all" at the end, as opposed to having to navigate back and forth between forms or "fix" a suboptimal initial query by (un-)ticking individual checkboxes.

A suggestion from a Commons admin - displaying somewhere the number of pages which fell outside the range Nuke can target, which may require followup deletion. For example, if a user created 25 articles, but only 20 of those were in the past 30 days, Nuke could display something like "5 other articles are too old to be deleted by this tool." and link out to their contribs/created pages.

In T370974#10211202, @Samwalton9-WMF wrote:

A suggestion from a Commons admin - displaying somewhere the number of pages which fell outside the range Nuke can target, which may require followup deletion. For example, if a user created 25 articles, but only 20 of those were in the past 30 days, Nuke could display something like "5 other articles are too old to be deleted by this tool." and link out to their contribs/created pages.

T379624