[ Question ] Month/Year selection controls

[michaelwarren1106]

month select

Currently the month and year selects have a super minimal approach, so I wanted to ask your thoughts on how a new design for those controls might improve user experience (and also help me be able to implement my own date picker input design using this calendar component :) )

The month select is a simple select box, but I have also seen design and options where the month selection is a group of buttons that the user can click to select the month they want.

IMO, there's not a major design issue with using a select, other than its hard to style a native select, so it might stick out as being "plain" in an otherwise modern looking style when implemented by a consumer. A group of buttons (along with relevant css vars/parts) would allow for a clean consistent style.

year select

IMO the year select being a <input type="number"> presents some more challenges and changing it up might offer some greater UX features to us consumers. if the year select was changed to a button group/list as well, that would enable new features like setting an allowed year range for the picker. Currently, with the input approach, there's no way I can see to disable certain years from being selected? Something like below would allow for more styling and also disabling years from be selected or paged to:

Another benefit to the button group approach is if the range of allowed years is super wide. Like if the calendar is used in a birthday input. Birthday years probably go all the way back to 1910 or something like that? Having all the year values from 1910-2022 in a <select> makes a silly tall select dropdown that has to be scrolled, etc. The button group approach, implemented with paging and possibly next/prev year buttons can allow for fast switching to years well in the past/future without ever creating a weirdly long select dropdown. I'd also wager that button groups are easier to parse/read for humans eyes, because they would be spaced out with more whitespace, etc.

Anyway, I just wanted to get your thoughts on these features!

[break-stuff]

Can you explain the design a bit? Would these button groups show up in a separate dialog that would overlay the calendar dialog?

[michaelwarren1106]

sure!

i was thinking that when you click whatever control ends up being the “select year” function (maybe a button?) the grid of days (1-30 for the current month) would get replaced with the grid of current years in the range of enabled years. and the “next month” and “previous month” buttons (from the previous view of the grid of days) get replaced by the “next years grid” and “previous years grid” buttons.

same for the month select button except simpler. when the “choose month” button is clicked, the “grid of months” replaces the grid of days. but there’s no need for any “next months grid” or “prev month grid” buttons because there’s only ever one grid of months.

that’s what i’ve seen most often with calendars.

imo the grid of months is easy because it can be relatively static. the months are always in the same order and there’s always the same amount, so you could make that whole grid pretty much a constant.

the grid of years would need to be calculated depending on how many years you’d want to display per pane.

an example would be UI5 calendar from SAP: https://sap.github.io/ui5-webcomponents/playground/components/Calendar/

i hope that makes sense!

[michaelwarren1106]

hey hey, bumping this (and the other) thread! Would you be open to accepting PRs for these features/redesigns?

[break-stuff]

I would like to keep this as simple as possible initially. My first thoughts are that this will create a decent amount of complexity to the component. My primary goal for this component has been to make it as light and as accessible as possible.

I'm worried this will dramatically increase the size of the component as well as make the accessibility and keyboard UX more difficult.

[michaelwarren1106]

ya i get that! I think that the month selector wouldnt have to add much more complexity, since its just a static tabbable list of the same 12 months all the time. IMO the part to worry about is the year selection right?

My main concern with the year selections is the UX of selecting a single year from a super wide range of years via a . IMO, if the range of selectable years is like 100 years long...then that select basically scrolls completely off the page in both directions. In general, I've found that selects with super long lists of options (think selecting year, county, country, state, etc) should be avoided because we currently cant do much to style tags. So we cant really improve the UX of a select cuz its all OS based etc.

If we just repeated the same a11y features for the year select as with the day selection, that could solve for keeping a11y tight. Adding another tabbable section like the day select for year selection would make the component a little bigger though.

break-stuff commented 2 years ago

The challenge I see is that if I want to go to year 1972, and have to arrow through 50 years to get where I want to go. Having an input is much more efficient and light weight. It also provides more flexibility since I don't have to limit years or provide paging. It seems simple to add that, but there will be a nontrivial amount of work and code to make that work.

break-stuff commented 2 years ago

For these selectors, do you envision them to display instead of the calendar or overlay over the top?

michaelwarren1106 commented 2 years ago

