django
django copied to clipboard
django
Refs #9388 -- Added selectable monthlist and yearlist to admin calender widget
now its easy so add older dates like birthday date in admin calendar widget.
in ltr
in rtl
@ahmadekhalili Thanks for this patch :+1: All new features require an accepted ticket. Also, tests and release notes are missing.
@ahmadekhalili Yesterday | Today | Tomorrow bar should not be visible when you select the month or the year.
@felixxm Added tests and release note, fixed some issues and a bit changes in yearlist css.
in ltr
in rtl
@thibaudcolas, I have a couple of thoughts. I wonder if we could remove the datepicker at some point as the major browsers all have their own, but I'm not completely sure how well they work (timezones, accessibility, usability, ...). There was some discussion about changing the input type of date/datetime fields to use the relevant HTML5 types - https://groups.google.com/g/django-developers/c/wp-pnzcB25o/m/oNwaqc_JAQAJ - but it seemed like there were still issues. I don't know if they'd apply to the admin or not. It's something I'm planning to look at at some point.
I'm sure there are plenty of datetime pickers out there we could use, but there are tradeoffs. If we found a good one, we can kind of wash our hands of the issue to some extent. But we'd also need to keep it updated, it may change and cause unexpected issues, adding extra dependencies is annoying, and so on. For now I think it's fine to improve what we already have and hope that the browser implementations will be good enough in the future.
There's a long thread (dating back to 2018) on the govuk-design-system. They show some user research which is interesting and my takeaway is that it is hard. The final comment references some fairly recent user research and shows that browsers datepickers still have issues.
It seems to me there are positive comments about having both a text input and an optional date picker. Which I think is what the admin does?
https://github.com/alphagov/govuk-design-system-backlog/issues/17
That's a very interesting thread, thanks for the link.
One thing I found especially interesting is that if you're dealing with a date the user already knows (such as a date of birth) they advice to just use a text box (or rather one for day, month, and year). It seems they only use a date picker if it's a date the user doesn't know, such as when making an appointment, where knowing the day of week is useful.
I'm not saying we should follow this advice necessarily, but I did find it an interesting separation of use-cases. It's a shame the native date pickers aren't accessible - has anyone done a more recent audit? What's linked to is a few years old now.
I dont know about different use cases in detail but there are several date pickers like: https://duetds.github.io/date-picker/ https://mengxiong10.github.io/vue2-datepicker/
but in my experience something like:
https://vuetifyjs.com/en/components/date-pickers/#usage
is more clear, simple and friendly for general cases. i also added "changing input when only clicking on a month or year" for example when you click on a month in monthlist box, input will fill with current year-clicked month-current day, means you don't force to clicking on a day to filling input and is useful when you only need month calendar or year calendar.
I think just using a text box for birthday is not something admin users like, because dates can have different formats like y/m/d y-m-d y-d-m or years with 2 digit or ....) and new users don't know which of them should be, so typing dates seems not good. but native date pickers even more and better styles and actions is something we need in future.
Yes, when entering a date the user knows already (rather than picking a day) I believe there’s consensus that text input is better. That does mean the input has to validate the entered date format, and support entering the date (and displaying help text) in the user’s local date format.
Accessibility-wise it’s also important to provide options whenever possible – so supporting users entering dates either with text or a picker is very valuable. This PR looks excellent in that respect, notwithstanding the issues with the base picker.
It seems to me there are positive comments about having both a text input and an optional date picker. Which I think is what the admin does?
Yep.
For the native input type="date", a11ysupport.io has test results from 6 months ago. It’s worth bearing in mind Safari’s support is very recent: Safari 14.1. It looks like desktop Safari versions below 14.1 account for about 1% of the global browser market share.
If we wanted to consider more seriously we could look at the time field / widget first – the current widget has clear issues, there’s also a native control with similar browser support considerations, and entering times as text is simpler than dates – no need to translate between days of the week and dates as with the date picker.
@felixxm failing checks is out of my codes and need rebase but i pulled on main branch so can't rebase. should i recreate PL?
@felixxm failing checks is out of my codes and need rebase but i pulled on main branch so can't rebase. should i recreate PL?
You should be able to rebase from the main branch :thinking: I did this for you. Use git pull --rebase to get the rebased version locally.