Open janett-baresel opened 6 months ago
Design expertise sought for the following expertise 🧠 :
"yes"
to #1
above, should we populate more dates from the previous month? @SkyeSeitz @macandcheese This is an example from Atlassian where both of @geospatialem's questions are answered "yes". There calendar always has 6 date rows we can see that the entire bottom row here is from the next month.
I agree with moving forward with a fixed height shared between months. Open to displaying the next month's dates in additional space for shorter months - a better use of space imo than leaving a potentially awkward gap. Thanks, @geospatialem and @ashetland 🙌
Check existing issues
Actual Behavior
When flipping through the months the picker changes height due to how many rows a particular month needs. This is not ideal when the button for next/previous moves up and down in certain scenarios. It is even worse if the changing height triggers different position of the popover above or below the control. (see 2 gifs). This also can happen when changing to the next year, where the months might be shorter or longer (in number of rows) than before.
Expected Behavior
The popover stays at the same place and doesn't change height so the above doesn't happen and users can seamlessly switch between months and years.
(One suggestion would be to have a consistent height, e.g. always 6 rows)
Reproduction Sample
https://developers.arcgis.com/calcite-design-system/components/input-date-picker/
Reproduction Steps
<div style="height:350px;"></div>
above pickerReproduction Version
2.8.0
Relevant Info
os and browser independent
Regression?
No response
Priority impact
p4 - not time sensitive
Impact
minor - just bad UX for people setting up a lot of dates for different layers. This becomes visible because SV (and MV) allow setting a visible time extent for any layer. Users will set up time ranges for multiple layers in a row and this UX makes it harder to quickly navigate to a given date.
Calcite package
Esri team
ArcGIS Scene Viewer