Unifiy approach and design of date-/timepickers throughout the UI

[reiferschris]

In the UI there are multiple places where a date-/timepicker is used, they are not always consistens in look & feel

This is a collection of the various styles and behaviors:

Main filter in Events/Series View:

• Notes
  • grey hover animation on calender symbol
  • grey highlight on selected date
  • selecting one date automatically prefills the other field with the same date. This can be e.g. annoying when selecting a bigger time range up to today and having to back to today in the second field

Date-/Timepicker in event metadata start date:

• Notes
  • calendar symbol has a circle around it and a round hover animation
  • hour and minute picker are a bit cumbersome to scroll and the scrollbar partially hides the contents, minutes can only be adjusted in 5 min steps
  • scrolling past the end (e.g. 23) is possible and leaves a lot of unneccasary whitespace
  • blue highlight on selected date
• personal opinion
  • I'm not a huge fan of the scrollable time list, not sure though what could be better. Do we have other options that library(?) offers?

Add new scheduled event datepicker

• Notes
  • same as datepicker in event metadata

Add new scheduled event timepicker (schedule multiple events looks the same) except for the date

Event details - scheduled event

• Notes
  • Timepicker does not display minute or hour if it is 0 (happens in duration as well as start and end time) Issue: Event Scheduling: "00" not correctly displayed #611

Edit (multiple) scheduled events

• Notes

  • same look as event details
  • adjacent bug: Edit multiple events of the same series are no more grouped by day of the week #533

  I hope I didn't forget anything, if so please let me know.
  Also please express your opinions as to which style you prefer like @Arnei suggested

[kruemelm0nsta]

for scheduling I would recommend 1-minute time steps

[snoesberger]

For the following reasons #920 (comment) it might make sense to replace the current MUI DatePicker with another date picker that offers more (free) features.

[snoesberger]

For the following reasons #920 (comment) it might make sense to replace the current MUI DatePicker with another date picker that offers more (free) features.

In this repository I can see the import of another date picker: react-datepicker which is never used (or maybe was used in the past?). The react-datepicker, is free of charge and seems to have all the necessary features like date-range picking, time picking, localization etc. According to the GitHub repository it is also widely used and maintained. To me, it looks like the react-datepicker could be a good replacement for the MUI DatePicker. This is what it will look like with the default design in place:

If no one has opinions against the react-datepicker, I'm willing to start replacing all MUI DatePicker occurrences in the admin UI with the react-datepicker and propose a PR with the changes (and at the same time guarantee a consistent design and address other issues with the date picker #920 #948).

[marcusm7]

If no one has opinions against the react-datepicker, I'm willing to start replacing all MUI DatePicker occurrences in the admin UI with the react-datepicker and propose a PR with the changes (and at the same time guarantee a consistent design and address other issues with the date picker #920 #948).

I would like that.

I can't say much about the implementation side of this library and how it fits with the rest of the admin-ui.
But from the user point of view, the range picking and the keyboard hotkeys (enter to select, navigation: cursors, pgup/down for month, shift+pgup/down for year) are nice - https://reactdatepicker.com/#example-date-range.

[Arnei]

Is there still work left on this issue? Could you please detail what problems you still have and what you would like to see?

The one thing that is immediately obvious to me is that we still have seperate dropdowns for the time selection for scheduling. I only took a brief look at react-datepicker, but it seems to me that is simply something it cannot do.

[snoesberger]

Is there still work left on this issue? Could you please detail what problems you still have and what you would like to see?

The one thing that is immediately obvious to me is that we still have seperate dropdowns for the time selection for scheduling. I only took a brief look at react-datepicker, but it seems to me that is simply something it cannot do.

The react-datepicker could be used as time picker only, but for the duration field we would still need a separate solution. Personally I don't mind if this part stays as it is (also because we don't need an external library for it).

One place where the MUI DatePicker is still used is in the statistics component. Once we replaced the date picker there, we could remove this external dependency completely.