Change #1037123 had a related patch set uploaded (by Catrope; author: Catrope):

[mediawiki/core@master] [Proof of concept] Special:Block ExpirationField

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

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/82915ffdd5/w

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

https://patchdemo.wmflabs.org/wikis/82915ffdd5/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/9ffcbe50fe/w

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

https://patchdemo.wmflabs.org/wikis/9ffcbe50fe/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/94b0fb3188/w

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

https://patchdemo.wmflabs.org/wikis/94b0fb3188/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/d73b641e18/w

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

https://patchdemo.wmflabs.org/wikis/d73b641e18/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/e24e0672a7/w

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

https://patchdemo.wmflabs.org/wikis/e24e0672a7/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/c0c115fe6c/w

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

https://patchdemo.wmflabs.org/wikis/c0c115fe6c/w/

Test wiki created on Patch demo by Roan Kattouw (WMF) using patch(es) linked to this task:
https://patchdemo.wmflabs.org/wikis/76ff8c28df/w

@bmartinezcalvo has made a design here, which I have prototyped in the attached patch. You can test it in this PatchDemo (log in with Patch Demo / patchdemo1).

This UI is a little different from the previous design and from what the block page currently looks like.

Advantages:

• The "other duration" and "specific date and time" options are more prominent, they're not hidden at the bottom of a dropdown or behind an icon-only toggle button
• The "other duration" option will benefit from i18n for the first time. Right now, users have a freeform text for a custom duration, but this only accepts English text. A French admin wishing to block someone for 3 days has to type 3 days; if they type 3 jours it won't work. With the number input + dropdown approach, we can translate the labels for hours/days/weeks/months/years, while still mapping those to their English equivalents behind the scenes.
• The native date picker makes it easier to choose a custom date+time than having to type it manually

Disadvantages:

• The "other duration" option is less flexible. In the current UI, the user can type just about anything that describes a duration or a point in time, and it'll be understood (as long as it's in English, see above). For example, 3pm tomorrow, next Thursday or last day of March are all accepted. With the more structured number input + dropdown approach, you can't things like that anymore. On the other hand, the date picker makes it easier to find and select e.g. the next Thursday.
• There's an ambiguity where the same value can be represented in different ways (for example, "2 days" could be selected in the preset dropdown, or entered as a custom duration). That shouldn't affect the user experience too much, but it can be a little annoying to handle in code.

Open questions:

• Are the labels for "Preset duration", "Other duration" and "Specific date and time" the right labels, or do we want to phrase those differently?
• Are hours, days, weeks, months and years the right units of time, or do we want to add other ones?

The code in my prototype works around the fact that T363416: Checkbox, Radio: Enable "other" text field has not yet been implemented. Hopefully we can get to that task soon, so that you won't have to work around the lack of official support for it.

The workaround basically consists of putting the input/select that's associated with the Radio after the Radio instead of inside it. This puts it between that Radio and the next Radio, which messes up some spacing things, so there are some hacky CSS rules to fight with Codex's desired spacing, and visually align the input/select with the Radio's label. This should work fine for now, but it should really be done inside Codex, which T363416 will address.

Advantages:

• The native date picker makes it easier to choose a custom date+time than having to type it manually

The current form has a date picker.

More disadvantages:

• Custom durations and specific date/time can be entered without any prior selection in the current UI, but a selection must be made in the proposed design. (More clicks)
• Users will no longer be able to copy and paste an expiration date/time into any of the three expiry fields.

Thanks @Catrope - this is an awesome demo. I feel like we're still giving the users all flexibility they need and putting it with a structure. This should help with technical resiliency and product resiliency over time, vs the freeform text entry, even at the expense of an additional click. And, if we look into the data, it will be easier to analyze.

I assume if the user starts to select the dropdown or the date picker, then the radio button would also get filled in, or is that an extra click?

I can't think of anything better than "preset duration and other duration" though it's not my favorite explainer text.

RE: Hours/days/weeks/months. Is Months going to be more technically complex, given that month durations change, and a block could start in the middle of a month?

In T359684#9851805, @JWheeler-WMF wrote:

Thanks @Catrope - this is an awesome demo. I feel like we're still giving the users all flexibility they need and putting it with a structure. This should help with technical resiliency and product resiliency over time, vs the freeform text entry, even at the expense of an additional click. And, if we look into the data, it will be easier to analyze.

That depends on how the data is collected. As it currently stands, everything just gets mapped to an expiry date+time in the backend. So even if the user submits the form with "2 weeks" filled out, the backend code will look at that, see that it's now May 31st at 5pm, and save the block with an expiry of June 14th at 5pm. The actual user input is currently discarded, so whether the user entered "2 weeks", or "14 days", or "June 14th at 5pm" is lost. However, if we were to capture additional data about how users are using this form (e.g. to see how often they choose a preset expiry vs a custom one), then yes we'd be able to analyze that more easily.

I assume if the user starts to select the dropdown or the date picker, then the radio button would also get filled in, or is that an extra click?

Right now, the dropdown (for presets), input+dropdown (for custom duration) and date picker (for specific date+time) are hidden unless the corresponding radio button is selected, so only one of those three things is visible at any given time. However, we could change the design so that all three are always visible, and in that case it wouldn't be hard to implement the behavior you describe (if you click the date picker, that would cause the "specific date+time" radio to be selected, etc).

I can't think of anything better than "preset duration and other duration" though it's not my favorite explainer text.

Yeah it's not great. The only alternative to "preset" that I can think of is "common". This is one advantage of having only one dropdown that contains all the presets plus options for other duration and specific date+time: we wouldn't need a term to describe the presets as a group.

RE: Hours/days/weeks/months. Is Months going to be more technically complex, given that month durations change, and a block could start in the middle of a month?

No, because we rely on PHP internals to deal with the date math. The current block form already supports freeform durations (just only in English), and you can already use months there. The issue with varying month lengths is handled just fine: if you say "1 month" and it's the 20th of the month, the block will expire on the 20th of the next month, regardless of how long the month is (so the block could be 28, 29, 30 or 31 days in length). Near the end of the month (like today) it rounds up: if you had put in "1 month" yesterday (May 30th), you'd get June 30th; today (May 31st) you get July 1st because there is no June 31st, and tomorrow (June 1st) you'll also get July 1st. This seems like reasonable behavior to me, and I think users who express the length of a block in months probably don't care that much about the exact number of days. If they did care, they could express it in days or weeks, or select an end date using the date picker.

Are we sure we want to limit custom durations to 12? That feels overly restrictive to me, especially for days and hours. I would argue for not restricting custom durations at all (except for preventing them from being zero or negative).

Re preset durations, those should use the ones configured on-wiki as the current block form does.

El T359684#9866190, @Catrope escribió:

Are we sure we want to limit custom durations to 12? That feels overly restrictive to me, especially for days and hours. I would argue for not restricting custom durations at all (except for preventing them from being zero or negative).

I suggest restricting the range of custom durations to prevent unusual (and unrealistic) combinations such as 800000 years. One potential solution could be offering limitations based on the selected options (such as "Years"). Users could first select the option from the menu and then input the desired number.