[UX] Improve editing data and time format patterns

[sutibun]

Dealing with typing archaic letters to get a specific date/time pattern is just wrong. And a link to a PHP manual is not the answer... unless you're a programmer.

Some options

• there should be a list of common examples on that page (e.g. how do I add am/pm)
• Replace the PHP.net tutorial link with one on bdcms.org that explains it better
• get away from having the user deal with PHP stuff. Provide some kind of drag and drop or GUI to help. Not sure what at the moment.

This always takes me time to figure this out.

[docwilmot]

How about a link below the "Format string" textfield that opens a dialog like Token dialog which says "Select from common patterns" or similar. Then in that dialog, we dont show the "archaic letters" at all, just:

Sample formats:

• 10/12/2015 - 01:56
• 12/10/2015 - 01:56
• 10/12/2015 - 01:56 PM
• 10/12/2015 - 13:56

Etc. User clicks one, it prefills the Format string textfield.

Alternatively, remove the textfield display and have a select list display all common display formats. Have an "advanced configuration" link below the select that allows you to use the archaic letters to build custom formats.

[sutibun]

I'm down with either one.

Hmm... maybe let's go with the latter one, as it hides the archaic letters from the default view but still allows advanced users access to them in the "advanced configuration"

[ghost]

For the record, here's what WordPress seems to do:

(Source: https://wordpress.org/support/article/formatting-date-and-time/)

They don't appear to give very many options, but I like how they separate date and time formats (so you don't have to account for each permutation thereof).

I started working on a PR for this, but I realised that giving options to select the date format separate to the time format means you'll also need to allow specifying the separator. Then do you have two 'Custom' options for date and time, or one for both combined?

If we can work out the best UI for this, I can continue work on a PR.

[klonos]

Yes 👍 ...offering a few commonly-used formats as pre-configured selections seems nicer UX (+ the ability to define a custom one of course).

Alternatively, we could provide a UI similar to the one for browsing and adding tokens, via point-and-click (see the "Browse available tokens for Content." link in /admin/config/urls/path/patterns).

[ghost]

I like the idea of showing the raw format in some sense (like WP does). That way, if someone likes one of the preconfigured formats but wants to change one part of it, they can see the raw text and use that as a basis for their custom format.

The problem is how...

1. Have a single select list or set of radio buttons showing all pre-configured full-date/time formats
2. Have separate select lists or sets of radio buttons for date formats and time formats

The problem with 1 is that you have to account for each variation of each format. So if we decide to pre-configure six date formats (short, medium and long in both d/m and m/d order), and pre-configure two time formats (12 and 24 hour time), that means there needs to be a total of twelve preconfigured formats. This might seem overwhelming and/or hard to tell the differences between all the options.

The problem with 2 is that you need to allow a way to specify the separator between the chosen date format and time format, and you need to allow custom options for each too. This'll add a lot more fields to the form and could create a confusing UI.

So I think a good compromise is what @docwilmot and @klonos suggested: keeping the single textfield for custom date/time format, but adding the ability to insert preconfigured options from a token-like modal list.

This solves both problems listed above: we can separate date formats from time formats in the modal (and users can insert one of each) so this prevents a single long list of options, and there's already a way for users to enter a custom format for both date and time and the separator (or even edit the pre-configured ones) using the existing field (no additional fields needed).

I'll see if I can start work on a PR to that effect...