Talk:Community Wishlist Survey 2023/Multiblocks

Archives /Archive

It's great you are here.

Thanks for your interest in discussing or following discussions on the Multiblocks wish. We endeavor to respond to you within 48 hours.

Notice for Codex Special:Block Testers

As we prepare to fulfill the Multiblocks wish (the #14 wish from the 2023 Community Wishlist), Community Tech has redesigned the Special:Block page using Codex.

• You are invited to test the refreshed block page on testwiki when we deploy. If you need Administrator rights to do this, request it below.

• Alternatively, there is also a simpler method to test on your local wiki by adding ?usecodex=1 to the end of the URL to your local blocking page.

Thank you –– STei (WMF) (talk) 18:05, 30 January 2025 (UTC)

• User
• User
• User
• User
• User
• User

Feedback

Thanks for providing the option to test the new interface of Special:Block. Some thoughts:

• When I open Special:Block, I usually want to block a user. The actual block interface should load right away, instead of initially just showing those collapsed sections.
  • I'm assuming that the block interface doesn't load right away because it's not clear which block options are supposed to be modified (or if I want to modify an existing block vs. issue a new one) once multiblocks are enabled?
  • The block interface should therefore at least load right away for accounts with no active block -> in that case it's clear that I just want to issue a new block.
• The "active blocks"-section should not be collapsed per default if there are active blocks. I want to see right away which currently active blocks there are.
  • If I saw it correctly, the section stays uncollapsed once I opened it, that's positive.
• The "edit" and "remove" options for blocks should probably appear as a button, similar to the "add block" and "remove all" buttons, to make it more obvious that this is not just some text in a table row, but important options to modify active blocks.

Johannnes89 (talk) 06:18, 1 February 2025 (UTC)

Hello @Johannnes89, thank you for testing and for sharing feedback so quickly. The suggestions have been well noted. –– STei (WMF) (talk) 15:48, 3 February 2025 (UTC)

Feedback from Quiddity

As an admin who is usually trying to understand the past context of an account (and less frequently doing the account-blocking directly), and as someone who generally uses a laptop with a single screen and tiled windows side-by-side, I'd suggest a few changes:

• Uncollapse the "Block log" permanently. I always want to see this often crucial background info, and the current design is identical for users with and without a block log, except for the tiny number. (Screenshot-1 and screenshot-2) -- Even if it was visually more-obvious (like a colored number, or colored bar), I still wouldn't want to have to manually uncollapse the section in order to see the details.
• Design tweaks for the Block log table (which I appreciate! It's potentially clearer than a single line) - I suggest using visual lines to separate the columns, instead of just white-space. That should make it possible to reduce the quantity of white-space, and thus resolve some of the extensive line-wrapping that is occurring for me in a tiled window, and especially in languages with longer words and strings (Screenshot-3)
• Timestamps - Use 24hour time for the Timestamps, to eliminate the need for "a.m."/"p.m." strings, and to be consistent with the times displayed everywhere else (IIRC?).
  • Perhaps remove the "UTC" string too?
  • Perhaps the "seconds" value could be a smaller font? It's normally irrelevant, and we don't show seconds anywhere else (IIRC?) so is mildly confusing, but I understand it can be relevant in rare circumstances.
  • User-prefs: These timestamps also don't currently seem to be matching my user-preferences (which are normally default/UTC, but I tried changing it to a different local time, and the Block page didn't adjust).
• Links to the userpage/talkpage - Replace these somewhere. Perhaps at the top of the page, with the new location of the "Contributions" link? They are useful for both accessing the pages in order to read or write, and it's useful to be able to see redlinks vs bluelinks for the various contexts that provides (Screenshot-4)
• Expiry - For the "Expires" column, it is useful to have the exact length of an auto-expiring block shown, because some communities/workflows/contexts use a process of incrementing block-lengths for repeat problems (1 day, 2 days, 4 days, etc), and it's easier to read "1 week" than it is to have to mentally calculate the gaps between two timestamps. Perhaps it would be feasible to put both pieces of information in the column? (Screenshot5)
• +1 to all of Johannnes89's comments.

I hope that helps! Quiddity (talk) 21:29, 4 February 2025 (UTC)