Click on a date picker, change the year and click on apply. The year on the widget does not change.
Yes, that does appear to be the case! Bug raised in our issue tracker, we’ll get it sorted. Thanks for the report.
On further inspection, you can actually change the year, but you have to pick a new date in that year.
If you have 30th Jan 2018 selected and you change the year to 2012, it doesn’t automatically choose 30th Jan 2012 (and if you have 30th Jan 2018 selected and you change the month to Feb, it doesn’t have to deal with that ambiguity).
This is the same way that Google Calendar’s Date Picker behaves.
So it’s not broken, although the UX can probably be improved here since it wasn’t obvious to either of us!
At first I didn’t understand why your animation looks different from mine, then I realized that I had the pick_time checked.
You can reproduce the problem by:
- set
dateto a valid date and time - check
pick_time - run the app
- click on the date picker
- change the year
- click on apply
-> it doesn’t apply the change of the year
It is not a problem when pick_time is not checked because there is no apply button, but it does become a problem when the apply button is there.
If you modify your workflow to
- set date to a valid date and time
- check pick_time
- run the app
- click on the date picker
- change the year
- select a date from the dates presented to you
- click on apply
-> it doesn’t apply the change of the year
Then it does register the date selection.
We should definitely improve the UX for this given that two perfectly intelligent people (yes, I’m including myself in that) are struggling with it!
Don’t us thick people count?
Thick-ist!!
1 Like
Well… I can’t tell the users to change their workflow because my apply button doesn’t really apply.
I noticed a form with a date and time where only the year was wrong. I clicked on the date picker, changed the year, clicked apply and it didn’t work.
I tried again and I noticed that the date is lost after clicking the year, but I didn’t remember the date. So I had to close the form, reopen it, read the date, change the year and reassign the date.
Way too much work for something that should just remember the date when you change the year.
Or, if there is a real use case for forgetting the date, then it should not allow to apply a date when there is no date selected.
I’m sorry if it sounded like I was saying you should get your users to change their workflow. The DatePicker UI needs to be changed so that users can easily see how it works. I was just trying to figure out if this is ‘not working’ vs. ‘not clear how it is supposed to work’.
If the date is lost then we are looking at a functionality bug! What did you do to make that happen?
If I do
- open DatePicker
- select different year
- go back to original year
The original date is still selected for me.
Oh, now I finally understand how this thing works!
When you pick the month or the year you only change what’s shown on the date picker, not the value of the date, duh!
I still think it’s bad UI design: there are 5 interaction elements, the first two (hour and minute) change the value, the next two (month and year) don’t, the last one (day) does.
I looked at a few datepickers on different websites (just a few) and they don’t have the apply button. They all force you to pick a date after changing the month or the year, just like Anvil’s datepicker does without pick_time checked. When they ask for both date and time they are split in two, one date picker and one time picker.
I think that when you select a new year or a new month the value of the year or of the month should change just like it changes when you select a new hour or a new minute (rounding the day to the nearest available day when required).
A different approach (that I don’t like) would be removing the apply button and adding a time picker as a separate form.
1 Like
That’s a good appraisal of the sources of confusion: the apply button, and the difference between {hour, minute, day} and {month, year} behaviour. Thanks, that’s really useful feedback.
I’ve created a ticket in our issue tracker about this, and it’ll get prioritised in the usual way.
1 Like