Date/Time Range Filter

[emaurer11]

What problem does this address?

The current component does not:

• select date ranges
• allow users to also choose custom times

What is your proposed solution?

• build custom calendar for selecting date ranges see demo
• add ability to select time presets
• build out responsive (mobile) version of the component (noting that the design for this is not completed yet)

cc @noisysocks

[noisysocks]

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.

[mirka]

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.

[jameskoster]

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):

• A SelectControl contains any preset options
• When 'Custom' is chosen, two instances of TimePicker are revealed. These are used to set the From and To dates

Here's how this might work in a filtering situation:

[jameskoster]

Coming back to this one with some updated designs, still built upon native input types but augmented with calendar UIs.

Presets only

This design would make use of the DropdownMenu component for the UI and would be handy for quickly filtering certain data views.

Simple date range

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.

Simple date range with calendar UI

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.

Combo: Presets + simple custom date range

Combo: Presets + custom date range with calendar

This one is very similar to the design in the OP. The calendar interactions could be the same.

[ciampo]

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:

• on mobile devices, where they'd get a tailored mobile UI;
• as a V1 of the component, while the rich calendar UI gets implemented;

Also, I have a couple of questions:

• I see that all inputs also show a time — how would a user be able to set that?
• the component can take quite a wide portion of space — what happens if there isn't as much space? Ie. responsive layouts, sidebars, mobile screens, etc