This layout makes it a little more obvious how we can achieve T376378 - we allow access to Special:Nuke but don't display the Continue button unless you're an admin.

It also makes T364224 redundant.

Noting this here so I don't forget: https://www.mediawiki.org/wiki/Help:Extension:Nuke needs an update.

Change #1099306 had a related patch set uploaded (by Chlod Alejandro; author: Chlod Alejandro):

[mediawiki/extensions/Nuke@master] Redesign Special:Nuke action flow

https://gerrit.wikimedia.org/r/1099306

I started on a code review and had some clarifying questions about the flow:

In the ticket it says:

Pages matching the filters should be displayed below the form, and update when new filters are run.

Does this mean that the list should update when you change the filters or when you click the List pages button?

Also, while testing the patch if no pages are found the form is disappearing (screenshot below):

In T380297#10374006, @Kgraessle wrote:

I started on a code review and had some clarifying questions about the flow:

In the ticket it says:

Pages matching the filters should be displayed below the form, and update when new filters are run.

Does this mean that the list should update when you change the filters or when you click the List pages button?

Ah, when you click List Pages, I wasn't intending for this to be an automatic update/refresh.

In T380297#10375483, @Samwalton9-WMF wrote:

In T380297#10374006, @Kgraessle wrote:

I started on a code review and had some clarifying questions about the flow:

In the ticket it says:

Pages matching the filters should be displayed below the form, and update when new filters are run.

Does this mean that the list should update when you change the filters or when you click the List pages button?

Ah, when you click List Pages, I wasn't intending for this to be an automatic update/refresh.

Ok, perfect, thanks for clarifying for me.

In T380297#10374006, @Kgraessle wrote:

Also, while testing the patch if no pages are found the form is disappearing (screenshot below):

Fixed this, and also rebased to solve the merge conflict. cc @Samwalton9-WMF; if Patch Demo still doesn't work with this patch, then it must be something else.

Test wiki created on Patch demo by SCardenas (WMF) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/064b6ee2dc/w/

I created a PatchDemo with the latest patchset so you can test it there, @Samwalton9-WMF.

Thanks folks, some observations:

If no pages are selected for deletion, the confirmation page still loads, with "0 pages were selected for deletion". I wonder if we should handle this case with an error message, it seems like we shouldn't advance if the user deselected all pages - @OTichonova what do you think?

This is unrelated - I'll file another task - but I noticed the 'no new pages' error message still says 'recent changes'. We should probably change this to use the max age config value instead (e.g. 'No new pages in the past X days').

Otherwise in my testing this all seemed to work as expected!

@stjn spotted a bug!

1. Enter User A in Special:Nuke and click List Pages. User A's pages are listed.
2. Replace User A with User B in the form, and click Continue (not List Pages)
3. The deletion reason form uses User B in the deletion summary, even though we're deleting pages by User A

(I think in this case, it should show the list of pages for the new user, not the second step flow.)

In T380297#10378980, @stjn wrote:

(I think in this case, it should show the list of pages for the new user, not the second step flow.)

I'm not sure either way, actually. On the one hand, the Continue button is connected to that form group, and so it would make sense that it operates based on the contents of the filters, rather than the list below. On the other hand, I think it could be surprising to get a different list of pages on the confirmation step than you were just looking at on the previous step - for example, what if someone's browser auto-fills that field without them noticing, or they accidentally add an additional character there. They might waste time selecting which pages to delete, click Continue, and then be presented with some error (see above, this is missing) that no pages are available for deletion.

Auto-fill should be turned off on that field if it isn’t yet (from my testing, seems to be autocomplete="off" disabling autofill in JS version but not in non-JS version). I feel like it is much less surprising if something happens based on how the form is filled out than if something happens not based on that. Especially since you can always return back to the original form if you filled in something incorrectly, which should still have all the info on which pages were intended to be deleted.

Also, it would be good to have a separate error in case where user does not actually exist on a wiki but ‘List pages’ or ‘Continue’ is requested.

In T380297#10378726, @Samwalton9-WMF wrote:

Thanks folks, some observations:

If no pages are selected for deletion, the confirmation page still loads, with "0 pages were selected for deletion". I wonder if we should handle this case with an error message, it seems like we shouldn't advance if the user deselected all pages - @OTichonova what do you think?

As discussed with JavaScript -> We should disable the 'Continue' button if zero results are selected
No-JavaScript (assuming the above isn’t feasible) -> an error message message would appear (message below) and stop people from progressing to the next page.

Message

Disabling form submission buttons is a bad accessibility practice that should not be used, see https://adrianroselli.com/2024/02/dont-disable-form-controls.html and links in there. (It should probably be written down somewhere in Codex styleguide or something if it isn’t.) Everyone should just receive feedback similar to message mockup.

I would note that it is impossible to make it this way in no JS version, that can only be a separate page and not an alert message on the same page.

In T380297#10380325, @stjn wrote:

Disabling form submission buttons is a bad accessibility practice that should not be used, see https://adrianroselli.com/2024/02/dont-disable-form-controls.html and links in there. (It should probably be written down somewhere in Codex styleguide or something if it isn’t.) Everyone should just receive feedback similar to message mockup.

Hello @stjn, thank you for the comment! I updated the designs to include an on-page error message instead of disabling the buttons (as it is recommended in codex).

Test wiki created on Patch demo by Samwalton9 (WMF) using patch(es) linked to this task:
http://patchdemo.wmcloud.org/wikis/a567c1d94b/wiki/Special:Nuke

In T380297#10392567, @Chlod wrote:

Thanks, everyone! Updated the patch to include the new design changes. Please let me know if anything else should be changed.

This looks to be working as expected!

I have played around with the code in Patch Demo and locally and everything seems to be working fine! My only concern/UI question is similar to the bug that @stjn found and got fixed.

If we list a user's (Alice) created pages...

But then we input Bob and click on continue...

There is no indication that we are deleting Alice's pages, not Bob's. You can see Alice's username in the Other/additional reason dropdown, but it's nowhere else to be found.

This can confuse users who might have misspelled a username and corrected it but not hit the List Pages button again. Should we display which user's pages we are deleting more prominently? Do we think this won't happen often enough and we can ignore this edge case for now?

My gut feeling tells me this is something we should probably show a warning/error box for, but I also kinda want a second opinion on that.

I still maintain that in this case a ‘List pages’ action should be performed for the new username. Though you could also just put the name in the page title. Doing an error or a warning seems excessive.

I still think this is the better choice of the two users to pick in this case. I'm open to discussing further, so perhaps we should merge this patch and then file a followup ticket to explore further. This new layout is blocking other work so let's perfect it after merging.

In T380297#10396049, @Samwalton9-WMF wrote:

I still think this is the better choice of the two users to pick in this case. I'm open to discussing further, so perhaps we should merge this patch and then file a followup ticket to explore further. This new layout is blocking other work so let's perfect it after merging.

Sounds good to me! I have merged this and placed it in the QA column.

Change #1099306 merged by jenkins-bot:

[mediawiki/extensions/Nuke@master] Redesign Special:Nuke action flow

https://gerrit.wikimedia.org/r/1099306

You can use {{int:message name}} in nuke-tools-prompt and nuke-tools-confirm messages instead of plain "Delete" and "Continue". This can prevent confusion caused by different translations of the button's name.

An example message

Test wiki on Patch demo by SCardenas (WMF) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/064b6ee2dc/w/

Test wiki on Patch demo by Samwalton9 (WMF) using patch(es) linked to this task was deleted:

http://patchdemo.wmcloud.org/wikis/a567c1d94b/w/