Open emaurer11 opened 7 months ago
All the links in this request are private P2s. This does not seem all that transparent, and it might be advisable to keep the discussion to internal P2s since nobody beyond Automattic employees has visibility into the full context.
Thanks for sharing your mockups of this. I believe we'll need this for Data Views so it makes sense to add this feature to @wordpress/components
.
Just to make sure we're on the same page — we are buildling a new DateRangePicker (name TBD) that is two DatePickers linked together with range selection functionality. Everything else in the mockup is extender territory.
We'll probably need to change the "selected date" indicator in DatePicker itself from a circle to a square so it translates better into a range selection scenario.
Exploring this one from a slightly different angle, based on the idea that a date range picker component could just be two instances of TimePicker
(itself utilising the native datetime-local
input type):
SelectControl
contains any preset optionsTimePicker
are revealed. These are used to set the From and To datesHere's how this might work in a filtering situation:
Coming back to this one with some updated designs, still built upon native input types but augmented with calendar UIs.
This design would make use of the Menu
component for the UI and would be handy for quickly filtering certain data views.
This one could potentially be two instances of TimePicker
. For use where a permanently-visible calendar UI is not useful or would be too prominent.
As above, but augmented by a permanently-visible calendar UI. For users of assistive technology (and perhaps folks who prefer navigating by keyboard) I suspect the native inputs to be the primary point of interaction, but for mouse users the calendar would be more ergonomic.
The following are more advanced combinations of the above. In each case the inputs / calendar would be revealed only when electing to specify a custom range rather than a preset.
This one is very similar to the design in the OP. The calendar interactions could be the same.
a permanently-visible calendar UI
By displaying the native range picker UI we'd get a lot of functionality for free — but if, in any case, we need to show an interactive, rich calendar UI, then it would make sense to use that UI also in the "Simple date range" case (and, why not, for any date picker, even when not selecting a range.
IMO, using the native date picker UI could only make sense for these scenarios:
Also, I have a couple of questions:
What problem does this address?
The current component does not:
What is your proposed solution?
cc @noisysocks