top | item 34146193

(no title)

tsergiu | 3 years ago

Almost every date picker I've used is terrible. If you are reading this and are responsible for adding a datepicker, please, please, please do at least the following:

1. There should be a textbox allowing me to type a human-readable date/time (e.g. "monday 5pm" or "july 7, 2015").

2. The textbox should be selected and ready to type into as soon as the datepicker is opened

3. There should be a short list of previously-typed dates because often, for a given date in the UI, the same date is used multiple times in quick succession

4. There should be a typical month view with days of the week visible, in case I'm on mobile

5. The current date should be highlighted on the month view.

6. I should be able to pick the month and the year in at most two taps each (i.e. dropdown for each), no matter how far back in time I need to go.

Shameless plug: we recently implemented an exceptional date picker on momentcrm.com because of how frustrated we were with the default browser experience.

discuss

order

bradgessler|3 years ago

In my web apps, I make dates text boxes that can handle inputs like “next Thursday”, “Monday at 5p”, etc by running the inputs through https://github.com/mojombo/chronic

I like the idea of inputs being able to make sense of as wide of a variety or formats as possible.

For number inputs I’d like to build into Rails something that can handle basic math expressions. For example, a person can enter “120 / 2” in an input and get 60. This is useful for expense apps where you need to expense half of something.

If folks are interested, I can open source these bits. I’d like to expand them as much as possible to handle an even wider variety of inputs.

gernb|3 years ago

So you do you handle every language or just English. Can I write 来週の木曜日? or "hier" etc...

bmitc|3 years ago

That's a cool library. I note that WolframAlpha handles this type of stuff readily. Does anyone ever bundle Wolfram products into theirs to handle natural language type things? I'm not immediately sure of the licensing framework, but it would seem nice to be able to do that.

Edit: It seems that WolframAlpha does have an HTTP API.

https://products.wolframalpha.com/api/documentation

I'm curious if anyone has used it. It costs but it could save an immense amount of time.

mastersummoner|3 years ago

Chronic is an awesome date library, agreed.

Xylakant|3 years ago

In your (1) case, how do you handle input that is m/d/y vs d/m/y - there are cases where cannot identify which convention has been used.

markdown|3 years ago

> there are cases where cannot identify which convention has been used

You could always just ask them. "I'm sorry but we had trouble parsing your date. Please indicate the correct date:

_ Saturday the 12th of March, 2032

_ Wednesday the 3rd of December, 2032

_ Neither, let me choose again.

gernb|3 years ago

how about placeholder="mm/dd/yy" or placeholder="dd/mm/yy"?

enraged_camel|3 years ago

>> Almost every date picker I've used is terrible.

If you think date pickers are bad, you'll love time pickers, e.g. https://vuetifyjs.com/en/components/time-pickers/

mcintyre1994|3 years ago

I quite like the iOS time picker, but agree the analogue clock style that I think Android popularised is awful. The iOS one also gives a number keypad if you tap the wheels so you can enter that way if you prefer. It’s a shame they don’t do anything similar for dates.

themeiguoren|3 years ago

To break down why this picker is bad, here are several UX snags I immediately ran into.

1) It was not obvious how to set minutes, and I spent several seconds trying to get the hour hand to go in between hours.

2) When I let go and it snapped to minutes, it was not obvious to me how to go back and change the hour I had just input incorrectly. Then after I input minutes I expected it to jump back to hours but it didn’t. This is especially bad if your first interaction is a single touch rather than a press and hold, as it will jump with a wrong input and no obvious way to go back before you can even process how the interface works.

3) I have to look at different areas at the same time to select a time. My finger is trying to scroll a circle (where btw my finger covers the number), but I have to look above to see what the input is.

4) The above was even trickier in the minutes inputs, since there were not markings for sub-5 minutes.

5) It was not obvious that the top bar was clickable as an input area to select am/pm, especially since clicking the top bar would not otherwise allow you to input the time.

6) It’s not obvious with the switch to minutes / seconds that the units have switched. Need some representation of this on the clock face itself.

Some major ticks on all inputs and minor ticks that pop up on the minutes input would help a lot with 1, 4, and 6. Could be subtle markings, but would help quite a bit imo. But really this didn’t need to be anything other than a simple text input.

friend_and_foe|3 years ago

Those aren't so bad, they're reasonably intuitive to anyone who knows how to read an analog clock, and though they're easily fat fingered, you do one click for hour, one for minute and AM/PM in the non 24h versions. Imagine a scrolling time picker where you couldn't scroll the hours, only the minutes. That's what common date pickers are like.

pydry|3 years ago

I'm still perplexed that this isnt how every website works.

The absolute worst are date pickers that grey out unbookable dates to look like past dates and default to one week from now, leading me to believe, if I'm not careful, that Im booking a ticket for today.

Seemingly no website that lets you book things has sensible date UX.

culi|3 years ago

Some of these are really great ideas! But I think they should be relegated to an external library or perhaps a web component. The issue here is this is the HTML datepicker. The picker itself isn't well-defined but things like being able to type in human-readable data/time and having it interpret that would likely conflict with the HTML standards already defined and be extremely difficult to define further. Not to mention you could only really do something like that on desktop and the issues pointed out in the post are dealing with mobile date pickers

f_allwein|3 years ago

Also, I’ve repeatedly come across date fields that force me to enter the month in two digits, i.e. 01 for January. What’s up with that?

tiluha|3 years ago

That's the default in Germany (and Europe?). Writing out the month is somewhat rare, although it does happen.

alistairSH|3 years ago

I’ve seen that, but I’m ok with it. I just assume it’s much easier to parse/check the entry if there’s a full 8 digits (mmddyyyy).