imo it could be either way. i was thinking they’d replace the calendar, but over the top would work too? you wouldn’t be able to see any of the days behind the other selections so ostensibly it’s the same right?

michaelwarren1106 commented 2 years ago

i just had a thought about year selection. imo with a large range of years it’s going to be messy almost no matter what you do because there’s so many options to choose from. i wonder if it would be beneficial to offer more “skip to” buttons that skip back more than one page, so if a page had 20 years on it, and there was a “go to 1910” button that skipped all the way to the beginning that would help. more buttons take up more space though

this is kinda what makes datepickers so hard, there’s such a wide range of what they can be used for

break-stuff commented 2 years ago

Maybe I'm missing something, but I still think the number input is the most accessible, lightweight, and flexible option. Trying to predefine the options creates too much complexity and ultimately hampers the user experience.

michaelwarren1106 commented 2 years ago

yep, i agree! no argument about that. my only gripe is that a select is the least visually appealing option. you can’t beat it in terms of a11y or simplicity, but there’s just no real way to make a native select’s options look good and having a js-based drop down is bloat imo

so im trying to balance the a11y and ux with the visual design side also :) with large date ranges there just aren’t any really options haha

i would even propose an input[type=number] but then you have validation issues when folks type a year that’s not allowed. well maybe? you could just leave error messages for the whole input and not display any in the picker window. if there weren’t any error messages then the only concern would be what to set the number step to be. that would need to be configurable because having a step of 1 for large year ranges would be awful haha

i’m kinda just spitballing to see if we can come to an idea that is both simple/usable and also stylable to work with large year ranges

break-stuff commented 2 years ago

I'm ok with leaving as a select for now. This will likely be the least used control in the calendar.

michaelwarren1106 commented 2 years ago

i get it. fair enough. I'll chat with our designers. if they come up with something simple and light, i'll post here and we can discuss?

break-stuff commented 2 years ago

Absolutely!

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[break-stuff]

The challenge I see is that if I want to go to year 1972, and have to arrow through 50 years to get where I want to go. Having an input is much more efficient and light weight. It also provides more flexibility since I don't have to limit years or provide paging. It seems simple to add that, but there will be a nontrivial amount of work and code to make that work.

[break-stuff]

For these selectors, do you envision them to display instead of the calendar or overlay over the top?

[michaelwarren1106]

imo it could be either way. i was thinking they’d replace the calendar, but over the top would work too? you wouldn’t be able to see any of the days behind the other selections so ostensibly it’s the same right?

[michaelwarren1106]

i just had a thought about year selection. imo with a large range of years it’s going to be messy almost no matter what you do because there’s so many options to choose from. i wonder if it would be beneficial to offer more “skip to” buttons that skip back more than one page, so if a page had 20 years on it, and there was a “go to 1910” button that skipped all the way to the beginning that would help. more buttons take up more space though

this is kinda what makes datepickers so hard, there’s such a wide range of what they can be used for

[break-stuff]

Maybe I'm missing something, but I still think the number input is the most accessible, lightweight, and flexible option. Trying to predefine the options creates too much complexity and ultimately hampers the user experience.

[michaelwarren1106]

yep, i agree! no argument about that. my only gripe is that a select is the least visually appealing option. you can’t beat it in terms of a11y or simplicity, but there’s just no real way to make a native select’s options look good and having a js-based drop down is bloat imo

so im trying to balance the a11y and ux with the visual design side also :) with large date ranges there just aren’t any really options haha

i would even propose an input[type=number] but then you have validation issues when folks type a year that’s not allowed. well maybe? you could just leave error messages for the whole input and not display any in the picker window. if there weren’t any error messages then the only concern would be what to set the number step to be. that would need to be configurable because having a step of 1 for large year ranges would be awful haha

i’m kinda just spitballing to see if we can come to an idea that is both simple/usable and also stylable to work with large year ranges

[break-stuff]

I'm ok with leaving as a select for now. This will likely be the least used control in the calendar.

[michaelwarren1106]

i get it. fair enough. I'll chat with our designers. if they come up with something simple and light, i'll post here and we can discuss?

[break-stuff]

Absolutely!