This report will cover multiple aspects of the date entry fields in the Time menu, because it's awkward to use in a number of ways.
1. Hesitating clears entered data
- Begin typing in a date field (e.g.
1)
- Pause for >1 second
- Type the next character (e.g.
2)
Instead of becoming 12, the contents of the field are replaced with a 2.
2. Deleting clears entire field component
- Begin typing in a date field (e.g. year
2010)
- Press the backspace key (e.g. because you meant to type
2011)
The entire year field gets cleared rather than a single character.
3. Input ignored and deleted when invalid
- Enter a “To” date before today’s date (e.g.
10/10/2020)
- Hit enter key/Search
Kagi ignores your input, and runs the search again with no date filtering.
This intersects with point #5 below, but even if that's fixed this is still an issue: if the user gets from/to switched around, they don’t want the page that they’re already looking at to simply be reloaded (because that’s when this would occur), forcing them to re-enter their desired dates from scratch.
Kagi should either automatically swap the dates so that it’s a valid range (this is DDG and Google’s behavior) or alert the user that the dates are invalid without initiating a search or clearing the entered data.
4. When not changing all components of the date, the input is ignored
Imagine you want to search for pages published since January 1 of this calendar year.
- Set “From” month and date to 01/01
- Hit enter key/Search
Kagi ignores your input, and runs the search again with no date filtering.
The issue here is that the dates are treated as actual dates in some ways, and placeholder text in other ways. If you leave the field alone entirely, it behaves exactly as though it is today’s date, like it appears to be. However as soon as the user alters any part of it, the placeholder text is completely ignored, so if the user only alters part of the date, it is seen as underspecified, and therefore ignored and replaced with today’s date.
In addition to this being surprising behavior, there is also no visual cue to the user regarding which date components have not been altered from their placeholder text (except while selected, and in a non-obvious way). If you want to say 1/1/2022, you need to type the 2022 yourself, even though it looks exactly the same as simply letting the 2022 remain.
5. Default “From” date doesn't make sense
Because we don’t have access to the future, the only case for “From = today” is when searching for things published today, which is mostly already covered by Past 24 Hours.*
There are two types of solution which I’d endorse:
- It should be earlier, e.g. 1/1/2000 or 1/1/2010 (or at the very least, yesterday).
- Both fields should be blank by default, like Google. This also allows the flexibility to underspecify dates: on Google if I leave the From field blank and simply type “2020” in the To field, it will search all dates ≤2022-12-31 (cf. #1126), and vice versa if the To field is blank.
*There are times when you might want things from today specifically, excluding yesterday evening, but this is definitely an edge case.
Final thoughts
I think an ideal solution would be for it to work more like Google’s date selection, which is a simple text field, allowing you to be very flexible with your input: it will interpret a From field with 2020, 1.1.2020, 2020-01-01, or even jan 1 2020. However, I understand this is a bigger deal than a standardized date entry!
