search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
145 stars 40 forks source link

[UX] Improve the description of the "Time zone handling" field #6596

Open stpaultim opened 5 months ago

stpaultim commented 5 months ago

Description of the bug

"After most of a decade away from Drop-oriented CMS's, today I couldnt figure out what exactly I was being asked to decide for "timezone handling" without digging into the code base. Hopefully this minor change will help others understand that this choice is primarily about display of timezones, and not the database storage."

Issue and PR submitted by @matt2000 https://github.com/backdrop/backdrop/pull/4781

Steps To Reproduce

Actual behavior

Before PR image

Expected behavior

From PR: image

Additional information

stpaultim commented 5 months ago

Thanks @Matt2000 for reporting this and supplying a PR.

I THINK this change makes sense. Could someone else confirm that if changing "Date's time zone" to "Server time zone" is an accurate change?

@indigoxela Does this look correct to you?

klonos commented 5 months ago

This is confusing indeed. From a UX perspective, I would prefer that these options were a radio set, so that each one of them can have its own, separate description text.

klonos commented 5 months ago

...FWIW, in Drupal, the respective setting is in the "Manage display" for the field, it is called Time zone override and it only offers the following options:

image
klonos commented 5 months ago

Could someone else confirm that if changing "Date's time zone" to "Server time zone" is an accurate change?

I would first have to look at what the code for each one of these options actually does in order to provide a more informed opinion.

indigoxela commented 5 months ago

What the "Date's timezone" is: this is an additional form item in the field widget, that allows setting the timezone per item. So "server timezone" gets it wrong.

Here a screenshot from the field setting and the resulting field widget:

dates-timezone

To further clarify: the "Site's timezone" is the per-site setting on admin/config/regional/settings (Regional settings per site, not server timezone).

klonos commented 5 months ago

OK, please don't stone me to death for changing too much - I will split this to separate issues/PRs as needed. I just wanted to fix certain inconsistencies in the UI and the code + some additional UX nitpicking.

So here's a PR that changes this to a set of radio options, each one with a separate help text: https://github.com/backdrop/backdrop/pull/4782

image

@indigoxela thank you for providing all of the clarifications in your previous comment - that saved me a lot of time 🙏🏼 ...since you have extensive experience with dates and date fields, I'd like to get your thoughts on the labels of the radios and their descriptions. Do they make sense now?

Also @matt2000, does that make it easier for you after that decade away from Drop-oriented CMS's?

avpaderno commented 5 months ago

I spotted a typo: Uses the time zone configured in the "Region and langugage" setting of each user account.

I like there is an explanation of every single option and the default time zone value is shown too.

indigoxela commented 5 months ago

thank you for providing all of the clarifications in your previous comment - that saved me a lot of time

Glad to help. :wink:

you have extensive experience with dates and date fields, I'd like to get your thoughts on the labels

I don't feel qualified to verify the meaning of label texts, as for me English is a foreign language.

Re UI change. One disadvantage is, that this previously tiny form section with only a dropdown, with the most common use-case pre-selected, is now huge an looks way more complicated than before. It makes people think hard, where they previously simply skipped over. "The website's timezone" is the most common use-case and the right decision ~90% of the time.

But as this is a UX issue, I quickly jump out (unfollow) and try to stay out of the way. :grin:

klonos commented 5 months ago

Thanks @kiamlaluno 🙏🏼

I spotted a typo ...

Yeah, CSpell caught that too ...I call these things like "languGage", which I type more often than I'd like, "typing impediments" 😓 ...I have a growing list of 'em too.

klonos commented 5 months ago

... this previously tiny form section with only a dropdown, with the most common use-case pre-selected, is now huge an looks way more complicated than before. It makes people think hard, where they previously simply skipped over. "The website's timezone" is the most common use-case and the right decision ~90% of the time.

Hmm 🤔 ...I hear you. I'll think some more about it and see if I can come up with anything better.

What we had before was obviously more compact and less "noisy", I agree. But the various options were confusing at the same time. Perhaps people were skipping these before because they didn't understand them, or they thought they did something entirely different from what they actually do ...especially in the case of the Date's time zone option: you'd either have to guess what it does, or go look at the code to figure things out - that's not right at all.

And with the No time zone conversion option, the entire explanation was only available in the docblock of the date_timezone_handling_options() function:

 * Timezone handling options.
 *
 * The 'none' option will do no timezone conversions and will store and display
 * dates exactly as entered. Useful in locales or situations where timezone
 * conversions are not working reliably, for dates with no times, for historical
 * dates where timezones are irrelevant, or anytime conversion is unnecessary or
 * undesirable.

It is bad UX to explain all options in the description of entire radio/checkbox sets - that's why we have the feature of allowing individual descriptions for each option in the first place. Putting that aside for a moment, in order to consider alternatives...

Lets assume that we put all that explanatory information in a single help text, and leave the drop-down select menu. Here's a quick mockup of what that would look like:

image

Besides being huge/ugly and everyone skip reading it, clicking the menu would expand its options over the help text and hide it:

image

So in that case, people new to this would need to get in a repeated loop of clicking the menu to show/hide it, then read each option, then read the description. That's bad UX 👎🏼

...an improved version of that would be to have the help text be a list, with each option already highlighted as part of the help text, like so:

image

That would allow people to read the help text first, decide which option they want to select, then select the option from the menu. Still, the "noise" in that form would be about the same as with adding individual help text to each item. So why go that way then?

Another consideration would be to follow the same pattern as we do for the "Show examples" <details> element as we do for the help text when configuring layouts, which allows the help text to be shown/hidden: image

Here's what something like that would look like:

Is that better? ...worse?

avpaderno commented 5 months ago

Radios are also used on /admin/config/development/jquery.

screenshot

IMO, they are the "best" solution when the options are mutually exclusive, and they each have a description: There is no need to create an unordered list for the descriptions, since the radios themselves make it an "unordered list," and it works even when JavaScript does not work.

Using a better example, on /admin/config/search/settings, where saving space could have been more important, radios are used.

screenshot

avpaderno commented 5 months ago

Actually, there is a reason for preferring radios even when the single options do not have a description: If the single options cannot be guessed knowing a single option, radios should be used; otherwise, they should not be used. (At least, this seems the criterium used in Backdrop core user interface.)

To make an example with forms currently used from Backdrop core:

Where radios are not used, the options are "predictable": a country name, a weekday, a time zone, an interval (in hours?).
Eventually, I could need to check all the options to understand how much complete (or correct) the list is, or how much granular the list is, but I already know I am asked to choose a country name in a list of countries, a time zone from a time zone list, and an interval (in hours?) from a list of intervals.

klonos commented 5 months ago

Where radios are not used, the options are "predictable" ...

Yes. That, plus also when the list of options is extremely lengthy (which would cause the form to be long and require a lot of scrolling), which is the case with the timezone/country lists.

@kiamlaluno I've fixed the typo, so the PR is ready for a review now.

Here's a summary of what else the PR changes:

  1. Since the radio (previously select) options were provided by a separate date_timezone_handling_options() function, I followed the same pattern and provided the descriptions for these options in a new date_timezone_handling_options_descriptions() function.
  2. Removed a couple of instances of the $description variable in _date_field_settings_form() where each of these variables were only used once.
  3. Moved the Cache dates setting and its dependent Maximum cached dates per field setting above the Time zone handling method settings. That was done because the setting seemed to be visually "blending" with the radio options when it was placed after them. The bolded label of the radio set now acts as a better "visual separator".

There's definitely one thing that I would like to fix in a follow-up: #6597 (which should include point 8 above if we don't fix it here). Please let me know which of the rest of the changes are big enough that should be split out into separate issues.

avpaderno commented 5 months ago

Could we limit the changes to the descriptions used in that form, and leave the other changes for other issues?

klonos commented 5 months ago

Surely can 👍🏼 ...I'll file separate issues and I'll update the PR.

docwilmot commented 5 months ago

I think @klonos PR is an great improvement. As a matter of fact, could probably use even more explanation there. I had to stare at each option quite a while to try and figure out what they were actually saying. "Use the "Default time zone" setting"? That means whatever date is chosen in that field, display what? Still hazy. Thats just me though.

klonos commented 5 months ago

Could we limit the changes to the descriptions used in that form, and leave the other changes for other issues?

@kiamlaluno I've split the other changes into their own follow-up issues:

Now the PR for this issue here is limited to changes in only one file (down from 6), and should be much simpler to review.

The only additional change I left in is the reordering of the "Cache dates" checkbox within the form. If it is left at the end of the form, immediately after the set of "Time zone handling method" radios, visually they appear as if they are part of the same form element. Here's before after screenshots to show what I mean: image

With the reordering in the left screenshot, the bold label of the radios acts as a "visual separator". That's why I believe that we should leave that change in.

Thoughts?

PR ready for another set of review.

avpaderno commented 5 months ago

The only additional change I left in is the reordering of the "Cache dates" checkbox within the form.

That change is still pertinent with this issue. (At least I consider it as "move the Time zone handling method options after the Cache dates option.")

avpaderno commented 5 months ago

I checked the preview site. All is good, for me.

klonos commented 5 months ago

This issue was discussed during today's Design/UX meeting, 35:28 into the recording: https://youtu.be/l2SAcL907AQ?t=2128

So @wesruv was added to the people that like the approach of the separate radios + individual help text. However, for the sake of allowing people to compere the UX/design with an alternative, I'll file a separate PR that explores the idea of a toggle and an expanding/collapsing help section. We can then decide which one would work best.

Also, based on the clarification around how bug milestones can be set, which was discussed during the dev meeting later, I'm adding a milestone here.